Re: Results after talking with Barry

>>>>> "FWH" == Fred Wilson Horch <[email protected]> writes:

    FWH> I hear Barry likes the idea of using Mailman 2.1. ;-)

Naw, what makes you think that? :)

    FWH> Sounds like the goal is NOT to do just a quick and dirty
    FWH> hack, and NOT to fork Mailman, but to write code that will
    FWH> become a part of the Mailman distribution, possibly starting
    FWH> in Mailman 2.1.

Whatever is going to go into MM2.1 has got to happen soon.  My goal is
to release MM2.1 by the Python conference in February.  That isn't
much time, so I've got to get to beta this month.  Once beta hits,
we'll be in feature freeze.

    FWH> It also sounds like the Mailman hackers welcome zmailman as a
    FWH> contribution to their efforts.

Absolutely.  

    FWH>  1) A branch on the Mailman CVS for zmailman.  This will
    FWH> provide one central repository for all design docs and code
    FWH> for our project.  If you want my help, I'll need everything
    FWH> in one place so that I can do a cvs checkout and updates to
    FWH> stay up to date with what is going on.

When it's necessary, we'll add a branch.  Branching adds all sorts of
nasty complications, so I'd like to avoid this for as long as
possible, preferrably after 2.1 is released (but then we won't need
the branch ;).  I think there's a lot that needs to happen before a
branch is required.

    FWH>  2) An announcement on the appropriate mailing lists that
    FWH> this project is happening.  This will be an opportunity to
    FWH> recruit some more folks, and spread the word about the goal
    FWH> of the zmailman project.  I think we need something on
    FWH> zope-dev and on the main mailman development list, whatever
    FWH> it is called.  We might also want to make an announcement on
    FWH> a Python list.  I think we need more person hours to make
    FWH> this project happen.  In order to get those hours, we have to
    FWH> let people know what we're doing and how they can help.

Stephan has already posted some announcements, and by now
mailman-developers know.  I think everybody who can contribute is
informed.

    FWH>  3) Space on the Mailman web site.  In addition to the CVS
    FWH> branch, we need a place for our project description, download
    FWH> packages, screen shots, etc.  If we're not going to fork, we
    FWH> should use the Mailman web site instead of Sourceforge or
    FWH> some other random site.  If getting write access to the
    FWH> Mailman web site is impossible, we should at least get a link
    FWH> from the Mailman web site to our own web site.

www.list.org is fairly static, not at all a good place to store our
artifacts.  Let's use the Mailman wiki instead:

    http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage

I've created a MailmanOnZope link where the discussion and artifacts
can be stored.  I'm happy to add a link to the static Mailman pages
pointing here, although it should be fairly easy to find.

    FWH>     I suppose we should also put something on a Zope web site
    FWH>     somewhere, since zmailman is ultimately just a Zope product.
    FWH>     But I understand that zope.org is due for a major overhaul,
    FWH>     so maybe we could wait on that one.

I think the Wiki is a good place to start for now.

    FWH> I assume the UML is a diagram of the data structures of
    FWH> Mailman.  Does this mean that the data structures of Mailman
    FWH> are currently undocumented, or is the UML some special way to
    FWH> document the data structures that will shed goodness and
    FWH> light on zmailman?

They're documented in the fine open source tradition of UTSL.

    FWH> Maybe the first thing would be for someone to summarize the
    FWH> current state of Mailman 2.1.  Here are my questions:

    |  1) Is there a project plan for Mailman 2.1?

Finish it up, get it out. :)

    |  2) What are the design goals for 2.1?

Originally, it was support i18n.  It's gone on to include lots of new
features, bug fixes, improvements, etc.  Time is nearing to put a fork
in it.

    |  3) Who is working on 2.1?

Me, basically.  With contributions from the community.

    |  4) When will 2.1 'final' be released?

When people stop asking for new features <wink>.  :)

Seriously, I'd like it to be done by IPC10.  We'll see.

    FWH> I also want to understand the 'Z' in zmailman.  (By the way,
    FWH> can we use all lowercase for ZMailman or is that a faux pas?)

If it were up to me, "ZMailman".

    FWH> Which version of Zope are we targeting?

Good question.  Zope3 would be ideal, but that's so far off, I think
Stephan has said that he's targeting Zope 2.5.

    FWH> Just to be brutally self-centered, let me say at the outset
    FWH> that I'm going to be splitting my cycles on Zope / Mailman
    FWH> stuff between zmailman and our own internal project at
    FWH> EcoAccess to just get the darn thing working already (i.e.,
    FWH> calling the Mailman CGI scripts through a Zope external
    FWH> method that will work with Zope 2.3.3).

I think that's fine, since we know you want to stick with Python
1.5.2.

    FWH> I just want to make sure I understand the goal for zmailman,
    FWH> namely that we will produce a product for Zope 2.5.0 or
    FWH> better that works with Mailman 2.1 or better.  Thus, we are
    FWH> shooting at two moving targets (not to mention the moving
    FWH> target of Python 2.x underneath it all).  Should be
    FWH> interesting!

Hopefully not in the Chinese fortune cookie sense of the word.  Should
be fun at least!

    FWH>  1) Project participants be given write access to a CVS
    FWH> repository, preferably a branch on the Mailman CVS server so
    FWH> we can begin checking in code to a central location.

When it's necessary.  If you think I'm a bottleneck then my suggestion
would be to start a short lived SF project for the prototyping, with
the understanding that it will eventually be merged into the main
codebase.  We've done this with the StandaloneZODB project, so I think
that will work.

    FWH>  2) Someone write up the "official" project announcement
    FWH> (including the goals of the project and the fact that the
    FWH> Mailman folks think this is a Good Thing) and post it
    FWH> everywhere potential developers and / or paying clients might
    FWH> be lurking.

Fill out the Wiki, then we can post links to it.

    FWH>  3) Someone write up some HTML pages to create an online
    FWH> presence for the project, and link those pages in to the main
    FWH> Mailman web site.  We need to think through what zmailman
    FWH> will do for people, and explain it on the project pages.

The wiki is already linked from the static pages, so that's probably
enough for now.

-Barry