[Ksummit-2012-discuss] [ATTEND] linux-next and process
linux at roeck-us.net
Mon Jun 18 21:00:33 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.
I have a hwmon-staging branch in my kernel.org repository for exactly that
purpose. Also, I started publishing standalone drivers on github. Especially
the latter (being public and referenced) helps a lot to get drivers tested
before I submit the code for upstream integration.
More information about the Ksummit-2012-discuss