[Debian-sf-devel] Debian Sourceforge -- status and plans

[Roland Mas]

  Hello people,

  I am mailing you because you have expressed interest in the Debian
package for Sourceforge at some point, either as a potential user, or
a potential developer, or a developer of some other related project
which could use some of the work that's been done on Debian-SF.

  I know I've kept promising it for some time now, here is a report on
the status of the Debian package.  I also mention the TODO list and
the plans for future evolution.  This will take the form of a
Not-So-FAQ.  People member of related projects, please do not miss the
"Greater plans" section at the end.

What is debian-sf?
------------------
  It is a package of Sourceforge for the Debian GNU/Linux operating
system.  That means, it's a file (or set of file) that can be
installed by a package manager, resulting in an automatic installation
of the Sourceforge software on a Debian system.  A few questions can
be asked to the user as part of the process for the local settings,
and the result is that with a Debian system and a simple "apt-get
install sourceforge" command, you get a fully-functional Sourceforge
server running in a matter of minutes with no hassle.

  Well, in theory.

  In practice, you only get a mostly-functional Sourceforge server
running in a matter of minutes with no hassle.

So, what works and what doesn't?
--------------------------------
  Well, first, a statement: my package is based on the last officially
released version of the Sourceforge code, labeled 2.5.  I have
modified little of it except for bugfixes and necessary changes.

  What works: the web part.  You can create your projects, your user,
manage them, use the bug-tracker, the patch manager, the monitoring of
those things, the documentation manager, the surveys, etc.  The LDAP
backend works, which gives us the CVS and shell accounts.  DNS is
done, as well as virtual hosting for the project homepages.

  What works not (yet): FTP, mail forwarding, stats.

Now how does it work?
---------------------
  Well, we use some of the features provided by Debian.  The
dependencies system allows us to be able to rely on the appropriate
pieces of software to be installed.  The Debian policy allows us to
depend on a system where we know where the files are and how we can
modify them.  Some Debian-specific tools (e.g. Debconf) allow us to
ask questions to a user on his first installation, in a friendly way.
Building on top of these, a few scripts have been written to turn the
original SF2.5.tar.gz tarball into a policy-compliant, running
Sourceforge.  These scripts take care of configuring Apache, Bind and
PostgreSQL (plus others), they create the database, they upgrade it
when needed (more on that later), etc.  And they clean up after us
when the user decides to remove Sourceforge.

Who dunnit?
-----------
  I dunnit.  I am Roland Mas, known by many email addresses,
identified by the 1024D/144843F5 GPG key available on most public key
servers.  I am a French Debian developer, and a member of one project
on Sourceforge.net (ORBit-Python).  I first tried to install
Sourceforge 2.0 in my workplace approximately a year ago, I did it
several times, and I ended up by posting my installation log on the
Offsite forum.  Then Guillaume Morin took this log and turned it into
a full-blown installation guide for SF 2.0, much more complete than my
log was.  That guide was in turn used by me for my first attempt at
packaging SF for Debian.  I almost released my package for
Sourceforge 2.0, but since then 2.5 was out.  So I decided not to
provide an upgrade path from 2.0 to 2.5, and I started working on 2.5
right away.  The first upload to Debian was done on May the 14th, 2001.

  But I didn't do it alone.

  Christian Bayle is another Frenchman, but not a Debianite.  Well,
not an official developer anyway.  He did more than I can thank him
for, including all the LDAP thing, the CVS, the CVSweb, the virtual
hosting, and probably more.

Want more?
----------
  Thanks to Christian's constant nagging, the whole package is now
hosted on Savannah.  The project name is debian-sf, and the
appropriate URL is <URL:http://savannah.gnu.org/projects/debian-sf/>.
Savannah is a variant of Sourceforge (in fact, a fork of the 2.0 code)
maintained and hosted by the FSF for GNU projects and recently other
Free Software projects too.

  If you want to keep informed on this package, please drop by and see
for yourself.  There are three mailing-lists, subscribe at will.

  If you want to occasionnally help the development of this package,
get yourself an account on Savannah and post patches.  If you're
serious about it, tell me and I'll add you to the group so that you
have CVS write access.

  If you want to help but cannot commit yourself to active
development, install and use the package, track bugs on the Debian BTS
at <URL:http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sourceforge>,
send additional info (or patches) on existing bugs, and submit reports
for any other bugs.  Savannah does not provide a bug-tracker yet, but
Debian has its own, so it's better to use that one.

What are the plans?
-------------------
  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.
I'm thinking of features such as e-mail forwarding (the like of
address@hidden), complete and working stats system, FTP and file
releases, mailing-lists management, and probably more.

  Second, we have to upgrade to Sourceforge 2.6.  Well, not 2.6 since
it never was released, but at least a more recent snapshot of the (now
sadly closed) CVS repository.  This will mostly involve a big database
switch with a tricky and windy migration path and very little room for
mistakes (for which we already have some infrastructure), and several
other changes as well (since I suppose the tools have changed, fixed
old bugs, and introduced new ones).

  Third, we have to split the package in parts.  The current package
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.

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

Greater plans
-------------
  "Recent events" that occurred at VA Linux (please read the thread at
<URL:http://sourceforge.net/forum/forum.php?thread_id=133596&forum_id=21304>
and follow the links for the full info) led me 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.  I 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?  I'm
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.  I have already been contacted by people wanting to make a
Red Hat package out of my Debian one, and they were at a loss to find
the info although it was plainly written in the scripts.  I'm not
making fun of them, it's just that I 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", I think the cooperation would be positive to
us all.  I will spend some time browsing through the other three
projects sources and try to extract info for my own, and I encourage
you to do the same.  Don't hesitate to ask questions, as I won't
hesitate myself :-)  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 I 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.

  </not-so-faq>.

  Well, that was a lengthy email.  I'm sorry for the time I've just
stolen from you, I probably won't email you personnally anymore except
on demand.  I'll use the appropriate mailing-lists instead.

Roland.
-- 
Roland Mas

$ chown -R us:us your_base*