On 11/01/2015 01:06 PM, Greg Kroah-Hartman wrote: > On Sun, Nov 01, 2015 at 02:10:48PM +0200, Or Gerlitz wrote: >> On 10/29/2015 1:51 PM, Christoph Hellwig wrote: >>> On Wed, Oct 28, 2015 at 10:57:59PM -0400, Doug Ledford wrote: >>>>>>> I had to do a minor hand merge to get this to apply, but it has been >>>>>>> pulled in for 4.4. >>>>> >>>>> This breaks all of the drivers in staging BTW. That will need fixed up >>>>> before the pull request goes in during the merge window. >>> That latest branch on infradead.org should have fixed all the staging >>> drivers. But Linus just clarified that we indeed do not have to care for >>> staging drivers, I asked him at kernel summit in front of the whole >>> audience. >> >> Can you and/or Greg clarify this a little further... when someone modified >> an API called by others >> drivers, they don't have to deal with staging drivers? > > Yes, that is correct. > >> that is, the folks that care for this staging code need to handle >> that? > > Yes, that is correct. > > It's up to the owners of the staging drivers to do the work, we do not > make it the responsibility of anyone else. Now most of the time people > are nice and fix up everything else, but it's not a requirement at all. > > hope this helps,
Not really. That may be a satisfactory answer for most of the things in
the staging area, but it is not a satisfactory for the items I moved
into that area. The things I moved there belong in one of two categories:
1) Aging, but working, drivers that will be removed in the future.
Since we no longer have a deprecation mechanism, I was informed that the
normal procedure now is to move the driver to staging for a while and
then remove it permanently on a future schedule. This provides an
orderly removal process. But, if you make it so that random people can
break the driver with no responsibility for fixing up their breakage, in
contrast to the entire rest of the kernel, then you eliminate that
orderly removal process and turn it into a completely non-deterministic
and chaotic removal process. So, no, if that's how it will be handled,
I will move the deprecated drivers back to the main rdma tree and time
them out and perform the orderly removal myself.
2) New drivers (one currently, one other one submitted but not yet
pulled in) under active development but which need specific things fixed
up. These have people already working on them full time. They were
submitted to the staging tree with a specific TODO in order to get out.
If you then break that driver and force the driver author to fix it,
you have in essence changed the TODO list. That means you now have a
moving goal post scenario.
And this behavior is somewhat justified if you have a driver that is
languishing in staging and being mostly ignored by the
authors/maintainers of the driver. If the maintainers don't care enough
about it to fix it up, why should the core kernel developers keeping the
kernel modern fix them up?
But what about when the drivers *are* being actively maintained and
worked on? From the perspective of a maintainer trying to get their
driver out of staging, this policy means that drivers that are already
in the main tree get help from the core developer who *must* fix them up
to work with their changes according to policy, while the same core
developer is allowed to ignore any responsibility for fixing up any
staging drivers. At the same time, it is highly likely that since the
core kernel drivers have reached a level of maturity that they don't
really *need* a lot of help keeping up with changes nor require a lot of
work. The maintainer trying to get their driver out of staging however
could probably use the help the most, and certainly likely doesn't need
any extra work dumped on their back.
So, no, for the drivers I have moved into the staging tree, I don't
support this policy. This policy is really just a means of not making
core developers work on drivers that no one cares about. The *means* of
saving those core developers that work turns out to effectively be a
punishment to any driver maintainer in the staging area who isn't
allowing their driver to languish and go unmaintained. Because the
staging tree is not limited to just drivers deserving of this
punishment, the policy itself is inappropriate IMO. If that's going to
be a problem, I have no issue moving the entire staging/rdma tree back
into the drivers/infiniband area and fixing it up appropriately.
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
