??changed: - * 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 - - * WhenSvN explains what we need to support SVN - - * SavaneTasks gives various ideas (easy and hard) to improve the Savane software which runs Savannah * 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 * WhenSvN explains what we need to support SVN * SavaneTasks gives various ideas (easy and hard) to improve the Savane software which runs Savannah
??changed: - - 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) - - - Document switching from CvS to GNUArch - - -Arch - - - Register archives in ArchZoom via a web interface * 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) ??changed: - - Suggest adding Savannah download areas to the GNU mirrors (GNU mirrors gladly mirrored the /savannah directory even when it contains untrusted download areas, and still mirrors the pre-crack CVS backups and post-crack changesets). Only signed files would be mirrored. (http://lists.gnu.org/archive/html/savannah-hackers-public/2006-02/msg00090.html for a positive preliminary reply) - - - 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). * 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). ??changed: - - 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/' - - - We're working on Doctor (http://doctor.mozilla.org/). Currently support is 'experimental'. If the experiment is successful, we could offer Doctor for all Savannah projects. - - - Doctor should support editing files in non-latin1 encodings. I guess it should try to auto-detect the encoding, offering to switch to a different encoding. The encoding would then be specified on commit for automatic reconversion. I do not know if the browser can really be made to edit, say, UTF8-encoded text... - - - We tried the new multi-site support, there was some issues: <Beuc> Ok, 1) so numbers cannot have 'gaps'; 2) there can only be one CVS repository (we have 2500 different CVSROOTs); 3) EDITOR_EMAIL is site-wide; 4) I suspect site-wide TEMP_DIR could host conflicting directories; 5) URI_PATTERNs conflict with project www (since www.gnu.org contains /software) - maybe it would be better not to try to guess the right repository. All in all I am not sure it is worth forsaking the symlinks-based approach we currently use. - - - (Submit that as bugs / patches) - - - 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. * 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. ??changed: - - Setup Zope backup and ZWiki backup - - - document backing-up / fixing zope (Wiki + doc in the repository) - - - contact CACert.org about their software license - - - generate new SSL certificates - - - move from CVS to Arch (show the example! :)) cscvs? - - - 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. * 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. ??changed: - - Clean-up mailing lists from old spam http://savannah.gnu.org/support/?103933 - - - Allow creation bug-/info-/help-$PROJECT from GNU projects, as well as $proj...@domain (ie not $project-$suf...@domain) - - -Savane - - - patch Savane to auto-invite people to these lists on either account or project creation - - - look for a way to easily invite people (mailing list command?) - -Long-term - - - Add an interface to manage translations, such as: - - - Pootle: http://translate.sourceforge.net/ - - - TRAD-LANG: http://eledo.com/article17.html - -[10 more lines...] * Clean-up mailing lists from old spam http://savannah.gnu.org/support/?103933 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 a more intuitive web interface. http://transifex.org/ is not a web interface but rather attempts to simplify and unify the translation workflow, easing maitainers/translators interactions. 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 Other projects: * 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) 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). 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) >From simon Sat Oct 13 08:35:23 +0000 2007 From: simon Date: Sat, 13 Oct 2007 08:35:23 +0000 Subject: zodb size Message-ID: <20071013083523+0...@https://savannah.gnu.org/maintenance> 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. >From Beuc Sat Oct 13 09:30:46 +0000 2007 From: Beuc Date: Sat, 13 Oct 2007 09:30:46 +0000 Subject: zodb size Message-ID: <20071013093046+0...@https://savannah.gnu.org/maintenance> In-Reply-To: <20071013083523+0...@https://savannah.gnu.org/maintenance> 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 new ZWikis version 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. >From simon Sat Oct 13 15:42:38 +0000 2007 From: simon Date: Sat, 13 Oct 2007 15:42:38 +0000 Subject: zodb size Message-ID: <20071013154238+0...@https://savannah.gnu.org/maintenance> In-Reply-To: <20071013093046+0...@https://savannah.gnu.org/maintenance> 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. -- forwarded from https://savannah.gnu.org/maintenance/taskslist#msg20090110100421+0...@https://savannah.gnu.org/maintenance _______________________________________________ Savannah-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/savannah-cvs
