On 08/07/2015 10:19 AM, Christoph Hellwig wrote: > On Fri, Aug 07, 2015 at 10:17:18AM -0400, Chuck Lever wrote: >> If bot barking doesn't bother anyone, then I'll keep the removal patch. >> For some such a complaint might be grounds for rejecting the patch. > > If it's (a) in tree proper and (b) not one of the rare false positives I > would consider it a reason for rejection as well. But this is the > staging tree we're talking about.
I want to put my $.02 in on this. The staging tree has meant different
things over time. In particular, it didn't used to be a place where "to
be removed" drivers went to hang out for a few releases before finally
being removed entirely. I suspect this policy of not touching staging
drivers with tree wide API changes pre-dates the policy of using staging
as an intermediate step in removal. It would seem to me that saying we
are going to remove a driver in 4.6 and moving it to staging for that
purpose, and then immediately breaking it so it doesn't compile, is not
compatible with the goals of orderly device driver removal (namely:
alerting people to the upcoming change, waiting a reasonable period of
time for objections/feedback, and then removing the driver if no one
brings forth a case for it to stay in the kernel). It effectively
becomes an immediate removal. For that reason, I can't say that I agree
with this policy of skipping staging drivers for API updates, at least
as it applies to drivers that were in the tree proper and are in staging
now as part of their orderly removal process.
I can't say as I really agree with the policy for drivers coming in
through staging either unless the authors of the driver are allowing it
to languish and not pursuing their TODO list.
In any case, I don't expect to have stuff from the RDMA core in staging
for an extended amount of time. But right now there is, and for the way
I'm using the staging area, *I* care if your patch breaks the drivers
that are there.
--
Doug Ledford <dledf...@redhat.com>
GPG KeyID: 0E572FDD
signature.asc
Description: OpenPGP digital signature
