[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable

Steven Rostedt rostedt at goodmis.org
Tue Jun 19 21:35:38 UTC 2012

On Tue, 2012-06-19 at 23:17 +0200, Rafael J. Wysocki wrote:

> It makes sense to create a patches-that-came-too-late branch in your tree and
> put those things in there, so that they can be moved to the linux-next branch
> when the merge window closes.  I'm not sure what the advantages of having a
> central repository of such things would be, though.

That's not what I'm proposing.

Yeah, things are being thrown around a lot here, but that's good,
because this is a 'discuss' list :-)

I'm not suggesting that we have a linux-devel that is there for you to
put things in that are for linux-next. If you had patches ready for
linux-next and missed the merge, you only need to wait till Linus's
merge window closes and linux-next will be open again.

Which means what I said before did not make sense. The merge window for
linux-next would be much longer than linus's tree. It would open when
Linus closes his merge window, and it should close around -rc5 or -rc6.
That is, if you see -rc5 came out, you have a couple of weeks left to
get stuff into linux-next before it closes.

Now for linux-devel that I'm proposing is for much earlier than when you
are ready for linux-next. And may not be for everything. If you are just
doing some minor updates to your subsystem, there's no advantage in
getting that out to linux-devel instead of just pushing it to linux-next
when it is ready.

What I want linux-devel for is the bigger changes. Things where you do
rewrites. It would have been nice to see the new printk() go into such a
repo that way we could have played with it more before it hit linux-next
or mainline. linux-devel should be for just that. Development, not

Sometimes its nice to have a general repo were you can dump out your
code and say "here's what I've been doing, does this all work for you?".
This is the place to send code that is still in RFC mode. Patches are
great, but I really believe that you will get more people testing it if
you shared the repo that others have their development code in too.

That's what I'm proposing. Not just a N+1 repo (put it in X before it
goes to Y then we can ship it to Z). But something like the old -mm was.
Where code can literally sit for years before it finally makes it to

-- Steve

More information about the Ksummit-2012-discuss mailing list