Re: [Savannah-hackers] savannah.org

[loic]

Guillaume Morin writes:
 > 
 > Sorry, I should have included some details. It seems better to install a
 > completely separated mailman for the non-gnu projects.
 > This would be simple to implement.

 (Disclaimer : I know nothing about mailman administration)

 When you say it is simpler does it mean that it's just simpler to
implement, do you mean simpler to install AND to maintain or just
simpler to install ? I have no doubt that it's a lot simpler to
install. I'm concerned that it may not be that simple to maintain. The
whole point of using the same facility as mail.gnu.org is that all the
administration is taken care of already (security, sysadmin
documentation, backups etc), and the same rationale pushes me to
create a subdirectory of www.gnu.org instead of creating a new document
root elsewhere (mirroring, sysadmin, backups, webmasters documentation is
done already).

 Here is a naive view of what could be done, provided mailman is 100% unable
to separate two sets of mailing lists.

 - a db file listing all the non-gnu mailing list
 - a re-write rule in apache (mod_rewrite) 
   for virtual host mail.savannah.org/mailman/listinfo/non-gnu -> ok
   for virtual host mail.savannah.org/mailman/listinfo/gnu -> not-found
 - a re-write rule in apache (mod_rewrite) 
   for virtual host mail.gnu.org/mailman/listinfo/non-gnu -> not ok
   for virtual host mail.gnu.org/mailman/listinfo/gnu -> ok

 mod_rewrite is able to use a db file, it's efficient and writing the
 rules so that the same mailman set of lists looks like two completely
 separated set on mail.savannah.org & mail.gnu.org is a matter of
    . dumping a db file (cron job or triggered each time a mailing list
      is created or deleted on fencepost)
    . writing a few apache rules (once)

 The same kind of manipulation is necessary to deal with the mail
adress itself. The virtusertable (or something like this) can be updated
at the same time as the db file (address@hidden & address@hidden).
 
 This solution may not be necessary if mailman can do the job. Otherwise
it seems a fairly easy and simple solution to me : no administration
overhead, minimal documentation involved. 

 More to the point this would allow an easy and painless migration of
the list that go from the state "is not gnu" to the sate of "is gnu".

 Cheers,

-- 
Loic   Dachary         http://www.dachary.org/  address@hidden
24 av Secretan         http://www.senga.org/      address@hidden
75019    Paris         Tel: 33 1 42 45 09 16        address@hidden
        GPG Public Key: http://www.dachary.org/loic/gpg.txt