sf move plan

[Mohammed Elzubeir <elzubeir at fakkir dot net>]

Here is the plan:

Moving to SourceForge has many advantages and obviously some disadvantages. It
is in my opinion that the pros outweigh the cons, but I gather it is not the
general concensus.

Since this is proposed to make our lives easier and not more difficult, I
would change plans to suit the majority. While I do reserve the right to veto, 
reaching a concensus among the core team is clearly outlined in our so-called
'manifesto' ;)

So, I will first explain what the pros and cons are of a big-scale move to SF,
and then present the details of the move (which have been modified from the
original plan).

Although getting support from SF can be a very very long process, it should
rarely be needed. Everything else operates almost flawlessly on it, and I only
had problems when I didn't understand their setup. I think that is the case w/
Chahine (back with aunyx). The fonts/look/color of SF are customizable, so if
you don't like an interface you have two other alternatives. Also, I can view
it just fine from just about any browser OTHER than Netscape on some Linux
boxes (which don't have all the nice fonts setup). The layout is something I
can't comment on <shrug>.

The 'good stuff' about sf....<drum roll> ;)
  - less overhead (maintenance/administration)
  - more bandwidth
  - more stable network (not that the current is not!):
		  we are running on a dynamic ip, if we lost it we will be unreachable
		  for a day or 2 are the new information propagates throughout the net.
  - more exposure -- and this goes both ways, for fellow arabeyes'ers and
	    for the rest of the open source community to us.
  - did i mention less overhead?			

i. CVS:

We will continue to keep the CVS repository as is, and will discontinue
updating the CVS on sf (will just disable the cvs option so it doesn't
even show).

ii. Web site:

The web site will move in its entirety over to be hosted by SF, granted that
they provide us unhampered access to a mysql database and php/perl/cgi. In the
event that any of those services are unavailable, the web site will remain on
the current arabeyes.org box.

iii. QaMoose

If/when we move the site over to SF, QaMoose will remain on the arabeyes.org
web server. It will have a virtual host... and will be on
http://qamoose.arabeyes.org/

iv. KDE files

The restructuring I am talking about will only be done after
  a) the core team all join the project on SF
	b) the translation team all join the project on SF

This will looks as follows

kde/
kde/kde-i18n/ara
kde/kde-l10n/ <-- country names

So we can work on the i18n and l10n hand in hand under one directory, with the
same exact KDE structure of those specific modules (which will make keeping
both upto-date easier).

v. Mailing Lists

The mailing lists will continue to run on arabeyes.org, with no plans to
change that in any other way. 

vi. Bug tracking system

I am not sure as to whether I would rather do this on SF, or locally run a
bug-tracking system (gnats). My only concern is SF's reluctance to
release/update their project extraction utilities, and I don't want to be
locked in w/o a convinient way of getting all the data we accumulate out of SF
should the need arise. That being said, I favor locally running gnats, but
that would interfere with the web page. 

So, this remains an open question.
-- 
-----------------------------------------------------------------------
| Mohammed Elzubeir                    | http://fakkir.net/           |
| Tech Support                         | http://www.arabeyes.org/     |
| College of Business Computing Center | Homepage:                    |
| University of North Texas            | http://fakkir.net/~elzubeir/ |
-----------------------------------------------------------------------