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

[Steven Rostedt]

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?

-- Steve