[Mageia-sysadm] Main tasks for the next days

[Michael Scherer]

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