[Ksummit-2012-discuss] [ATTEND] linux-next and process

Greg KH greg at kroah.com
Mon Jun 18 20:06:21 UTC 2012

On Mon, Jun 18, 2012 at 03:59:37PM -0400, Steven Rostedt wrote:
> On Sun, 2012-06-17 at 11:28 +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > "Me too" :-)
> > 
> > I would like to attend since KS is the one place I get to actually meet
> > any of you face to face.  I find that it makes it easier to remember that
> > you are all people and lowers the level of ranting that my workmates have
> > to put up with on a daily basis.  :-)
> > 
> > Also, I am wondering if we should talk a little about the process of
> > being maintainers (I hear groans already :-) - I don't really want to
> > teach you all how to suck eggs) and whether people have any (hopefully
> > positive) criticism of the linux-next process itself.
> > 
> As, IIRC, linux-next is made for the next release. That is, when it gets
> into linux-next, it should pretty much be ready for mainline, and we are
> just in the stages of making sure the code integrates with others.
> I'm wondering if we need a global repository similar to linux-next that
> can hold development changes. Things that work locally, but you want to
> get a wider use from it, but you do not feel it's ready to make the next
> cut. Maybe it's ready for two or three more releases, or it may supply a
> new API that you want to vet out before committing.
> Updates to this repository should still be well tested before entering,
> but it would be used more for a way to get other people to play with it
> and see how it interacts with the rest of the system.
> One example I can imagine would be the SCHED_DEADLINE scheduler being
> entered to it. It may not be fully ready for the next kernel release,
> but that's something that would be interesting to see how it works with
> other's development trees.
> I'm sure other people have ideas that they want to share and see how it
> interacts with other subsystems before committing to linux-next.
> I would also imagine that this repo would pull from different git trees
> like linux-next, but if a new change is proven to be too broken, that it
> gets reverted (rebased) with a email going out to the owner of the repo.
> We still want the code to build and work for everyone.
> Make this like -mm use to be :-) Where changes in -mm would stay around
> for years before making it to mainline.
> Thoughts?

If you can manage something like this, I would love to see it,
especially as it would allow me to keep on top of patch submissions for
the 2 weeks that the merge window is open.

And also, I'm sure we all have things in local development trees that
are half-baked, that could use some more testing by others before they
get added to the public trees.  I know I sure do...

greg k-h

More information about the Ksummit-2012-discuss mailing list