From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Mon, 24 Jun 2019 11:29:36 -0400 Subject: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released In-Reply-To: References: <20190611013147.GW7115@bill-the-cat> Message-ID: <20190624152936.GP9388@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de 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=C3=A4rber w= rote: > >>> > >>> 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 (wh= ich > >>> is good) but the overall quality of boards not actively worked on > >>> (because they were working good enough before) will decay, which is b= ad. > >>> The only way to counteract that would be to automatically test on real > >>> hardware rather than just building, and doing that for all these mass= es > >>> 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? > >=20 > > 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. > >=20 > > It would make sense to have such test automation for all of our > > architectures similar to what Kernel CI (https://kernelci.org/) does. >=20 > 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. --=20 Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: