[Ksummit-discuss] Topic: Removal of code that is still in use by users but there is a better code.
linux at roeck-us.net
Wed Jun 11 23:22:16 UTC 2014
On 06/11/2014 12:43 PM, Bjorn Helgaas wrote:
> 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:
>>>> 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.
I understand, but personally I don't have much problem with code as long
as it compiles. I am more concerned with code that doesn't compile and
no one cared for years.
Sure, there is a difference if that code actually consumes cycles, but I
suspect that isn't likely enough to be bothered about. If there is such code,
I would agree that it should be removed even if it does compile.
More information about the Ksummit-discuss