[Ksummit-2012-discuss] [ATTEND] Process issues, device model, stable
greg at kroah.com
Wed Jun 20 16:51:23 UTC 2012
On Wed, Jun 20, 2012 at 05:40:25PM +0100, James Bottomley wrote:
> On Wed, 2012-06-20 at 08:12 -0700, Greg KH wrote:
> > On Wed, Jun 20, 2012 at 08:32:24AM +0100, James Bottomley wrote:
> > > 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.
> > DRM and video already do this today, both in different ways. DRM has
> > the code within their subdirectory, but has the driver depend on
> > CONFIG_STAGING. Video has subdirectories in drivers/staging/ that I
> > know to not touch at all.
> > Either way works just fine for me, if other subsystem maintainers want
> > to do this, they are more than welcome to (just let me know if I'm not
> > supposed to touch a subdirectory that they create.)
> Either way is fine by me too ... if you want to create staging/scsi and
> move the SCSI drivers into it, that works for us.
What scsi drivers should move into it?
> What I really want is to get linux-scsi copied on the patches and try
> to avoid the "we've applied 500 patches to this driver, what do you
> mean it has fundamental problems" disappointment.
That was the hyper-v debacle, and was entirely their own fault. I NEVER
say that just because a driver is cleaned up enough enough to pass the
basic coding rules, that this means it is really good enough to merge to
the right part of the kernel, that's why I force the authors to submit
it to the subsystem, for your review.
The hyper-v people were under some unrealistic pressure by managers who
had no idea how Linux worked (despite some of them working in the Linux
"industry" for years), that felt somehow they could magically decree
that the code was good enough to be merged and that would be all that is
needed to be done.
Hopefully a mess like that will never happen again, but I wouldn't hold
my breath. It's just a learning process that all companies go through,
nothing really new there at all.
More information about the Ksummit-2012-discuss