Hi Andreas,, On Sat, 22 Jun 2019 at 20:49, Andreas Färber <afaer...@suse.de> wrote: > > Hi Simon, > > Am 22.06.19 um 21:14 schrieb Simon Glass: > > On Sat, 22 Jun 2019 at 20:08, Andreas Färber <afaer...@suse.de> wrote: > >> Am 22.06.19 um 20:15 schrieb Simon Glass: > >>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber <afaer...@suse.de> wrote: > >>>> 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? > >> > >> You're missing my point: What good is it to do a release when you > >> yourself consider it of such poor quality that you advise others not to > >> take it? > > > > Who said that? > > You, quoted above. In response to my concerns about decreasing quality > you suggested to take only every second release. That doesn't improve > the quality of either. It implies that one may have such bad quality > that people should skip it and yet does nothing to improve the next.
Actually I did not say that I consider the release of such poor quality. Nor did I advise others to take it. I suspect this is a misunderstanding of "But why not just take every second release?". My point was that if people don't have time to test every release, then just put in the time to test every second release. I am actually not sure how much a bit of extra time helps with stability. Have the last two releases been more reliable on hardware, since people have found time to test them using the 9-week -rc phases, whereas the previous 6-week one did not? > > > Your point, I thought, was that people didn't have time to test it? > > Not quite, I was talking about the full build-test-report-fix cycle > taking its time. Bugs in one -rc don't necessarily get detected and > fixed in time for the next -rc. That doesn't change unless the distance between rc's increases. But I think your point is that there are more -rc releases so more time to find and fix things. > > And I fail to see how your suggestion of skipping releases gives them > more time to test before the U-Boot release. That would rather be an > argument for slowing down the U-Boot release cycle beyond 3 months > (which I'm not asking). It would mean testing only every second release, which halves the time you spend testing, a significant reduction in load. Just need to schedule testing time over (say) 6 week, 3 times a year instead of 6 times. I think an automated test setup is the best way to do this. Marek asks who would run it? Perhaps people who have an interest in each board and want to spend less time on manual testing? We already have the technology to do this, with pytest and tbot. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
