As far as this package is concerned, there are three big things that still need to happen.

First, we need to make debian-sf as fully functional as it can get. Some things don't exactly work like they should, or don't work at all. We are thinking of features such as complete and working stats system, for a start. [There used to be more items in this list, but they have been done.] Update: Christian and Roland consider that the stats system can wait. We therefore focus our attention on the following items.

Second, we have a mostly working 2.6 package, and it upgrades smoothly from a 2.5 package. We therefore focus on stabilising this upgrade path, and fixing any bugs.

Third, we have to split the package in parts. The current stable package (2.5.x) works just fine for a medium use, but it would probably not hold the load of a public site. So we need to be able to split the thing onto several boxes: the one that holds the database, the one(s) that hold(s) the web services, the one(s) that hold(s) the mailing-lists, the one(s) for the CVS, the one(s) for the shell accounts... So we need to split the package in sub-packages. We already have split packages but need more test.

There also are a few less major things we need to fix, but not as big as those three.

"Recent events" that occurred at VA Linux Systems (please read this thread) led us to the following musings.

Sourceforge is not free software anymore. Oh, sorry, yes it is. Sort of. "SourceForge Open Edition" (note the marketroid speech), will eventually be released under the GPL. Sometime. Maybe. We are therefore looking around for a free alternative.

And the choice is ours. Savannah, sf-genericinst, sfportable, Debian-SF... It's not even a fork anymore, that's a multi-spike fragmentation. In some cases, concurrence is good. In others, it hurts. we think it hurts in this particular case, because if/when ever one of those projects dies or gets to sleep, its users are lost in the wild.

You may disagree that this is a problem, but here are two proposed solutions anyway.

First one is CoopX. This project aims at providing a description language, or a file format, or something along those lines, to store the data in Sourceforge-likes. The goal is to ease backups and more importantly to ease transition for migrations. Say, if at some point I (as a user of one SF-like) recognise the Super Powers of the sf-genericinst package when compared to debian-sf, I might want to move my project from one type of hosting to another. If the whole project (or the most part of it) can be saved as myproject.coopx and reloaded at some other site, then the fork will not be as bad, because people will have the choice for their platform, and they will not be bound by it afterwards.

The second solution is, well, obvious. Why don't we cooperate? we're sure there is as much to learn from Savannah by debian-sf as there is from debian-sf by sf-genericinst, but the info might be hidden in scripts. we have already been contacted by people wanting to make a Red Hat package out of our Debian one, and they were at a loss to find the info although it was plainly written in the scripts. we're not making fun of them, it's just that we recognise the way packages work is not as easy to get out from the scripts as it is when someone explains it.

Since CoopX is now at the least a good idea and at best a project "in the planning phase", we think the cooperation would be positive to us all. we will spend some time browsing through the other three projects sources and try to extract info for our own, and we encourage you to do the same. Don't hesitate to ask questions, as we won't hesitate ourselves :-) Please use the debian-sf-deval mailing list for questions on debian-sf though, so that we get archives.

In a second phase, maybe we could even try to un-fork, eventually becoming one big family, but we think this cannot happen anytime soon. sf-genericinst is 2.6-based, debian-sf is 2.5, Savannah is 2.0, and there are simply too many differences between all of that.