On Wed, Jul 03, 2019 at 09:59:22AM -0600, Simon Glass wrote: > Hi Troy, > > On Tue, 2 Jul 2019 at 10:04, Troy Benjegerdes > <troy.benjeger...@sifive.com> wrote: > > > > > > > > > On Jun 22, 2019, at 2:43 PM, Marek Vasut <ma...@denx.de> 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 ? > > > > > > > I just got the infrastructure going to do this for the HiFive Unleashed > > (RiscV port), but that’s only one board right now. > > > > I’d propose that one of the responsibilities of being a custodian/ > > maintainer for a board and/or arch is a commitment to run a > > *simple* automated testing framework on a set of boards. > > SGTM, and I feel we should work towards a shared solution ideally in > the U-Boot tree to make this easy for people. Much exists already. > > > > > I’ve looked into KenrelCI enough to see that it seems rather > > complex to get up and running. We need a dead-simple setup > > (a few debian packages? A container? An SDcard image for a > > BeagleBone?) that can collect serial console output and power > > cycle a board. > > > > Eventually maybe we should have a Tizen SDWire or something > > like that, however that requires some real money for board > > development since I can’t seem to find a source for where > > I can buy an SDWire. > > Me neither. > > So where can we buy this magic board?
You can't, exactly. It's up at https://wiki.tizen.org/SDWire and Heinrich might have a bit more to say, but it's one of those things that we may want to see how much a run, or two runs cost and have a US and EU person that can resell-at-cost. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
