[Savannah-hackers] Re: Update on Savannah

[Mathieu Roy]

address@hidden (James E. Blair) said:

> The FSF admins (of which there are only two on staff) have a backlog of
> tasks related to Savannah that we have not been working through as quickly
> as we had hoped we would.  We've been out of the office on holiday around
> the new year, and we've had a number of urgent tasks (one assigned
> directly by RMS) that we have had to work on in addition to Savannah.
>
> But this is what we have been working on recently:
>
> * We have had multiple hard drive failures (not on Savannah), that
>   have required immediate (and considerable) attention.
> * A new local root exploit prompted us to drop everything and compile
>   kernels for all of the machines that we run, including Savannah.
> * We've been working on the webcvs repositories.  We have them up and
>   running now, so people can work on them.  We have been struggling to
>   get the GNU web server to update the content from those
>   repositories.  We're very close to having hourly updates working
>   properly again.  (We still plan to get sync-on-commit working again
>   after we get through more of the Savannah tasks.)
> * We fixed the "uidxxxxx instead of username in CVS history" bug.  This
>   involved changes and testing to cvs and the cvs-chroot code.
> * We checked out the gnu-content and non-gnu content trees as
>   requested by savannah-hackers so that they can update site content
>   through CVS.
>
> These are the things we still have to work on:
>
> * We have identified a number of potential problems with the back-end
>   Perl scripts.  These still need to be corrected before we can:
>
>      * Rework back-end scripts that create projects so that the
>        repositories are created correctly in the new chroot environment.
>
> * Address security and authentication concerns about the file upload area,
>   and then re-enable that.
>
> * Make viewcvs work with the webcvs repositories.
>
> * We must address the "cvs-locks" bug.
>
> * We need the help from savannah-hackers in creating a new web interface
>   to the administrative files in CVSROOT.
>
> We very much need the help of savannah-hackers to finish the work of
> creating a more secure and robust Savannah system.  We're working as hard
> as we can, but we can't possibly run Savannah by ourselves.  We want to
> work with savannah-hackers to improve the system.  Please keep in touch
> with us regularly so that we can help each other.  Bradley has proposed
> weekly IRC meetings, and we hope that we can make those happen.


* I currently have no time to devote to these activities. About the
change in the interface, the way to go is:

       - to make a branch for this development, with a name following
       the policy defined in savannah/doc/devel 
       (more generally, following every rules stated in
       savannah/doc/devel) 
       - to add an admin/configuration page in
       frontend/php/projects/admin/ similar in design (UI and code) to
       the others pages in that area
       - use a table called "joker" table in the database, not adding
       any fields to the usual table (this is something that can only
       be done after serious discussion at savannah-dev and should be
       done only when the branch is about to be merged in the trunk)


* About the change in the backend scripts, I would like to get the list
of the "number of potential problems". 

About "Rework[ing] back-end scripts that create projects so that the
repositories are created correctly in the new chroot environment",
changes to make the script fitting a specific installation should not
be made in the script but in projects/savannah/lib/Savannah/Cvs.pm by
adding a specific sub CvsMakeAreaSPECIFICNAME (the same goes for
download area). 
In other words, nothing should be removed but new methods should be
added when necessary, and selectable in the administration of group
type. CVS and other installation are always specific enough so that
one script can never fit with the same code (CERN management by CVS
have nothing in common with GNU management by CVS, for instance).

(As it is explained in the README, currently the association
method -> perl module -> sub name is hardcoded. In is something that
should change later.) 

Will the backend run inside a chroot or on the main system? If it is
on the main system, it is pretty trivial to write the sub that make
the proper creation  -- the only issue could be the args given to
the sub.




Regards,




-- 
Mathieu Roy

  +---------------------------------------------------------------------+
  | General Homepage:           http://yeupou.coleumes.org/             |
  | Computing Homepage:         http://alberich.coleumes.org/           |
  | Not a native english speaker:                                       |
  |     http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +---------------------------------------------------------------------+