On Mon, 11 Feb 2008 20:21:33 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > > Note that a lot of these are already in the MAINTAINERS file. > > But for the record, here's mine, in the order they need to be pulled > from. > Driver core: > kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/ > PCI: > kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-02-pci/ > USB: > kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-03-usb/ > > These are all quilt trees, with the series file in the directory for the > order of the patches, and a README saying what kernel version they have > been rebased against.
Thank you. Over time we might think about some sort of standard for these. > Oh oh oh, I get merged first! me me me! What's it worth to you? :-) > This is going to get really interesting, especially when (not if) we do > more global api changes. Look at the last round of kobject changes. > That touched a lot of different places, and other trees ended up not > building because of it, because I changed apis and they had added new > code based on the old apis. This is one of the things that linux-next will hopefully let us discover more easily/faster. > I think the only way to fix this is not going to just "drop the tree" > like you are suggesting, but to let both people know (the person who > caused the change, and the person who's tree broke after the merge), and > then either add a "fixup patch" for the build like Andrew has been > doing, or disabling something from the build section. Right. Except that "drop the tree" will probably only mean for a day or so i.e. it will be taken out of the current round but will reappear automatically when the conflict/dependency is sorted out. > As I know I'm going to be changing more driver core apis[1] this week, > I'm sure we will get a very good set of examples of this for you to see > in action :) Excellent! However, I am hoping that these global api changes may be introduced in a more orderly fashion (some of which is happening already) by creating new api's and then switching to them (and them maybe changing the names back if necessary). And, yes, I realise that this is sometimes not possible (or at least not worth the extra effort). > Good luck, Thanks, I will probably need it :-( -- Cheers, Stephen Rothwell [EMAIL PROTECTED]
pgplwugAxf4NN.pgp
Description: PGP signature
