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

[Marek Vasut]

On 6/22/19 9:12 PM, Heinrich Schuchardt wrote:
> 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.

So who's gonna set it up and host it ?

-- 
Best regards,
Marek Vasut