[U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released

[Heinrich Schuchardt]

On 6/22/19 8:15 PM, Simon Glass wrote:
> Hi,
>
> On Sat, 22 Jun 2019 at 16:10, Andreas Färber <afaerber at suse.de> wrote:
>>
>> Hi Simon,
>>
>> Am 22.06.19 um 16:55 schrieb Simon Glass:
>>> I'd like to better understand the benefits of the 3-month timeline.
>>
>> It takes time to learn about a release, package and build it, test it on
>> various hardware, investigate and report errors, wait for feedback and
>> fixes, rinse and repeat with the next -rc. Many people don't do this as
>> their main job.
>>
>> If we shorten the release cycle, newer boards will get out faster (which
>> is good) but the overall quality of boards not actively worked on
>> (because they were working good enough before) will decay, which is bad.
>> The only way to counteract that would be to automatically test on real
>> hardware rather than just building, and doing that for all these masses
>> of boards seems unrealistic.
>
> Here I think you are talking about distributions. But why not just
> take every second release?
>
> I have certain had the experience of getting a board our of the
> cupboard and finding that the latest U-Boot doesn't work, nor the one
> before, nor the three before that.
>
> Are we actually seeing an improvement in regressions? I feel that
> testing is the only way to get that.
>
> Perhaps we should select a small subset of boards which do get tested,
> and actually have custodians build/test on those for every rc?

What I have been doing before all my recent pull requests is to boot
both an arm32 (Orange Pi) and and an aarch64 (Pine A64 LTS) board via
bootefi and GRUB. To make this easier I am using a Raspberry with a
relay board and a Tizen SD-Wire card (https://wiki.tizen.org/SDWire)
controlling the system under test,
cf https://pbs.twimg.com/media/D5ugi3iX4AAh1bn.jpg:large
What would be needed is scripts to automate the testing including all
the Python tests.

It would make sense to have such test automation for all of our
architectures similar to what Kernel CI (https://kernelci.org/) does.

Regards

Heinrich