[Mailman-Developers] Plea for Help

Barry A. Warsaw bwarsaw@python.org
Wed, 13 Oct 1999 11:01:42 -0400 (EDT)


>>>>> "SR" == Sean Reifschneider <jafo@tummy.com> writes:

    SR> Distributed means that every developer gets their own personal
    SR> repository and the tool handles moving changes between
    SR> repositories.

    SR> This is exactly what I was thinking of doing with the more
    SR> public CVS repository.  Unfortunately, I don't believe that
    SR> CVS has any sort of mechanism for doing this automaticly, So,
    SR> that means that the core developers still have to do a lot of
    SR> work to maintain it.

My sentiments exactly.  What would be ideal would be some kind of
hiearchical arrangement of repositories.  Let's say the I18N guys work
on their patches for multi-languages.  Another group works on
archiving improvements.  Another group is improving the web
interface.  Maybe I hack on the database schema.  As each subproject
reaches various milestones, those changes would percolate up the
repository hierarchy so that wider groups of folks could bang on
them.  At some point, they would pass greater scrutiny and end up
ready for the main tree.  These changes would have to merge cleanly
with all the other changes coming down from the top.  Eventually, I'd
know that enough people like the change, have tested it, and
understand it so that I can pull it into the main branch without
reading every single line of code.

There's another approach, which is more work upfront, but is probably
worth it anyway.  The way Guido deals with the enormity of Python
development is that his source is very modular.  There are core bits
that he cares very deeply about, and will not commit to unless he's
read every line.  He'll nitpick over minor details until the patch is
just right.  That's a good thing because you want to be sure the
critical stuff is clean, consistent, robust, etc.

But enough of the code is modular so that he doesn't have to look at
every line of the Python library, or peripheral objects or modules.
Sure, sometimes patches will break things, but that usually comes out
during beta testing, and besides if they're really broken it doesn't
hose Python completely.

We aren't there with Mailman; there is much too much interdependence
in the code base.  It would be a lot of work to separate components
out so that people can work on them independently.  And Mailman the
same kind of project as Python, so there's a limit to how much
modularity can be had.

Anyway, I'm rambling, but I'm glad you guys are talking about this
stuff.  I want to do anything I can to maintain the longterm viability
of Mailman, and the usefulness of the program outside python.org.  As
long as I'm webmaster over here, I'm sure I'll be using Mailman, but
my own personal requirements may not completely coincide with
y'all's.  So its good to hear what your ideas are.

Thanks,
-Barry