[U-Boot] livetime of boards

[Wolfgang Denk]

Dear Tom,

In message <20131105203736.GM5925 at bill-the-cat> you wrote:
> 
> > We have the real problem, that we have a lot of old boards, which
> > are unmaintained in U-Boot, and we have no chance to find out, if this
> > boards are longer used/tested ...
> 
> We also have a feature, lots of hardware support because lots of things
> don't change drastically, frequently.  That's not to say that I wouldn't
> mind dropping old platforms (even that ones I have sentimental feelings
> towards), and would certainly like to see more and frequent sanity
> testing.

I think Heiko's idea of documenting test reports is pretty cool - but
of course we need to discuss in detail how to implement this, and
also decide wether we use this for (semi-automatic) code cleanup (by
removing boards that have not been tested for a long time).

> This problem comes up when we talk about doing big changes, and I think
> that's the right time to talk about things.  And I think the answer
> should be, we try and convert things forward and when it's not obvious
> if things will still work correctly, or how to do it, that's when we
> need to make a hard push on the board maintainers to find some time to
> work on things.

Agreed. And here information how recently (or maybe even how
frequently) a board has been tested (build tested, run on actual
hardware) would come in really handy.  we can probbaly automate build
testing one way or another, but for actual runtime tests we will lways
depend on the board maintainers, or board users.

> > So, the question raises, should we introduce a column in boards.cfg,
> > which shows the "livetime" of a board support in U-Boot?
> 
> I sense a lot of conflicting patches.

Again I agree.  Also, I fear that  boards.cfg  is becoming more and
more unreadable by adding even more stuff.  If I see this correctly,
the maximum line length in  boards.cfg  already exceeds 360 characters
:-(


So nstead of adding this information to  boards.cfg  we could probably
use separate files for such information.  We could provide tools to
make test reports really easy, say something like

	scripts/build_test
	scripts/run_test

which the user would just call with a "passed" or "failed" argument;
the scripts could then auto-detect which configuration and which exact
U-Boot version were in use, and send an email.  Whether that would be
a patch against the source code or something that get's auto-added to
a wiki page is just an implementation detail.  But if we had something
like this, we could get a muchbetter understanding how actively boards
are being tested.

So when you're once again doing some change that requires touching
files for some othe rboards, you could simply check that database.  If
you see that 3 out of the last 5 releases have reported succesful
run-time tests you will probably decide to accept the needed efforts,
but when you see the last test report is more than 5 years old, you
will probably rather decide to initiate a code removal process.

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
A Chairman was as necessary to a Board planet  as  the  zero  was  in
mathematics, but being a zero had big disadvantages...
                         - Terry Pratchett, _The Dark Side of the Sun_