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

James Bottomley James.Bottomley at HansenPartnership.com
Thu Jun 21 12:51:39 UTC 2012

On Thu, 2012-06-21 at 07:43 -0400, Steven Rostedt wrote:
> On Wed, 2012-06-20 at 08:32 +0100, James Bottomley wrote:
> > 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.
> Best incentive for what? Pushing crap?

Right, that's my sole goal when it comes to the kernel.

Alternatively, you might have thought that the reason was encouraging
review and participation.  A lot of stuff in -mm didn't get reviewed
primarily because people thought if they didn't bother it would languish
there forever anyway. Conversely when stuff did finally get a review,
the original authors had got bored and drifted away.
> > A lot of the mm issues were solved by the staging tree (at least for
> > drivers).
> But there was a lot in -mm that was not drivers.

There's stuff in staging which isn't too.

> >   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.
> It's not about forgetting about it. I doubt people will be satisfied
> with just leaving code in -mm. If that's the case, untouched code that
> sits for too long is perfect rational for removing 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.
> I guess we are looking at this from two different points of view. You
> are focused on drivers, I'm focused on core kernel code, or shared code
> across drivers/arch. Changes like SCHED_DEADLINE and even the new printk
> could have sat a little in a devel repo to get some usage before
> appearing in next.

I've got to say, I don't really see the difference.  Driver code is nice
because it's usually well contained and it's easy to tag with the
TAINT_CRAP flag, but core changes can be staged as well.  They are more
volatile and more prone to conflicts because of the lack of
containment ... or are you thinking there's a problem getting a single
maintainer to take care of this?


More information about the Ksummit-2012-discuss mailing list