On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Andrew was looking for someone to run a linux-next tree that just
> contained the subsystem git and quilt trees for 2.6.x+1 and I (in a
> moment of madness) volunteered. So, this is to announce the creating of
> such a tree (it doesn't exist yet) which will require some (hopefully)
> small amount of work on the part of subsystem maintainers.
>
> Those interested in discussion about this are encouraged to join the
> [EMAIL PROTECTED] mailing list.
>
> The first things I need from the subsystem maintainers (you know who you
> are) are a contact address (a list address is fine) and at least one git
> branch or quilt series that contains all the things you want to see go
> into 2.6.26.
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.
> I am happy for there to be multiple branches/series (in
> fact there probably will need to be in some cases where there are
> dependencies on others work).
>
> The tree will be based on the current version of Linus' tree but you may
> specify an earlier branch point if you need to (hopefully not - but more
> likely for quilters, I guess).
>
> I hope to recreate this tree every day automatically. In order to do
> this, any tree that has a conflict will be dropped from that days tree.
Oh oh oh, I get merged first! me me me!
> The maintainer will be notified. I hope to provide some clue as to what
> the conflict is with, but probably not initially.
>
> I will attempt to build the tree between each merge (and a failed build
> will again cause the offending tree to be dropped).
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.
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.
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 :)
Good luck,
greg k-h
[1] Hopefully the "multiple drivers for a single device" feature people
have been asking for for years will be landing soon, of course the
number of odd places in the kernel that made the assumption that we
could only have one driver per device is causing lots of fun...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
