[Mailman-Developers] Patching question

[Richard Barrett]

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.