Re: git trees which are not yet in linux-next
- From: Daniel Hazelton <dhazelton@xxxxxxxxx>
- Date: Mon, 5 May 2008 17:11:52 -0400
On Monday 05 May 2008 14:41:53 Pekka J Enberg wrote:
On Mon, 5 May 2008 21:16:12 +0300
"Pekka Enberg" <penberg@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- git trees which are not yet in linux-next
- From: Andrew Morton
- Re: git trees which are not yet in linux-next
- From: Andrew Morton
- Re: git trees which are not yet in linux-next
- From: Pekka J Enberg
- git trees which are not yet in linux-next
- Prev by Date: Problem mounting ext2 using ext3?
- Next by Date: Re: w35und: some more code removal
- Previous by thread: Re: git trees which are not yet in linux-next
- Next by thread: Re: git trees which are not yet in linux-next
- Index(es):
Relevant Pages
|
