Messages in this thread |  | | | Date | Sat, 6 Mar 2010 23:19:20 -0500 (EST) | | From | Alan Stern <> | | Subject | The gregkh patch scripts |
| |
Greg:
Are the scripts you use for creating the various gregkh-*.patch files stored in
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/scripts/
? Those files appear not to have been updated for quite some time.
Regardless, the way the current scripts work has got a problem. As far as I can tell, they take Linus's current tree, apply your various accumulated quilt series files, and then compute the diff between the end result and the starting point. The output is labelled with name of the starting tree. (If my understanding is wrong then tell me so and ignore the rest of this message.)
The problem is that Linus's current tree is not a good starting point. For example, right now several of the individual files such as gregkh-07-usb-2.6.33.patch are completely empty. This is because you have sent all the pending changes upstream, so they are now included in Linus's tree and hence they don't show up in a diff.
But... The file is still named "gregkh-07-usb-2.6.33.patch", even though it isn't a patch against 2.6.33 -- it's a patch against whatever Linus's tree happened to contain at the time you ran the script. Since I don't know what tree that was (and I don't have git repository for the kernel anyway), I can't use the patch file. (Well, I _can_ use it because it's empty, but it doesn't do me any good -- the principle is still valid.)
As Linus has explained to quite a few people, this isn't a good way to operate. What your scripts do is essentially the same as rebasing a publicly-exported git repository, which should be done relatively infrequently. It's okay to rebase against the actual releases and the *-rcN trees, because they are well-defined intermediate points. But rebasing against a *-rcN-gitM should be quite rare, and rebasing against anything else is basically forbidden.
This means the scripts shouldn't start with the vanilla tree-of-the-moment. They should start with the most recent release or -rcN tag. In rare cases they could use an rcN-gitM tag, but only if there's a good reason.
So for example, the current gregkh-*-2.6.33.patch files should be quite large, because they should contain all the accumulated development for the last three months that hasn't gotten into 2.6.33. When 2.6.34-rc1 is released then the files should get small, since they would then contain only material that was submitted slightly before or during the merge window.
Can the scripts be updated to work in this way?
Alan Stern
|  |