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 >>>>>>> <afaer...@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/panfrost/ci/gitlab-ci.yml#L158 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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
