> On Jul 3, 2019, at 11:04 AM, Tom Rini <tr...@konsulko.com> wrote: > > 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
What are the chances I can get KiCad sources for the board ;) _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
