savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-hackers] Followup on large Savannah tasks


From: Paul Fisher
Subject: [Savannah-hackers] Followup on large Savannah tasks
Date: Mon, 14 Jun 2004 18:35:09 -0400
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux)

For the larger item tasks, it might be a good idea to organize the
list and make it available for other volunteers to work on.  I've
already put the top three requests from Elfyn at the top of the list.
Feel free to reorder the list as appropriate.

In addition, the FSF is going to be sponsoring a contest to add GPG
signed changesets to CVS.  That announcement will be made soon.

Jim and I are busy working on getting the new associate membership
site rolled-out at the FSF this week.  We'll have some spare cycles to
work on Savannah next week.


Large TODO list:

1. Create a web interface to manage CVSROOT directories

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.

2. Create a web interface to manage Download areas

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.

3. Mailman control from savannah.gnu.org's web interface

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.)

4. GForge Transition

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.

5. Process for securing remaining/future CVS commit scripts

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.

6. GPG signed CVS changesets

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.

7. Exec-shield support for Debian stable

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).

8. Performance analysis / scaling requirements

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.

9. Make CVS locks use a RAM-disk

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.

10. Improve webcvs

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.

11. GNU arch support

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

12. Investigate offering other bug-tracking systems for GForge

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]