[Ksummit-discuss] Topic: Removal of code that is still in use by users but there is a better code.
bhelgaas at google.com
Wed Jun 11 19:43:18 UTC 2014
On Wed, Jun 11, 2014 at 11:54 AM, Guenter Roeck <linux at roeck-us.net> wrote:
> On Tue, Jun 10, 2014 at 01:19:12PM -0700, H. Peter Anvin wrote:
>> On 06/10/2014 01:12 PM, Konrad Rzeszutek Wilk wrote:
>> > Hey,
>> > I would want to propose a topic on removing code in Linux that
>> > users are using - but they are doing it less and less and it
>> > mostly is tied in with older hardware. Specifically how to do
>> > this transition properly - and if we want to define some checklist
>> > /policy to do it via.
>> I second this. Right now deprecation is entirely ad hoc... usually in
>> the form "this hasn't compiled for X releases and noone noticed", which
>> makes it hard to do *controlled* deprecation...
> That is a bit different to "users are using but less and less". Personally
> I would not mind leaving code in the kernel as long as it is used, but
> it would be great if we had some rule that a file/driver which did
> not compile for X releases (pick a preferred number for X - two years
> worth of releases ?) can be removed.
I suspect most people would agree with the idea that something that
hasn't compiled for X years can be removed, possibly with some
negotiation about what X is.
But my impression is the proposal is to go farther than that, and
figure out a way to remove obsolete but still-compilable code. If we
all did our jobs perfectly, we would never add a change to Linux that
broke compilation of anything. So if there's a file that doesn't
compile anymore, I think of that as a result of a mistake somewhere
along the line. We can use that mistake to deduce that nobody cares
anymore, but it'd be a lot nicer to have a scheme that didn't depend
on people making random mistakes.
More information about the Ksummit-discuss