[U-Boot] livetime of boards

[Heiko Schocher]

Hello Wolfgang,

Am 07.11.2013 20:15, schrieb Wolfgang Denk:
> Dear Heiko,
>
> In message<527B8BA7.2070605 at denx.de>  you wrote:
>>
>>> Agreed too. I doubt if a mailing list makes sense to collect such
>>> data. It would probably be more efficient to provide a web based
>>> service for this. It just has to be easy to submit reports, and to
>>> query the status for boards.
>>
>> Ok, how would look like such a web based service?
>
> I have no idea.  Not yet.  Let's first define what we want to have,
> then think about how to implement it.

Ok.

>>>> I also think that should be done on release only.
>>>
>>> Why?  To me it makes a lot of sense to also collect information on
>>> intermediate snapshots.
>>
>> Hmm.. I thought we get a "test report" (however this looks like in the
>> end) based on a commit id in u-boot/master ... isn;t this enough?
>
> Yes, this is perfectly fine.  I just want to allow this at _any_ time,
> not only once per release (near the end of the release cycle).
> especially for releases where bigger changes get merged it may be
> precious information to know when the code stopped working.

With "once", I only meant, we once update the "livetimer" and collect
all the time test reports!

>>> I hesitate to automatically remove existing boards.  Why would we want
>>> to do that?  To reduce efforts, right?  So I vote to keep boards as
>>> long as they are either maintained, or they at least "do not hurt".
>>
>> Why the "not hurt case"? Is it really good to have a lot of boards,
>> which compile clean, but we do not know, if the code really works?
>
> Well, one reason is efficiency.  If the code builds fine, and does not
> cause efforts druing any of the ongoing work, it is more efficient to
> just keep it than to actively remove it, which would require active
> work.  I. e. I want to reduce the work load on the maintainer(s) such
> that they only have to become active if such action saves even more
> effort.  Actually it may even seem more efficient in some cases to
> perform minor fixing even of unmaintained boards than to remove them.

But in the long term I think, we have more work with old, unmaintained
boards, then removing it. And if we remove boards actively, we maybe
force more the board maintainers (for examples corporates who have
interest that the board stays in mainline) to really test them ;-)

>> I prefer to have in current mainline only boards, which really work
>> or at least maintained... if a board maintainer did the work to
>> bring it into mainline, it should be interested in "stay in" mainline.
>> If this interest is lost and no other volunteers ... board is useless
>> in mainline.
>
> But should we not also try to minimize efforts, especially on the
> custodians?  If a board does not cause any trouble, we should not have
> to invent additional efforts for it.

Hmm... I am not really sure, if it is more work for removing a
board or fixing compiling issues ...

>> Ok, that is a way to go, if we have for all boards the information,
>> in which maintainstate it is ... but think of for example the new
>> i2c framework, how much boards use I2C? I have to check now all
>> this boards, decide to delete it or convert it  ... very time consuming
>> frustrating work ... and maybe for a lot of "do not hurt" boards only
>> waste of time ... :-(
>
> I don't really understand this argument. The I2C code is either
> hardware independent (say, the command line interface code), or it is
> platform specific (say, the driver code for the I2C controller on a
> specific SoC), or it is board dendent (say, some specific twiddeling
> with I2C devices to perform some magic operations on a board).
>
> In the first two cases the work wil have to be done in any case
> (except for the realy rare case that there are only old, unmaintained
> boards left using this SoC).  An for the board specific code you can
 >
> check if you need to adapt it by checking the board's test status.  If
> the board is unmaintained, then we enter the "it hurts" branch, and
> drop the board.

Hmm... :

pollux:u-boot hs [master] $ grep -lr HARD_I2C arch/powerpc/
[...]
arch/powerpc/cpu/mpc8xx/i2c.c
[...]
arch/powerpc/cpu/mpc8260/i2c.c
arch/powerpc/cpu/mpc5xxx/i2c.c
arch/powerpc/cpu/mpc824x/drivers/i2c/i2c.c
arch/powerpc/cpu/mpc512x/i2c.c
pollux:u-boot hs [master] $

Is it worth to move the drivers to drivers/i2c/ and convert them to
the new framework? Or is it better to delete them and the boards,
which use them ... Ok, if we had such a "livetimer" without deleting
old boards, you are right, I could do now:

- search the boards, which use the drivers
- search the state of this board
- decide, dropping or convert ...
   On which criteria whould this decision be done? I have no idea
   if this boards exist anymore ...

If we have only good boards, I have only one way -> convert. No
time wasted for the above steps ...

So, yes, I think we do not need to delete the boards, just mark
it broken ...

My hope with "delete old boards from mainline" is, that we become
more testreports from board maintainers, as they (should) have
interest that the board support stays in mainline. If they know,
that the board is only marked as broken, old or whatever ... they
maybe do not reserve the time for testing a board once a year ...

>> if we have a clean mainline state, where I know all boards are working
>> the decision is clear, convert all ... and board maintainers will test
>> it ... and we have always a clean compile state for mainline
>
> Again: you don't need any knowledge about boards that are not affected
> by your I2C changes.
>
>> And if we have this test/delete cycle, I can be sure, that after a
>> defined time all boards in mainline are working!
>
> Yes, but the cost is additional efforts, and being more aggressive
> than necessary.  I dislike both.

I dislike additional efforts too (But the question is, needs removing
old boards more effort than fixing them all the time maybe uselessly?).
Is it really aggressive to want once a year a testreport from
board maintainers? They get a lot of effort from the mainline for
free...

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany