Greg:
When you work on accepting and merging patches, do you use a single tree
for all the changes or do you have separate trees for usb, pci, i2c, and
so on? If you use a single tree then there's no real choice but to export
all the patches together -- cherry-picking the subsets will inevitably
lead to inconsistencies. Personally I wouldn't mind having to download
patches for the multiple subsystems. It's worth it to be sure of getting
a consistent patchset.
On the other hand, if you really do keep the different areas separate
while working on them (which would force Andrew Morton to do the necessary
reconciliation, right?) then the patches you export also need to be kept
totally separate. Having a single "series" file might work but it
wouldn't be a good idea.
I would like to see incremental patches exported in addition to the
cumulative patch file. Here's how it could be made to work. For the sake
of argument I'll assume that all the usb, pci, i2c, etc. patches come from
the same tree. (If not, this scheme could apply to each of the separate
trees.)
In the top-level directory there should be a file named "base" containing
a single line with two fields, a release name and a patchset increment
number, like this:
2.6.12-rc2 5
The scripts (on both your end and my end) can read this at startup, and
the increment number can be rewritten by your daily update script.
In patches/series, your script should maintain subdivisions indicating
where each increment ends. These are in the form of comment lines,
something like:
#=== 5
which would indicate where the patches for increment 5 end and the patches
for increment 6 begin. The update script can automatically append the
appropriate comment to this file in preparation for the next set of
patches.
Finally, the script could produce incremental patches as well as the
cumulative patch. These can be stored in the top-level directory, with
names like
gregkh-2.6.12-rc2-4-5.patch
gregkh-2.6.12-rc2-5.patch
for the incremental and cumulative patches, respectively. (You might even
want to bzip2 them.)
In a typical run of the update script, here's what would happen. The
script starts by reading the current release name and increment number
from ./base. Let's say the current increment is 5. Then the script
unpacks the base 2.6.12-r2 tree, makes a hard-linked copy, and applies the
-5 cumulative patch. It then makes a second hard-linked copy of that, and
applies all the patches in the patches/series file following the "#=== 5"
line.
Next the script calculates the diff between the first and third trees,
storing it as the cumulative -6 patch, and it calculates the diff between
the second and third trees, storing it as the incremental -5-6 patch. It
rewrites ./base, updating the increment number to 6, appends the "#=== 6"
delimiter line to patches/series, and erases the -5 cumulative patch file.
Finally the three temporary trees are removed.
Something like this would provide maximum flexibility, convenience, and
opportunities for automation on my side. My scripts could easily keep
track of what was new and apply only the necessary patches.
What do you think?
Alan Stern
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
