On 30/06/2019 12:34, Matwey V. Kornilov wrote:
25.06.2019 15:04, Tom Rini пишет:
On Tue, Jun 25, 2019 at 01:10:26PM +0200, Neil Armstrong wrote:
On 24/06/2019 17:29, Tom Rini wrote:
On Sat, Jun 22, 2019 at 09:43:42PM +0200, Marek Vasut wrote:
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@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 ?
My hope is that we can make use of the GitLab CI features to carefully (!!!!) expose some labs and setups.
Yes, the Gitlab CI could send jobs to lava instances to run physical boot tests, we (baylibre) are investigating this at some point, re-using our kernelCI infrastructure.
That seems like overkill, possibly. How hard would it be to have lava kick off our test.py code? In the .gitlab-ci.yml I posted, I migrated the logic we have for travis to run our tests. I wonder how hard it would be to have test.py "check out" or whatever machines from lava?
Isn't it possible to kick off the lava from gitlab webhooks?
Not sure, but you can totally generate and submits jobs to lava from gitlab ci : https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/pan... as collabora does for panfrost.
Neil
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot