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/[EMAIL PROTECTED]/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/[EMAIL PROTECTED]://savannah.gnu.org/maintenance _______________________________________________ Savannah-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/savannah-cvs
