Re: [Ksummit-discuss] Topic: Removal of code that is still in use by users but there is a better code.

From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "John W. Linville" <linville@tuxdriver.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Ksummit-discuss] Topic: Removal of code that is still in use by users but there is a better code.
Date: Thu, 12 Jun 2014 18:36:05 -0700	[thread overview]
Message-ID: <1402623365.2523.167.camel@dabdike.int.hansenpartnership.com> (raw)
In-Reply-To: <20140612132756.GA4073@tuxdriver.com>

On Thu, 2014-06-12 at 09:27 -0400, John W. Linville wrote:
> On Wed, Jun 11, 2014 at 03:36:01PM -0700, James Bottomley wrote:
> > On Wed, 2014-06-11 at 15:26 -0700, Roland Dreier wrote:
> > > On Wed, Jun 11, 2014 at 3:17 PM, James Bottomley
> > > <James.Bottomley@hansenpartnership.com> wrote:
> > > > This would eventually become like CONFIG_EXPERIMENTAL before somebody
> > > > put it out of its misery: a pointless thing which everybody enables.
> > > 
> > > Probably so.
> > > 
> > > > Could we just step back and ask what the burning need to do this (at
> > > > least for drivers; I understand the ABI deprecation headache) is?  Most
> > > > driver code for obsolete things harmlessly compiles; why bother trying
> > > > to hunt them down and shoot them when they're not really causing
> > > > offence?
> > > 
> > > Every time a developer wants to change a core API, that developer
> > > needs to patch every driver that uses the API.  Every old, unused,
> > > bitrotten driver we have in the tree is 100% wasted work, and often a
> > > substantial amount of work because it's really hard even to understand
> > > how those drivers are (mis)using the API being changed.
> > 
> > Well how often do we do that?  It's not like it's the most common
> > activity.
> 
> I think it happens often enough to be a valid concern.  There are
> definitely wireless drivers (some which predate my tenure), that
> still compile but which I strongly doubt are functional or used.
> I've pushed some out of the tree from time to time, and I'll probably
> continue to do so.  But in the meantime, it can be difficult to judge
> what is used or not and what simply doesn't work because of a series
> of subtle mistakes in patch bombs...

So the solution to this is to put the drivers into a freeze maintenance
mode where you make no changes but what is absolutely required (and you
can decide depending on the extensiveness of the required change whether
you'd rather mark the driver as BROKEN than do the API change).  It
doesn't solve the problem entirely but it means that breakage has to
come from outside rather than subtle mistakes in unnecessary patches.

James