[Mailman-Users] CVS branches?

[Barry A. Warsaw]

>>>>> "ES" == Ellen Spertus <spertus at mills.edu> writes:

    ES> incorporated into Mailman.  It seems my choices are: - working
    ES> from a snapshot (what I've been doing) - getting my own CVS
    ES> branch

I personally do not believe that long-lived branches work well in
cvs.  Everytime we've tried them, in Mailman, Python, or other
projects, it ends up being a near-impossible nightmare to eventually
merge them back into the main branch.  CVS brances work well if
they're short-lived or not intended to be merged (e.g. a
2.0-maintenance branch).

In addition, MM2.1 is so long overdue that I've got to be brutal in
adding new code to the current trunk, or it'll never get out.  Also, I
strongly believe in feature freezes for betas.  I recently rewrote the
mail command handler stuff for MM2.1b2 but that was mostly because
what was there was severely broken and there was just no way to fix
the problems without a rewrite.  The code ended up smaller and more
modular, so the added features were just gravy.  I've always had a
sneaking suspicion that I'd have to bite this bullet before the 2.1
release.

That all having been said, I also know how much of a pain it is to
continually port your patches as the trunk develops.  I've been on the
other side! :)  Ideally, we'd find ways to architect the system so
that add-ons don't require fundamental changes to the code -- they'd
be largely drop in additions or replacements.  Some of Mailman is well
suited to that approach, and we can improve things in future releases.

I'd be willing to talk about branches and opening up write access to
more people after 2.1 goes out.  I'm sure there will be a 2.1-maint
branch, but I haven't decided how to structure cvs for the MM3
effort.  Should we plan on a MM2.2 with more modest goals and
features?  Should MM3 development happen on the trunk or a branch?
Etc.  All good reasons to finally kick 2.1 out the door asap.

-Barry