[U-Boot] AT91: How treat outdated/unmaintained boards/code - was [PATCH v3 1/2] at91rm9200ek: add configure target for RAM boot

[Wolfgang Denk]

Dear =?iso-8859-1?Q?Andreas_Bie=DFmann?=,

In message <AF6B65B0-6784-4550-86FE-CC49AD3525B6 at googlemail.com> you wrote:
> 
> If one can fix some remaining atmel (or arm in general) boards they
> should become the new maintainer.

Agred - assuming they agree, too.

> 3. How should we treat at91rm9200 boards which are not transformed to
> at91. I plan to get the at91rm9200 device drivers (at91rm9200_usart,
> emac) merged with at91 implementation. When we do this transition (will
> last til end of this year at least; not before 2011.03/maybe 2011.06) we
> could completely delete the deprecated drivers. Thus we break at91rm9200
> boards completely (which may not working at all due to new arm
> relocation stuff ... but who knows/test this/is responsible for?).
> Should we write down/propagate a time schedule for this transition as it
> is done for arm relocation? Should we drop those possible not working
> boards in general?

If we know for sure that a board is broken, and nobody cares about it
we shoul remove it.   This is simple to find out if a board does not
compile, but I guess there are a number of boards that are broken in
more subtle ways.  If you are aware of any such cases, please let me
know or submit a patch to remove them.

U-Boot has sometimes been critized to carry old jetsam for too long,
thus preventing any reasonable innovation. Let's prove these guys
wrong...


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I mean, I . . . think to understand you, I just don't know  what  you
are saying ...                        - Terry Pratchett, _Soul Music_