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

James Bottomley James.Bottomley at HansenPartnership.com
Wed Jun 20 07:32:24 UTC 2012

On Tue, 2012-06-19 at 17:35 -0400, Steven Rostedt wrote:
> 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
> maintenance.
> 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
> mainline.

Please, no, not -mm again.  Patches languished in there for years.  Very
few people ran the tree just because it was known to be full of crap.
The immediacy of having something go in the tree is about the best
incentive we have.

A lot of the mm issues were solved by the staging tree (at least for
drivers).  The big issue I have with staging is that it seems to be
completely isolated from the actual communities who would understand the
code, so the last SCSI driver I got from it had had about 1,000 patches
but was still full of SCSI bugs.  However, even with the flaws, it's
much better than just dumping stuff in -mm and forgetting about it.

Thinking about the problem from my point of view, I think the solution
might be to break up the staging tree: every participating maintainer
would have a staging branch for ugly drivers that needed polishing and
these could be accumulated into the staging tree (which may or may not
be the upstream kernel tree depending on how we feel).  This would mean
that at least the subsystem which understood the driver took
responsibility for it.


More information about the Ksummit-2012-discuss mailing list