[Savannah-cvs] [SavaneTasks] a first version of the Savane Tasks List

[Beuc]

Savannah relies on the Savane software to interface users and system 
administration. Savane manages a list of services for each project, and a list 
of project members who can access them (some of them are project admins and can 
add or remove members).

Savane also provide a flexible bug/task/support tracker, with mail 
notifications, field transition hooks, fine-grained persmissions, query forms, 
squads, and more.

At Savannah, we rely on the 'savane-cleanup' branch:
http://savannah.gnu.org/projects/savane-cleanup
The reference repository is located at:
http://git.sv.gnu.org/gitweb/?p=savane-cleanup.git;a=summary
Read doc/devel/DEVEL and doc/devel/CLEANUP to see what's in progress or 
recently added.


This page is the Savane Tasks List.


Getting started with the code
=============================

 * https://savannah.gnu.org/support/?group=administration mentions several 
minor bugs that are mainly due to PHP E_STRICT warnings, waiting for fixes. 
This will make you understand how the code works. Assigned to: 

 * RMS also expressed interest in two small-sized improvements:

  *  Refine the search results; RMS noted that typing "Emacs" does not bring 
the Emacs project as the first search result (check 
`<http://lists.gnu.org/archive/html/savannah-hackers/2007-07/msg00048.html>`_). 
We currently directly rely on !MySQL to provide us with results and order them, 
so this requires a bit of manual post-processing, unless you know how to make 
MySQL better order the search results. A "direct match" feature would probably 
do the trick, too.  Assigned to: 

  * Provide a description for all repositories of all SCMs in use, so user can 
understand which ones are experimental, or mirrors (such as Emacs' Git mirror), 
or canonical/reference, etc. Assigned to: 

More important wanted changes
=============================

Mail interface to the tracker
-----------------------------

RMS also has interest in this one, because he's often offline. He cannot just 
set down for an hour and browse the Savannah website, but he could prepare a 
batch of trackers mail directives and send them all at once when online.

The main problem I can see is spam. We already get spamdexing on trackers, I 
can only image what we'll get through a mail interface... Studying the Debian 
BTS (Bug Tracker System - bugs.debian.org), which is entirely driven by mail 
and receives little spam, would probably prove interesting.

A note on permissions: the Savane trackers currently rely on heavy 
authentication and authorization (you may need to have a Savannah account, and 
then you may need to be "technician" or "admin" on the tracker to perform some 
actions). I do not see how to implement it for a mail interface. GPG might be 
used, but is not really suitable for that purpose. One suggestion is to simply 
disable tracker permissions if the tracker enables the mail interface for it - 
and proeminently notify the user about that fact. Again, the Debian BTS relies 
on a similar setup without apparent troubles, but this may need closer 
investigation.

Assigned to: 

Wiki
----

Provide a wiki for projects: problems include spam and replication for 2500+ 
projects. Or 1 big wiki for everybody, but we need to have a solid spam 
protection first. The goal is to avoid setting up a wiki that will be filled 
with spam, with not enough visitors to fix it (we're not as big as Wikipedia 
just yet ;)). Note that WikiSpam is usually different than (unfortunately) more 
common mail spam.

The format used by the wiki is also important. It would be good to be able to 
switch to another wiki system in the future, if needed.

This very wiki is hosted by ZWiki, but it relies on Zope. We don't have much 
experience with Zope, but from what we could see it doesn't seem suitable for 
hosting a lot of wikis. For example, the size of the ZODB grows large very 
quickly (600M for 1 wiki, which we thus had to purge).

Assigned to: 

SCM hooks interface
-------------------

We need to provide users with a web interface to register on-commit hooks in 
their repository. For CVS, we already offer several hooks: webpages on-commit 
synchronization (site-wide), commit_prep+log_accum mail notifications (per 
project, can be used multiple times), cia.vc notification via XMLRPC.

There's already some work done:

 * 
http://arch.savannah.gnu.org/archzoom/address@hidden/infra--main--0--patch-130/cvs/generate_log_accum.pl

 * frontend/php/cvs/admin/ in the Savane source code

The code has some limitations. In particular, when removing all hooks at once, 
hooks are still kept installed in the system (the replication model is flawed). 
Site-wide hooks are currently hard-coded.

Assigned to:

Translations
------------

Unlike one of our proprietary competitors, we do not have a translation web 
interface. Installing Pootle (http://translate.sourceforge.net/) and 
integrating it with Savane would be great. Other improvements would be to 
connect it directly to the repository to edit the .po using an intuitive web 
interface.

Assigned to:

--
forwarded from 
https://savannah.gnu.org/maintenance/address@hidden://savannah.gnu.org/maintenance