[Mageia-sysadm] Main tasks for the next days

Tue Nov 16 13:54:37 CET 2010

Le mardi 16 novembre 2010 à 09:01 +0100, Romain d'Alverny a écrit :
+> On Tue, Nov 16, 2010 at 00:55, Michael Scherer <misc at zarb.org> wrote:
+
+
+> > There is lots of topic that we didn't really discussed about ML setup
+> > like :
+> >  - list moderation policy
+> 
+> Do you have an example of such a policy?
+
+Nope, but I guess we can find some of them for
+debian/ubuntu/fedora/gentoo.
+
+http://fedoraproject.org/wiki/Hall_Monitor_Policy
+https://wiki.ubuntu.com/MailingLists
+http://www.debian.org/MailingLists/HOWTO_start_list
+
+( but most research give MLs guideline for users, that we already have )
+
+But this is also related to the creation of a team to take care of that,
+and to the policy of creation. Ie, who decide that list are created or
+not. 
+
+And also who take care of the list that are not tied to a team. And who
+can moderate a list, the moderation team alone, the team leader, the
+sysadmin, a combination of them, etc ?
+
+> >  - archiving
+> 
+> Not sure it makes for all, but, subscriptions to public ml should
+> state that all communications on these lists are archived.
+
+We also need to discuss what will be public and what will not. 
+
+And what do we do with thing like gmane ( nntp and public archiving ). A
+automated integration would be nice ( like automatically subscribe to
+their service when we offer a mailing list ), but this would require a
+script I guess.
+
+There is also the topic of ml<-> forum integration.
+
+> >  - migration from the old server ( especially for archives migrations )
+> 
+> I don't know if we can import Mailman archives into Sympa ones. If
+> not, maybe we should just copy plain archives into a specific place
+> and put redirection rules for existing ones.
+
+Even we do import, we will likely lose links, and therefore we will need
+to change 1) blog posts 2) mailing list archives. So a copy of the
+website should be done indeed. How long should we keep the url is open
+to discussion.
+
+> >  - setting a proper spam filter, with greylisting and sympa integration
+> 
+> How is it managed at this time with Mailman? Can't this be done after
+> Sympa production setup?
+
+For mailman, this is managed at the smtp server level, and we do not
+have any kind of integration ( but this will likely change as I am quite
+tired of cleaning the queue of some others zarb.org project with 100
+spam per month ).
+
+And by integration, it usually mean "moderation/rejection based on SMTP
+headers".
+
+For the moment, there is around 1 to 2 spam per day that end in the
+moderation queue for mageia lists. Without spam filtering and
+greylisting, I suspect it will be much more ( greylisting reduced the
+load of spam by 90% the day we deployed it ). And as the one that clean
+the moderation queue quite often, I am not thrilled of having a mail
+server without spam protection :)
+
+But my point is we need a proper ( read with proper filtering and
+redundancy ) smtp server before having a ml server.
+
+> >  - web interface setup and requirement
+> 
+> Isn't a sympa vanilla install correct for that?
+
+We have to check, and for this, we need to know what we want.
+
+I am quite confident that it can be tweaked to do what we want as it
+offer templating ( with TT2 ) like most of the perl applications we
+deployed.
+
+( and in fact, I also think we should add "template technology used" to
+the list of criteria for selecting application, as I do not think the
+web team will love to have 23 types of languages to learn for this )
+
+But we need to see if there is work needed on this part. I mostly see
+the need to remove some part of the interface for some users, and the
+need for usual theming and navbar.
+
+
+A recurrent problem on AUFML server was that we had a dual admin
+interface : some people were subscribed with drupal and ldap ( and a
+nightly synchronisation script ), and some with mailman. 
+
+Yet, people used mailman to unsubcribe ( as this was the logical thing
+to do, and since nothing prevented it on mailman side ), and some people
+were then re subscribed each night, leading to frustration ( and some
+angry mails toward admins ). 
+
+
+> >>  * we will import a copy of the Mandriva soft/ repository as
+> >>    svn.mageia.org/soft-cleaning, and will use this repository to clean
+> >>    all projects. Each project when ready will be imported in the new
+> >>    soft/ repository (when the new organisation has been decided). The
+> >>    soft-cleaning repository will only be used to do the cleaning work
+> >>    and will be erased when finished.
+> >
+> > Without history ?
+> 
+> Without svn history, this what I thought we agreed on yesterday
+> (checking http://meetbot.mageia.org/mageia-meeting/2010/mageia-meeting.2010-11-15-19.36.html
+> it is).
+
+The lose of history was for the packages, not for soft ( at least,
+that's what I understand, given the fact that "history" is said 5 times
+and all related to packages, not soft/ ).
+
+We all agree that some softwares will need to be cleaned from icons, but
+IMHO, most of them don't. I also think we can do miracles with git-svn
+and history rewriting ( except it may take time ). 
+
+But having worked on software without svn history, I can tell you it is
+a source of recurrent frustration. You look at some weird piece of code,
+you do not understand why it was done like this, you do svn blame ->
+"rev 443 admin: import of the old repository". You are screwed.
+
+> > Because there is software that do not requires cleaning ( like mdvsys or
+> > some software that were fully created by the community ).
+> 
+> Not related, but isn't this a supplementary reason to have a separate
+> SVN repository for each project, and not a single one for soft/ (as it
+> is today)?
+
+Yes, it is.
+
+-- 
+Michael Scherer
+
+