* CurrentTasks describes what we're working on, usually has a higher priority * CVS contains some tasks related to the CVS setup * Git presents the progress with http://git.or.cz/ support * SvNTasks explains what we need to improve SVN * SavaneTasks gives various ideas (easy and hard) to improve the Savane software which runs Savannah
* Read-only bind mounts changed in recent kernel, and this results in /home being read-only when rebooting a vserver. Upgrade util-vserver or work-around. * user katzchen is continously removed and recreated by the sv_users cron job. Investigate. * The Cacti CPU graph is apparently graphing "idle" when it's graphing "user". This makes people believe the CPU is loaded, while it's not (cf. Munin CPU graph and the anti-peak on march 4th when I artificially loaded the CPU)
* Make a clear, simple, illustrated explanation of the use of SSH public keys. That's not a very simple concept (PKI + keygen + passphrase + ssh-agent + ssh-add + pros over password-authentication) * Explain why we use.org, and explain how to import the certificate using screenshots
* Suggest unifying alpha/ftp/download.sv. This could be easily done by setting Savannah as the main upload area, and have it replicate signed files to ftp.gnu.org and alpha.gnu.org (this involves adding a new download area for GNU projects). * Per-project stats? e.g. http://stats.gna.org/ (you can try to contact https://gna.org/p/admin about it)
* Improve the quick-n-diry webpages sync-on-commit. commit_prep is needed to that a multi-directories commit doesn't trigger multiple remote 'cvs checkout' at once. * Add support for other targets directories, so we can properly host translations team at 'www.gnu.org/server/standards/translations/country_code/' * Unified notification for www.gnu.org portions. Possible unified CVS repository, dunno, but in the long run I'd rather have project chose how they want to update their webspace, so this doesn't fit well.
* document backing-up / fixing zope (Wiki + doc in the repository) * We need to keep several pieces of information out of Savannah: * contacts: get something automated to have your local copy in-sync * password (TLS CA + Zope + Mailman - others can be found in savannah or mysql config files): make a script to maintain a crypted file that contains the passes. Optionaly have the order of the passes scrambled at each regeneration (so no assumption can be made on several successive versions of the file) and do not rely on temporary files during the update. Optionaly do not put the passes in a file, but in each of our brains, and scrap this whole idea.
* Clean-up mailing lists from old spam http://savannah.gnu.org/support/?103933
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 a more intuitive web interface.
Note: Pootle is currently (1/2009) merging different branches and switching to the Django web framework. The latest release isn't very stable, but the next ought to be :)
http://transifex.org/ is not a web interface but rather attempts to simplify and unify the translation workflow, easing maitainers/translators interactions.
The Translation Project (http://www.translationproject.org/) doesn't have tools to edit the .po and .pot per se, but they have a publication system to manage them by team. It manages a good part of the GNU projects, including coreutils and GCC. The source code can be found at: http://svn.vrijschrift.org/tp-repo/TP/
Tools to work with .po:
* http://translate.sourceforge.net/wiki/toolkit/index - the Translate Toolkit, used by Pootle.
* http://code.google.com/p/polib/ - .po parser
* https://launchpad.net/pyg3t - http://bazaar.launchpad.net/~k-nielsen81/pyg3t/trunk/files - only an initial code import
* TRAD-LANG: http://eledo.com/article17.html * Entrans: http://entrans.sourceforge.net/demo/main.php * Poliglota: https://tracker.gnulinuxmatters.org/wiki/Poliglota * CLWE: http://www.wiki-translation.com/ * Ikiwiki: http://ikiwiki.info/ (a native translation plugin using po4a is under development)
* Down with Rosetta! (proprietary, used at Ubuntu Lanchpad)
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 thatis 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).
Suggestion for anti-spam: I think that one of the most useful anti-spam features would actually be statistics. We have numerous anti-spam systems in different areas, but little data on how much spam was caught, nor ways to quickly review caught spam to check for possible false positives. It would be good to have a set of anti-spam features that we could enable or disable, and then see how effective it was.
Another discussion: http://lists.gnu.org/archive/html/savannah-hackers-public/2009-01/msg00003.html
* Official .gnu.org webpages need to be validated by maintainers and their team - open wiki can be a problem
- Work-around: manual sync from temp wiki site to .gnu.org for the Hurd Wiki
- Disallow non-member contribution (not recommended)
Find a nice wiki for that, consuming little resource
* Or provide a big wiki for everybody
* Plan something against spam (TextCHA seems to work fine at the moment)
zodb size --simon, Sat, 13 Oct 2007 08:35:23 +0000
Hi Beuc.. zodb files get large, but that's just historical records chewing up disk space, and does not correspond to memory usage. Many zope sites have zodb files of 1G or more. Pack it periodically to keep the size down. FYI I host 30 zwikis on one server and 60 on another without problem.
zodb size --Beuc, Sat, 13 Oct 2007 09:30:46 +0000
Hi, that's what I meant with "purge", that is, "pack". I had to throw away the wiki history because of that. I think I read that newversion are using their own history format to avoid this problem, though. Anyway maybe I'm wrong, but until now I don't find Zope very practical, packing being one of the burdens.
zodb size --simon, Sat, 13 Oct 2007 15:42:38 +0000
That's correct, current Zwiki preserves edit history through packs. Well it's easy to pack nightly with a cron job, but I hear you, chat me if I can help.