Re: [Savannah-hackers] savannah.org

[Joel N. Weber II]

   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).

Doing a completely seprate mailman installation just implies taking
another copy of the source tarball, and configuring it with a
different installation directory.

The real costs we are saving also include things like acquiring
hardware (which becomes painful if you want to make sure that the FSF
or VA pays for it rather than you personally; I rather strongly
suspect that if I added up how much time I've spent trying to get the
FSF to buy hardware, and if I spent 1/4 of that time being paid to do
work on proprietary software, that I could then pay for whatever
hardware I wanted the FSF to get), and fixing the system when it
crashes, etc.

    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. 

Umm, I think what you're proposing is a lot more complicated and
trouble prone than just installing mailman in two different directories.

    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".

That's true, though.  Still, we could also get away with just copying
the aliases from one alias file to the other, and adding a redirect in
the apache config file (or an Alias directive would be even more
subtle) for the few cases where this comes up.  I see no reason to
worry about a general eloquent automated solution if it's likely that
a manual kludge that works pretty well will get the job done.