[Savannah-hackers] Savannah status report

[Paul Fisher]

Sending the savannah status report a bit late this week; I was holding
off on being able to announce log_accum being turned back on, but due
to some needed last minute changes to the SMTP portion, and a flood at
the FSF offices today, log_accum has been pushed back a few hours.
Depending on the severity of flood related activities in the morning,
I should be able to get log_accum turned back on tomorrow, and will
send email once that has been done.

Items worked on this past week:

  * Final C code written to handle SMTP sessions.  That code is on
    savannah, in /usr/src/socket_mail.c.  We should be able to reuse
    that bit of C for any other apps running in the chroot that need
    to send out email.

  * Fixed CVS access to Savannah that broke this weekend.

  * Itemized the list of remaining large tasks that need to be
    completed for Savannah.  That list is at the bottom of this email.
    Time estimates are also included and assume forty hour work weeks.
    We currently don't have sufficient staffing to devote forty hours
    a week to Savannah work at the FSF, and assuming one full-time
    person, we feel there's about a years worth of work needed on
    Savannah.  Help from any volunteers interested in working on any
    of the listed items is appreciated.

After log_accum is finished, the next item on the list for this coming
week is to re-enable mailing list creation.


Large task list:

* GForge Transition (16 weeks)

GForge needs to be installed and configured.  Savannah's database
needs to be ported to GForge's database structure.  Upstream changes
to GForge will likely be needed, and coordination will need to occur
with Tim Purdue on those matters.  GForge's backend process will need
to be audited.  Projects will need to be smoothly transitioned from
the Savannah install to the GForge install.

* Create a web interface to manage CVSROOT directories (2 weeks)

Files within each project's CVSROOT need to be edited by the package
maintainers, but allowing CVS access to CVSROOT is insecure.  A web
interface needs to be built to allow fine-grained control of portions
of the CVSROOT directories.

* Process for securing remaining/future CVS commit scripts (2 weeks)

CVS commit scripts other than log_accum need to be evaluated, audited,
and put back in place.  A system needs to be created for suggesting
new CVS commit scripts be put in place for projects to use.

* Create a web interface to manage Download areas (4 weeks)

A web interface needs to be built to manage GPG-signed uploads of
files for distribution.  All files distributed on savannah.gnu.org
require GPG signatures.

* GPG signed CVS changesets (12 weeks)

CVS needs to be modified to support GPG-signed changesets to insure
the integrity of source code hosted on savannah.gnu.org.  Those CVS
changes will need to be integrated into the upstream CVS codebase.

* Exec-shield support for Debian stable (3 weeks)

Exec-shield can provide a good deal of protection against buffer
overflow attacks, but Debian stable does not support exec-shield and
it's not likely that a new Debian stable will be released this year.
Consistent with the policy of running Debian stable on production
servers, to support exec-shield, we will need to backport a current
gcc and binutils and keep an exec-shield-enabled compiled copy of
Debian stable for use on savannah.gnu.org (as well as other FSF
servers).

* Performance analysis / scaling requirements (4 weeks)

The current Savannah install already has performance issues, and the
scaling requirements need to be carefully investigated such that we
can determine the rate at which we will need to increase hardware
capacity as projects grow and where to focus software optimization
efforts.

* Make CVS locks use a RAM-disk (2 weeks)

The current Savannah install spends much of its time performing disk
I/O.  Given the amount of RAM available on savannah.gnu.org, it would
be useful if "mount --bind" or a similar technique could be used to
allow the multiple chroot'd CVS installs to share a single RAM-disk
for their numerous locks created during every CVS checkout..

* Improve webcvs (4 weeks)

The current webcvs uses an excessive number of resources by forking
copies of python for each and every webcvs request.  webcvs should be
ported to work with mod_python.  We also have a need for webcvs to
work with the chroot'd CVS install setup on savannah.gnu.org, and
those changes need to be written in a maintainable fashion that are
suitable for importing upstream.

* GNU arch support (3 weeks)

Savannah.gnu.org should support the GNU version control system.

* Mailman control from savannah.gnu.org's web interface (2 weeks)

Full remote Mailman control should be added for creating, destroying,
and renaming lists. (In the past, only automated Mailman list creation
has been supported -- all other requests were performed by hand.)

* Investigate offering other bug-tracking systems for GForge (2 weeks)

Much of Savannah's and GForge's complexities come from reinventing the
wheel when a good piece of free software already exists.  Many free
software developers are familiar with using Bugzilla and other
well-maintained bug trackers.  Offering such services would be a
benefit to what Savannah (and Sourceforge) currently offers.