[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable
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
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.
More information about the Ksummit-2012-discuss