[U-Boot] Deprecation (planned removal) of 'maintainer-less' code

[U-Boot] Deprecation (planned removal) of 'maintainer-less' code

[Graeme Russ]

Hi Wolfgang,

I notice you've finally gotten sick of 'talking to the wall' regarding
unmaintained code (net, USB, AVR32, etc.)

To make life a little easier for everyone, maybe we can put together a list
of U-Boot sub-components which do not have an active maintainer so we can
discuss what to do about it as a whole rather than in a piecemeal fashion

Regards,

Graeme

[U-Boot] Deprecation (planned removal) of 'maintainer-less' code

[Marek Vasut]

> Hi Wolfgang,
> 
> I notice you've finally gotten sick of 'talking to the wall' regarding
> unmaintained code (net, USB, AVR32, etc.)
> 
> To make life a little easier for everyone, maybe we can put together a list
> of U-Boot sub-components which do not have an active maintainer so we can
> discuss what to do about it as a whole rather than in a piecemeal fashion

And this'll produce more talk to the wall.

I'll take over the USB, so you better CC me for USB patches. We need someone for 
NET now ...

M

[U-Boot] Deprecation (planned removal) of 'maintainer-less' code

[Graeme Russ]

Hi Marek,

On Mon, Feb 27, 2012 at 10:06 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> Hi Wolfgang,
>>
>> I notice you've finally gotten sick of 'talking to the wall' regarding
>> unmaintained code (net, USB, AVR32, etc.)
>>
>> To make life a little easier for everyone, maybe we can put together a list
>> of U-Boot sub-components which do not have an active maintainer so we can
>> discuss what to do about it as a whole rather than in a piecemeal fashion
>
> And this'll produce more talk to the wall.

Sorry, should have been more specific - List all the code that does not
have a maintainer in one thread and set a timeframe on deprication of the
lot unless maintainers are found (say 3 months) and then just depricate it
all in one go...

>
> I'll take over the USB, so you better CC me for USB patches. We need someone for
> NET now ...

I still wonder if we can't just move all the unmaintained code off to a
corner like /depricated with a CONFIG_SYS_ENABLE_DEPRICATED with a big fat
warning that there is no support for depricated code? Anything that stays in
depricated for longer than 6 months can them be thrown away. Make a rule that
no board configuration which sets CONFIG_SYS_ENABLE_DEPRICATED will be
accepted into mainline - If you really want feature 'X' for your board and
simply cannot live without it, be prepared to maintain it :)

Like Wolfgang, I would like to see these sub-systems that are prone to
bit-rot removed, but I think we should be able to come to a comprimise and
'box' the bit-rot (kind of an inverse to the Linux 'staging' strategy which
prevents non-compliant code getting into the main kernel code base)

Regards,

Graeme

[U-Boot] Deprecation (planned removal) of 'maintainer-less' code

[Marek Vasut]

> Hi Marek,
> 
> On Mon, Feb 27, 2012 at 10:06 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >> Hi Wolfgang,
> >> 
> >> I notice you've finally gotten sick of 'talking to the wall' regarding
> >> unmaintained code (net, USB, AVR32, etc.)
> >> 
> >> To make life a little easier for everyone, maybe we can put together a
> >> list of U-Boot sub-components which do not have an active maintainer so
> >> we can discuss what to do about it as a whole rather than in a
> >> piecemeal fashion
> > 
> > And this'll produce more talk to the wall.
> 
> Sorry, should have been more specific - List all the code that does not
> have a maintainer in one thread and set a timeframe on deprication of the
> lot unless maintainers are found (say 3 months) and then just depricate it
> all in one go...
> 
> > I'll take over the USB, so you better CC me for USB patches. We need
> > someone for NET now ...
> 
> I still wonder if we can't just move all the unmaintained code off to a
> corner like /depricated with a CONFIG_SYS_ENABLE_DEPRICATED with a big fat
> warning that there is no support for depricated code? Anything that stays
> in depricated for longer than 6 months can them be thrown away. Make a
> rule that no board configuration which sets CONFIG_SYS_ENABLE_DEPRICATED
> will be accepted into mainline - If you really want feature 'X' for your
> board and simply cannot live without it, be prepared to maintain it :)
> 
> Like Wolfgang, I would like to see these sub-systems that are prone to
> bit-rot removed, but I think we should be able to come to a comprimise and
> 'box' the bit-rot (kind of an inverse to the Linux 'staging' strategy which
> prevents non-compliant code getting into the main kernel code base)

Or find some maintainers ...

M
> 
> Regards,
> 
> Graeme