[Gforge-devel] GForge Project Enhancements Proposal

[Justin Richer]

Hi everyone,

As some of you may already know (*waves to Roland and Christian*), I've
been involved in running a SourceForge server for MITRE, the USAF, and
some other associated peoples. Our installation is based on Debian-SF
version 2.5, synched with whatever the latest revision is out now, and
enhanced with several major changes that we've developed here. We have
just learned recently that the run for our project is up at the end of
the fiscal year, and at that time we're no longer going to be supporting
this installation. However, it is now our task to clean up and
transition our changes, which translates to the following proposal:

We would like to port everything that we've worked on that is of
interest to anyone else to GForge (from SF-2.5) and release it all as
OpenSource and, hopefully, have it merged into the GForge project.
However, we'd like to actually work with everyone on this to make sure
that our changes integrate smoothly with everything else. That is, that
our object structure is coherent, that our database tables don't step on
others, and that coding styles are up to par. Keep in mind that we
already have all of these things implemented in 2.5, and we know how to
get them working under that environment. We never did get to the point
of setting up an installer for our system though, as we were supporting
a small installation. What we want to do now is create a clean port of
everything within the next couple months (when our FY is up). Our
features and functionality include:

 * A somewhat rewritten Theme engine to replace the horribly incomplete
one found in 2.5. While this is not really an issue for GForge, many of
our other modules depend on some new themeable functions in this
infrastructure. We're going to have to work out exactly what needs to be
pulled and what needs to be dropped, as I don't think anyone is
particularly in the mood for completely rewriting the GForge theme
system (if you are, please speak up! :).

 * A fully customizeable Role-Based Access Control system. All projects
have a number of Roles which individual developers may be assigned to
upon being added to the group. Each role has a set of privileges for
each tool, which can be set to Read, Write, or Admin by a project
administrator. All projects get a default of four pre-defined roles:
Administrator, Member, Logged-In (member of site but not of project),
and Guest (no logged in account at all). A project administrator does
have the option, though, of creating any new roles for further
granularity. Our implementation is *very* heavily tied into the 2.5
framework, so a near total reimplementation will be needed. But, I
believe that the concepts can be gleaned pretty readily and that with
GForge's increased granularity of thing we should be able to do this
one.

 * Integration of the Chora (http://www.horde.org/chora/) CVS viewing
framework into SourceForge. This negates the need for any kind of CVSWeb
or ViewCVS system external to SF. We needed it in order to secure the
CVS viewing of certain projects to only members of those projects. The
Chora viewer is an advanced tool written in PHP and on par with CVSWeb
and ViewCVS in most functions. We've even included the integration of
CVSGraph into this Chora system. In addition to the viewing
capabilities, we've added some capability to check-in files from a web
form into CVS, either individually or a directory at a time (using a ZIP
file as a transit).

 * CVS-backed Document Manager. We've done away with the traditional
Document Manager and used a CVS/Chora-backed module to create a system
with full document history and the capability to store and display
various document types, including binary files (PDFs and the like).
While this does exist to some extent in GForge already, backing it with
Chora and its viewer structures could make for a cleaner interface.

 * CVS-based project webpages. This negates the need to give users shell
access to the host machine to update project webpages. The system sets
up triggers so that as soon as changes are checked into the module, the
pages get automatically updated.

 * Enhanced FRS. We've rewritten the interface for managing released
files in SourceForge, and now allow for completely web-based control,
including upload. I must admit that I've yet to play with a lot of the
system as it exists in GForge, and I need to see how much overlap there
is and how much this part is really needed. Regarless, it's worlds
better than the interface that exists on SF 2.5, and maybe we can get
some of that into GForge as well.

 * Licence/Domain manager. We've written a system for dealing with
different licenses for people coming from different domains, as well as
filters allowing only registration from matching email addresses. This
is probably too specific to our own needs, but it's here if anyone's
interested in it.

We'll have a couple staff coding this project on our end as soon as we
get our servers straightened out. As I stated before, I'd like to keep
this all synched with the main GForge project, and make sure that
everything we do is actually installable and usable by others. We've got
a bit of public release to waddle through before we can just toss our
code out the door, but I don't forsee any problems in that- just filling
out paperwork, really.

*dons asbestos suit* ... Any questions/comments?

 -- Justin Richer
    The MITRE Corporation