[Savannah-cvs] [TasksList] (edit) clean-up

[Beuc]

??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 
address@hidden (ie not address@hidden) 
-
-
-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: <address@hidden://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: <address@hidden://savannah.gnu.org/maintenance>
In-Reply-To: <address@hidden://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: <address@hidden://savannah.gnu.org/maintenance>
In-Reply-To: <address@hidden://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/address@hidden://savannah.gnu.org/maintenance