lkml.org 
[lkml]   [2008]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Announce: Linux-next (Or Andrew's dream :-))
    On Mon, 11 Feb 2008 20:21:33 -0800 Greg KH <greg@kroah.com> 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 sfr@canb.auug.org.au
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2008-02-12 06:09    [W:0.022 / U:61.512 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site