[U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released

[Simon Glass]

Hi Andreas,

On Sat, 22 Jun 2019 at 20:08, Andreas Färber <afaerber at suse.de> wrote:
>
> Hi,
>
> Am 22.06.19 um 20:15 schrieb Simon Glass:
> > On Sat, 22 Jun 2019 at 16:10, Andreas Färber <afaerber at 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?

Your point, I thought, was that people didn't have time to test it?

>
> That has nothing per-se to do with who uses that release and whether you
> build it in OBS or locally.
>
> > 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 don't understand that question. The proposal, as I understood it, is
> to shorten the release cycle by one month, doing six instead of four
> releases. How could there be an improvement by leaving it as it is? My
> fear is that the change will make it _worse_, i.e. no improvement but
> rather risk of more regressions by switching to _two_ months.
>
> In this very same -rc4 thread I reported one such regression, and
> luckily a patch was quickly prepared to address it. It's not yet merged
> despite tested - review also takes time.
>
> > I feel that
> > testing is the only way to get that.
>
> Agreed. And my point was that testing takes time. Increasing the release
> frequency shortens the time for testing of each release.
>
> > Perhaps we should select a small subset of boards which do get tested,
> > and actually have custodians build/test on those for every rc?
>
> Many custodians are volunteers. You can't force them to test boards at a
> pace you dictate to them. Also, more frequent releases also increase the
> chances of a custodian/maintainer being on vacation during a release.
>
> And a working, say, BeagleBone doesn't make the user of a random other
> board any happier. ;-)

Another question...how much do people care about the latest and
greatest features? Perhaps we should be merging patches frequently,
but creating a release branch separate from master?

The current process seems very very slow to me.

Regards,
Simon