At 18:21 07/02/2003, Marilyn Davis wrote:

Hi Mailmen and Mailwomen,

If I fix up a patch for 2.1 so that eVote works with it, some administrators will want it and some won't.

What happens when new Mailman patches come along for 2.1+? Will I have to make a new patch for each patch?

Please forgive my ignorance.

Marilyn

I have some enhancement patches for MM that have yet to be adopted for inclusion in the main development line; may never be. If it will help I'll describe how I've been doing things although the real Mailman developers may have a different take on things

Thus far I have maintained my patches as follows:

1. When a new numbered or beta release of MM comes out I try applying my patches for the previous numbered release.

2. If it applies without complaint and tests out as working I just add a comment to the sourceforge page for the patch telling people that patch file name abc works with MM version x.y.z

3, If the patch will not apply without complaint or it fails my testing I fix things and generate a new version of the patch. I then upload the revised patch + a comment to the sourceforge page for the patch. Fixing things can include creating a whole new precursor patch if it is to correct a bug in the Mailman numbered release code that I've just tripped over rather than a defect in the code my patch adds.

I normally generate the patches by doing a recursive diff between a directory structure of either the vanilla MM release or that + any necessary precursor patches applied, and the directory structure of the MM release plus my changes. I guess I could use RCS/CVS branches for some of this but thus far I haven't got my head round solving the problem that way.

My current worst case is a patch #444884 which requires three precursor patches. #444879 which is an enhancement patch and #668685, which fixes a new bug that appeared in MM 2.1. Patch #44879 in turn depends on patch #661138 which fixes different issues that also appeared in MM 2.1 final. The patch generation sequence goes like this:

diff -r -u -P mailman-2.1/ mailman-2.1-driver/ > driver-2.1-0.1.patch diff -r -u -P mailman-2.1/ mailman-2.1-tfix/ > templates-2.1-0.1.patch diff -r -u -P mailman-2.1-tfix/ mailman-2.1-index/ > indexing-2.1-0.1.patch diff -r -u -P mailman-2.1-index/ mailman-2.1-htdig/ > htdig-2.1-0.3.patch

and the patch application sequence goes like this:

zcat distributions/mailman-2.1.tgz | tar xf - mv mailman-2.1 mailman-2.1-run cd mailman-2.1-run/ patch -p1 < ../patches/current/driver-2.1-0.1.patch patch -p1 < ../patches/current/templates-2.1-0.1.patch patch -p1 < ../patches/current/indexing-2.1-0.1.patch patch -p1 < ../patches/current/htdig-2.1-0.3.patch

The reason I've done things this way is I want to separate patches that add discrete chunks of enhancement from fixes to generic problems I've identified in baseline MM while developing the enhancements. This way I'm in with a shout of persuading Barry Warsaw to add the bug fixes to the Mailman CVS at some point, even if he won't accept the enhancements so readily. Hopefully, and over time, my patches to fix MM bugs go away even if I'm left with the maintenance of the enhancement patch(es). That's better than polluting my enhancement patches with general bug fix stuff and then having to rip that out if its fixed in a new numbered release.

In the case of the example, I split my original work into a fairly generic patch #444879 and a more specialised one #444884. Again this was with the hope that the more generic patch had a better chance of making it into the CVS ahead of the more specialised stuff.

I do not even attempt to publish patches for MM CVS; its too much like trying to shoot skeet with a rifle. As far as I'm concerned the sort of adventurous people that run from the CVS have to make do with patches for the most recent numbered (or beta) release and do their own manual fixing of rejected patch elements

After fumbling around at the start, I adopted a patch file naming convention (see example) where the first number group is the version of Mailman the patch applies to and the second number group is the evolution/version number of the patch applicable to that MM version; adrift in sourceforge's repository is htdig-2.0.8-0.1.patch and htdig-2.0.13-0.4.patch, as well as the most recent htdig-2.1-0.3.patch.

Its a bit of a chore maintaining patches for MM across new releases but I do it because I need the changes for my own use and the discipline of having to keep up to date and publish for other users is good for my soul. In practice it means I can build my MM server systems from cold almost automatically to the patch state I want them to run at (the patch application lines above come out of the script that does this).

I've been trying to get out revised patches after just a few days of a new numbered or beta release hitting the stree, but not always with success.

I do not know of any way of avoiding conflicts with other patches that people might want to apply to same version of MM as my patches. I make it clear if my patches have necessary precursors and aim for no problems/warnings when running the patch command. I take the view that if people are mixing and matching a lot of different patches and this leads to patch command warnings or errors, then the person concerned has to contribute to their own salvation; although I'm willing to advise or help. How big a problem this is depends on how pervasive your changes are; so far I seem to have been fairly lucky on this score.

Sorry to rattle on at such length when you probably have all of this scoped out. Still, if its saves you some work along the way ...

I had put your post to mailman-users to one side as a reminder to investigate eVote further. If the MM 2.1 version is likely to be available in the near future, it will suit me better than having to regress my test system to MM 2.0.13 in order to try out eVote.

Best of luck.