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

Steven Rostedt rostedt at goodmis.org
Thu Jun 21 11:43:22 UTC 2012


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?

> 
> 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.

>   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.

-- Steve




More information about the Ksummit-2012-discuss mailing list