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