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

Marek Vasut marek.vasut at gmail.com
Mon Feb 27 00:21:10 CET 2012


> Hi Marek,
> 
> On Mon, Feb 27, 2012 at 10:06 AM, Marek Vasut <marek.vasut at 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


More information about the U-Boot mailing list