[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080506144111.43736d63.sfr@canb.auug.org.au>
Date: Tue, 6 May 2008 14:41:11 +1000
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: Pekka J Enberg <penberg@...helsinki.fi>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-next@...r.kernel.org, sfrench@...ibm.com,
swhiteho@...hat.com, stefanr@...6.in-berlin.de, jeff@...zik.org,
ralf@...ux-mips.org, drzeus-list@...eus.cx, jack@....cz,
cbou@...l.ru, jens.axboe@...cle.com, ericvh@...il.com,
wim@...ana.be, chris@...kel.net, nico@....org, clameter@....com,
ezk@...sunysb.edu, linux-kernel@...r.kernel.org
Subject: Re: git trees which are not yet in linux-next
Hi Pekka,
On Mon, 5 May 2008 21:41:53 +0300 (EEST) Pekka J Enberg <penberg@...helsinki.fi> 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)? If
> they can go into for-next, then for-mm can disappear. Stephen?
Stefan Richter is right: if they have passed your review and testing in
isolation, then they are allowed into -next for testing against other
subsystems. So (2), (3), and (1b) ... :-)
--
Cheers,
Stephen Rothwell sfr@...b.auug.org.au
http://www.canb.auug.org.au/~sfr/
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists