git trees which are not yet in linux-next - Kernel

This is a discussion on git trees which are not yet in linux-next - Kernel ; git-cifs: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git git-gfs2-nmw: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-nmw.git git-ieee1394: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git#for-mm git-jg-misc: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git#irq-remove git-libata-all: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-2.6.git git-mips: git://git.linux-mips.org/pub/scm/upstream-akpm.git#mips-for-mm git-mmc: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git#for-andrew git-udf: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jack/linux-udf-2.6.git#for_mm git-battery: git://git.infradead.org/battery-2.6.git git-block: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git#for-akpm git-v9fs: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git#v9fs-devel git-watchdog: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog-mm.git git-xtensa: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/czankel/xtensa-2.6.git#testing git-orion: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/nico/orion.git git-pekka: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git#for-mm (This list is probably incomplete - there might be other ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 29

Thread: git trees which are not yet in linux-next

  1. git trees which are not yet in linux-next


    git-cifs: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git

    git-gfs2-nmw: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-nmw.git

    git-ieee1394: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git#for-mm

    git-jg-misc: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git#irq-remove

    git-libata-all: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-2.6.git

    git-mips: git://git.linux-mips.org/pub/scm/upstream-akpm.git#mips-for-mm

    git-mmc: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc.git#for-andrew

    git-udf: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jack/linux-udf-2.6.git#for_mm

    git-battery: git://git.infradead.org/battery-2.6.git

    git-block: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git#for-akpm

    git-v9fs: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git#v9fs-devel

    git-watchdog: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog-mm.git

    git-xtensa: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/czankel/xtensa-2.6.git#testing

    git-orion: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/nico/orion.git

    git-pekka: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git#for-mm


    (This list is probably incomplete - there might be other trees which are
    presently empty but which aren't in linux-next yet)

    (Jeff, git-libata-all is a pretty important one)

    Guys, could you please prepare a tree for Stephen and send the details
    over to him? Please Cc me also.

    Once this has happened, there should be no need to run a separate for-mm
    branch. I'll just switch over to using whatever branch linux-next is
    using.

    I'll continue to pull all the git trees, although I'll expect to drop them
    again. I will do this to keep my list of git URLs fresh. So if for some
    reason linux-next isn't getting updated I can drop it and switch back to
    the individual git trees.


    I don't yet know how I'll get along basing -mm on linux-next. The first
    problem is working out "how the heck did that patch get into linux-next"?
    That would be much easier if the signoff trail was complete for git-based
    patches, but it often is not.

    Thanks.

    (git-unionfs and such things will remain -mm-only)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: git trees which are not yet in linux-next

    Andrew Morton wrote:
    > (Jeff, git-libata-all is a pretty important one)



    libata-dev.git#NEXT is for linux-next, and libata-dev.git#ALL is for -mm

    Already taken care of.

    Jeff


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: git trees which are not yet in linux-next

    On Fri, 2 May 2008 15:12:06 -0700
    Andrew Morton wrote:

    > The first
    > problem is working out "how the heck did that patch get into linux-next"?
    > That would be much easier if the signoff trail was complete for git-based
    > patches, but it often is not.


    doh. I'm pulling linux-next's constituent trees independently, so if I
    spot a turd in linux-next I can just grep the various git trees to find out
    where it came from.

    It seems wrong though...
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: git trees which are not yet in linux-next

    On Fri, 02 May 2008 18:20:26 -0400
    Jeff Garzik wrote:

    > Andrew Morton wrote:
    > > (Jeff, git-libata-all is a pretty important one)

    >
    >
    > libata-dev.git#NEXT is for linux-next, and libata-dev.git#ALL is for -mm
    >
    > Already taken care of.
    >


    Oh. Something seems to have gone wrong then.

    Next/Trees has:

    libata git git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git#NEXT

    but:

    y:/usr/src/25> diffstat patches/linux-next.patch | grep /ata/
    y:/usr/src/25>

    There's nothing there?

    (plans for git-jg-misc?)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: git trees which are not yet in linux-next

    Andrew Morton wrote:
    > git-ieee1394: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git#for-mm


    Stephen pulls linux1394-2.6.git#for-next.

    > Guys, could you please prepare a tree for Stephen and send the details
    > over to him? Please Cc me also.
    >
    > Once this has happened, there should be no need to run a separate for-mm
    > branch. I'll just switch over to using whatever branch linux-next is
    > using.


    -mm is going to become identical in content to -next?
    --
    Stefan Richter
    -=====-==--- -=-= ---==
    http://arcgraph.de/sr/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: git trees which are not yet in linux-next

    Andrew Morton wrote:
    > On Fri, 2 May 2008 15:12:06 -0700
    > Andrew Morton wrote:
    >
    >> The first
    >> problem is working out "how the heck did that patch get into linux-next"?
    >> That would be much easier if the signoff trail was complete for git-based
    >> patches, but it often is not.

    >
    > doh. I'm pulling linux-next's constituent trees independently, so if I
    > spot a turd in linux-next I can just grep the various git trees to find out
    > where it came from.
    >
    > It seems wrong though...


    What about the committer info? Well, I suppose a nobody@localhost slips
    in, but more often I expect it to be something more telling than that.
    --
    Stefan Richter
    -=====-==--- -=-= ---==
    http://arcgraph.de/sr/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: git trees which are not yet in linux-next

    On Sat, 03 May 2008 03:11:25 +0200 Stefan Richter wrote:

    > Andrew Morton wrote:
    > > git-ieee1394: git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git#for-mm

    >
    > Stephen pulls linux1394-2.6.git#for-next.
    >
    > > Guys, could you please prepare a tree for Stephen and send the details
    > > over to him? Please Cc me also.
    > >
    > > Once this has happened, there should be no need to run a separate for-mm
    > > branch. I'll just switch over to using whatever branch linux-next is
    > > using.

    >
    > -mm is going to become identical in content to -next?


    -mm will be (and now is)

    origin.patch
    linux-next.patch


    Where "other patches" includes git trees which aren't in linux-next.

    So yes, you should drop #for-mm and add #for-next.

    I will pull your #for-next brach daily, but I'll only include it (as
    git-ieee1394.patch) if for some reason linux-next.patch needed to be
    dropped.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: git trees which are not yet in linux-next

    On Sat, 03 May 2008 03:19:00 +0200 Stefan Richter wrote:

    > Andrew Morton wrote:
    > > On Fri, 2 May 2008 15:12:06 -0700
    > > Andrew Morton wrote:
    > >
    > >> The first
    > >> problem is working out "how the heck did that patch get into linux-next"?
    > >> That would be much easier if the signoff trail was complete for git-based
    > >> patches, but it often is not.

    > >
    > > doh. I'm pulling linux-next's constituent trees independently, so if I
    > > spot a turd in linux-next I can just grep the various git trees to find out
    > > where it came from.
    > >
    > > It seems wrong though...

    >
    > What about the committer info? Well, I suppose a nobody@localhost slips
    > in, but more often I expect it to be something more telling than that.


    Beats me. To pick one example:

    commit 1a72963d3af38eb17a939fc19b322735da1c0aad
    Author: Matthew Wilcox
    Date: Fri Apr 25 12:38:41 2008 -0400

    Convert board-nokia770 from semaphore to spinlock

    None of the operations done under the semaphore could sleep, so a spinlock
    is more appropriate to this case.

    Signed-off-by: Matthew Wilcox

    There's no sign how that got there. A bit of forensics shows up:

    semaphore-removal git git://git.kernel.org/pub/scm/linux/kernel/git/willy/misc.git#semaphore-removal

    in Next/Trees. I don't actually have that tree in -mm, which is a bit
    unusual. Otherwise a grep for `Convert board-nokia770 from semaphore to
    spinlock' would have found it.

    Oh well, don't worry - I'll work it out


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: git trees which are not yet in linux-next

    Hi Andrew,

    On Fri, 2 May 2008 15:33:01 -0700 Andrew Morton wrote:
    >
    > On Fri, 02 May 2008 18:20:26 -0400
    > Jeff Garzik wrote:
    >
    > > Andrew Morton wrote:
    > > > (Jeff, git-libata-all is a pretty important one)

    > >
    > > libata-dev.git#NEXT is for linux-next, and libata-dev.git#ALL is for -mm
    > >
    > > Already taken care of.

    >
    > Oh. Something seems to have gone wrong then.
    >
    > Next/Trees has:
    >
    > libata git git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git#NEXT
    >
    > but:
    >
    > y:/usr/src/25> diffstat patches/linux-next.patch | grep /ata/
    >
    > There's nothing there?


    This just means that everything that Jeff expected to go into 2.6.26 is
    not in Linus' tree, right? And he hasn't moved his 2.6.27 expectations
    into linux-next yet (after all we are still in the 2.6.26 merge window).

    --
    Cheers,
    Stephen Rothwell sfr@canb.auug.org.au
    http://www.canb.auug.org.au/~sfr/

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFIG+skTgG2atn1QN8RAvJPAJwOVFM2tjWz4WAdyEWa73 1u2J5bgACffuZb
    rIvXLn5zUy49pVhAOjht92E=
    =z87C
    -----END PGP SIGNATURE-----


  10. Re: git trees which are not yet in linux-next

    Andrew Morton wrote:
    > On Sat, 03 May 2008 03:19:00 +0200 Stefan Richter wrote:
    >
    >> Andrew Morton wrote:
    >>> On Fri, 2 May 2008 15:12:06 -0700
    >>> Andrew Morton wrote:
    >>>
    >>>> The first
    >>>> problem is working out "how the heck did that patch get into linux-next"?
    >>>> That would be much easier if the signoff trail was complete for git-based
    >>>> patches, but it often is not.
    >>> doh. I'm pulling linux-next's constituent trees independently, so if I
    >>> spot a turd in linux-next I can just grep the various git trees to find out
    >>> where it came from.
    >>>
    >>> It seems wrong though...

    >> What about the committer info? Well, I suppose a nobody@localhost slips
    >> in, but more often I expect it to be something more telling than that.

    >
    > Beats me. To pick one example:
    >
    > commit 1a72963d3af38eb17a939fc19b322735da1c0aad
    > Author: Matthew Wilcox
    > Date: Fri Apr 25 12:38:41 2008 -0400
    >
    > Convert board-nokia770 from semaphore to spinlock
    >
    > None of the operations done under the semaphore could sleep, so a spinlock
    > is more appropriate to this case.
    >
    > Signed-off-by: Matthew Wilcox
    >
    > There's no sign how that got there. A bit of forensics shows up:


    Poke through the man pages, particularly git-log, and tell it to spit
    out the committer info, then. It's in there.

    For example,

    git log --pretty=full

    produces

    commit c4d0f8cbca3a97900f85b082064a63c7a5928bd7
    Author: Alan Cox
    Commit: Greg Kroah-Hartman

    usb_serial: some coding style fixes

    Signed-off-by: Alan Cox
    Signed-off-by: Greg Kroah-Hartman

    Regards,

    Jeff



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: git trees which are not yet in linux-next

    Andrew Morton wrote:
    > On Fri, 02 May 2008 18:20:26 -0400
    > Jeff Garzik wrote:
    >
    >> Andrew Morton wrote:
    >>> (Jeff, git-libata-all is a pretty important one)

    >>
    >> libata-dev.git#NEXT is for linux-next, and libata-dev.git#ALL is for -mm
    >>
    >> Already taken care of.
    >>

    >
    > Oh. Something seems to have gone wrong then.
    >
    > Next/Trees has:
    >
    > libata git git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git#NEXT
    >
    > but:
    >
    > y:/usr/src/25> diffstat patches/linux-next.patch | grep /ata/
    > y:/usr/src/25>
    >
    > There's nothing there?


    Correct. There is presently nothing waiting for linux-next.


    > (plans for git-jg-misc?)


    That's an ever-present bucket with ever-changing contents. I put stuff
    in there when I have things for -mm testing, and hopefully, eventually
    upstream.

    Sometimes jgarzik/misc-2.6.git#ALL might be empty (like libata-dev#NEXT
    is now), sometimes not.

    The general point is to make sure both you and Stephen are pulling the
    right branches, which is sounds like you are.

    Jeff



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: git trees which are not yet in linux-next

    Jeff Garzik wrote:
    >>> Andrew Morton wrote:
    >>>> On Fri, 2 May 2008 15:12:06 -0700
    >>>> Andrew Morton wrote:
    >>>>
    >>>>> The first
    >>>>> problem is working out "how the heck did that patch get into
    >>>>> linux-next"? That would be much easier if the signoff trail was
    >>>>> complete for git-based
    >>>>> patches, but it often is not.
    >>>> doh. I'm pulling linux-next's constituent trees independently, so if I
    >>>> spot a turd in linux-next I can just grep the various git trees to
    >>>> find out
    >>>> where it came from.

    ....
    > Poke through the man pages, particularly git-log, and tell it to spit
    > out the committer info, then. It's in there.
    >
    > For example,
    >
    > git log --pretty=full

    ....

    Of course some committers have more than one tree in -next. So if
    Andrew wants to know the actual tree, the laziest method which I know of is
    $ gitk

    Among else, gitk shows which branches contain the commit. (How to do
    this without X GUI?)
    --
    Stefan Richter
    -=====-==--- -=-= ---==
    http://arcgraph.de/sr/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: git trees which are not yet in linux-next

    On Sat, 03 May 2008 10:46:39 +0200 Stefan Richter wrote:
    >
    > Of course some committers have more than one tree in -next. So if
    > Andrew wants to know the actual tree, the laziest method which I know of is
    > $ gitk
    >
    > Among else, gitk shows which branches contain the commit. (How to do
    > this without X GUI?)


    Unfortunately, this will not work either as I do not export to the public
    tree the heads of each of the branches that I merge. It does work in my
    tree until I do the next update.

    However, if you look at the closest following merge that is committed by
    me, that will tell you which branch the commit was on.

    --
    Cheers,
    Stephen Rothwell sfr@canb.auug.org.au
    http://www.canb.auug.org.au/~sfr/

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFIHlJbTgG2atn1QN8RAo7YAJwIsnqT909BYWkq94062Z MV6B+pVQCfYk5e
    IHcXlcueXaw3f2e8r97pIy0=
    =mODf
    -----END PGP SIGNATURE-----


  14. Re: git trees which are not yet in linux-next

    On Fri, 2008-05-02 at 15:12 -0700, Andrew Morton wrote:

    >
    > (This list is probably incomplete - there might be other trees which are
    > presently empty but which aren't in linux-next yet)


    Any chance the voltage/current regulator tree could be added :-

    git-regulator: git://opensource.wolfsonmicro.com/linux-2.6-audioplus.git#for-akpm

    Thanks

    Liam

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: git trees which are not yet in linux-next

    On Mon, 05 May 2008 17:52:16 +0100
    Liam Girdwood wrote:

    > On Fri, 2008-05-02 at 15:12 -0700, Andrew Morton wrote:
    >
    > >
    > > (This list is probably incomplete - there might be other trees which are
    > > presently empty but which aren't in linux-next yet)

    >
    > Any chance the voltage/current regulator tree could be added :-
    >
    > git-regulator: git://opensource.wolfsonmicro.com/linux-2.6-audioplus.git#for-akpm
    >


    Yup, I added that, thanks.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: git trees which are not yet in linux-next

    Hi Andrew,

    On Sat, May 3, 2008 at 1:12 AM, Andrew Morton wrote:
    > Guys, could you please prepare a tree for Stephen and send the details
    > over to him? Please Cc me also.
    >
    > Once this has happened, there should be no need to run a separate for-mm
    > branch. I'll just switch over to using whatever branch linux-next is
    > using.


    I was looking at preparing a for-next branch for the SLAB tree but I'm
    not sure I understand the above. For something like the slab
    allocator, you want as much exposure as possible before asking Linus
    to pull so I would like to continue to (ab)use -mm for testing as
    well. But that doesn't seem to fit the linux-next rules at all...

    So what to do here? I don't have a problem with maintaining separate
    branches for mm and next where the latter is not going to get much
    action until very late in the release cycle when I'm preparing for the
    next merge window.

    Pekka
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: git trees which are not yet in linux-next

    On Mon, 5 May 2008 21:16:12 +0300
    "Pekka Enberg" wrote:

    > Hi Andrew,
    >
    > On Sat, May 3, 2008 at 1:12 AM, Andrew Morton wrote:
    > > Guys, could you please prepare a tree for Stephen and send the details
    > > over to him? Please Cc me also.
    > >
    > > Once this has happened, there should be no need to run a separate for-mm
    > > branch. I'll just switch over to using whatever branch linux-next is
    > > using.

    >
    > I was looking at preparing a for-next branch for the SLAB tree but I'm
    > not sure I understand the above. For something like the slab
    > allocator, you want as much exposure as possible before asking Linus
    > to pull so I would like to continue to (ab)use -mm for testing as
    > well. But that doesn't seem to fit the linux-next rules at all...


    You have stuff in your tree which isn't intended for 2.6.27??

    > So what to do here? I don't have a problem with maintaining separate
    > branches for mm and next where the latter is not going to get much
    > action until very late in the release cycle when I'm preparing for the
    > next merge window.


    I don't mind, really - just do what you think is best for your subsystem
    and then tell me and Stephen about it. We'll only notice if you break
    stuff

    So I'd suggest that you have a #for-next which contains material for 2.6.26
    and 2.6.27 and a #for-mm which contains material for 2.6.28+.

    Only problem is, I'd need to generate the #for-next -> #for-mm diff, and
    that particular git operation has been troublesome in the past.

    otoh, I think that staging for-2.6.26 and for-2.6.27 material in -mm really
    is reaching far enough into the future, and I'd question the value of
    staging for-2.6.28+ material as well. I mean, that's half a year away.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: git trees which are not yet in linux-next

    On Mon, 5 May 2008 21:16:12 +0300
    "Pekka Enberg" wrote:
    > > I was looking at preparing a for-next branch for the SLAB tree but I'm
    > > not sure I understand the above. For something like the slab
    > > allocator, you want as much exposure as possible before asking Linus
    > > to pull so I would like to continue to (ab)use -mm for testing as
    > > well. But that doesn't seem to fit the linux-next rules at all...


    On Mon, 5 May 2008, Andrew Morton wrote:
    > You have stuff in your tree which isn't intended for 2.6.27??


    Heh, no, but I did read somewhere that you're only supposed to put patches
    in 'next' that you consider to be good enough for Linus to pull.

    On Mon, 5 May 2008 21:16:12 +0300
    "Pekka Enberg" wrote:
    > > So what to do here? I don't have a problem with maintaining separate
    > > branches for mm and next where the latter is not going to get much
    > > action until very late in the release cycle when I'm preparing for the
    > > next merge window.


    On Mon, 5 May 2008, Andrew Morton wrote:
    > I don't mind, really - just do what you think is best for your subsystem
    > and then tell me and Stephen about it. We'll only notice if you break
    > stuff
    >
    > So I'd suggest that you have a #for-next which contains material for 2.6.26
    > and 2.6.27 and a #for-mm which contains material for 2.6.28+.
    >
    > Only problem is, I'd need to generate the #for-next -> #for-mm diff, and
    > that particular git operation has been troublesome in the past.
    >
    > otoh, I think that staging for-2.6.26 and for-2.6.27 material in -mm really
    > is reaching far enough into the future, and I'd question the value of
    > staging for-2.6.28+ material as well. I mean, that's half a year away.


    Well, I only really have three kinds of patches: (1) testing, (2)
    for-linus asap (fixes in the middle of a release cycle) and (3) for-linus
    when the merge window opens. Up until now, I've put (1) in for-mm and
    after enough exposure (and no bug reports) they graduate into (2) or (3).

    So the problem here is where I put the patches in category (1)? If
    they can go into for-next, then for-mm can disappear. Stephen?

    Pekka
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: git trees which are not yet in linux-next

    Pekka J Enberg wrote:
    > Well, I only really have three kinds of patches: (1) testing, (2)
    > for-linus asap (fixes in the middle of a release cycle) and (3) for-linus
    > when the merge window opens. Up until now, I've put (1) in for-mm and
    > after enough exposure (and no bug reports) they graduate into (2) or (3).
    >
    > So the problem here is where I put the patches in category (1)?


    (1) Testing = (1a) testing isolated changes, (1b) testing in integration
    with other pending changes. -next is for the latter kind of tests,
    AFAIU with the primary goal of sorting out integration related issues.
    For several reasons --- for example one reason which I saw mentioned was
    to attract more testers than maybe -mm had lately --- we have been asked
    to submit code to -next which has passed (1a)-type testing and had
    appropriate review.

    Needless to say, many of us have difficulties to acquire resources
    [time, hardware, test cases/ workloads] for (1) or (1a). OTOH,
    borrowing -next or -mm for too early test stages will not pay out for
    any of us in the long run.
    --
    Stefan Richter
    -=====-==--- -=-= --=-=
    http://arcgraph.de/sr/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: git trees which are not yet in linux-next

    On Monday 05 May 2008 14:41:53 Pekka J Enberg wrote:
    > On Mon, 5 May 2008 21:16:12 +0300
    >
    > "Pekka Enberg" wrote:
    > > > I was looking at preparing a for-next branch for the SLAB tree but I'm
    > > > not sure I understand the above. For something like the slab
    > > > allocator, you want as much exposure as possible before asking Linus
    > > > to pull so I would like to continue to (ab)use -mm for testing as
    > > > well. But that doesn't seem to fit the linux-next rules at all...

    >
    > On Mon, 5 May 2008, Andrew Morton wrote:
    > > You have stuff in your tree which isn't intended for 2.6.27??

    >
    > Heh, no, but I did read somewhere that you're only supposed to put patches
    > in 'next' that you consider to be good enough for Linus to pull.
    >
    > On Mon, 5 May 2008 21:16:12 +0300
    >
    > "Pekka Enberg" wrote:
    > > > So what to do here? I don't have a problem with maintaining separate
    > > > branches for mm and next where the latter is not going to get much
    > > > action until very late in the release cycle when I'm preparing for the
    > > > next merge window.

    >
    > On Mon, 5 May 2008, Andrew Morton wrote:
    > > I don't mind, really - just do what you think is best for your subsystem
    > > and then tell me and Stephen about it. We'll only notice if you break
    > > stuff
    > >
    > > So I'd suggest that you have a #for-next which contains material for
    > > 2.6.26 and 2.6.27 and a #for-mm which contains material for 2.6.28+.
    > >
    > > Only problem is, I'd need to generate the #for-next -> #for-mm diff, and
    > > that particular git operation has been troublesome in the past.
    > >
    > > otoh, I think that staging for-2.6.26 and for-2.6.27 material in -mm
    > > really is reaching far enough into the future, and I'd question the value
    > > of staging for-2.6.28+ material as well. I mean, that's half a year
    > > away.

    >
    > Well, I only really have three kinds of patches: (1) testing, (2)
    > for-linus asap (fixes in the middle of a release cycle) and (3) for-linus
    > when the merge window opens. Up until now, I've put (1) in for-mm and
    > after enough exposure (and no bug reports) they graduate into (2) or (3).
    >
    > So the problem here is where I put the patches in category (1)? If
    > they can go into for-next, then for-mm can disappear. Stephen?
    >
    > Pekka
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/


    I think (1) would be for-mm, (2) would be pushed to Linus ASAP and (3) would
    be for-next. (unless I've gotten the intent of the various trees mixed up
    somewhere while tracking this discussion)

    DRH

    --
    Dialup is like pissing through a pipette. Slow and excruciatingly painful.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 2 1 2 LastLast