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

Steven Rostedt rostedt at goodmis.org
Thu Jun 21 13:43:12 UTC 2012

On Thu, 2012-06-21 at 13:51 +0100, James Bottomley wrote:
> 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.

Note that -mm was a quilt queue as well as one big patch. I find git
much better to test individual changes. I sometimes ask people that post
patches if there is a git repo I can pull from. Makes testing much

Also, I would argue that any branch that gets lack of development, gets
a email sent to the maintainer asking them for status, and if there's no
reply or they don't care, it simply gets dropped. This is very easy to
automate, especially with git.

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

That wasn't the point of staging IIRC.

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

Core changes usually touch core code, which means that it's not
contained in the staging directory.

Anyway, it doesn't hurt to have such a repo. If you don't like it, just
don't use it.

-- Steve

More information about the Ksummit-2012-discuss mailing list