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

[Daniel Hazelton <dhazelton@enter.net>]

On Monday 05 May 2008 14:41:53 Pekka J Enberg wrote:
> On Mon, 5 May 2008 21:16:12 +0300
>
> "Pekka Enberg" <penberg@cs.helsinki.fi> 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" <penberg@cs.helsinki.fi> 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.