[Buildroot] [autobuild.buildroot.net] Your daily results for 2019-08-18

[Arnout Vandecappelle]

On 21/08/2019 12:03, Peter Korsgaard wrote:
>>>>>> "Yann" == Yann E MORIN <yann.morin.1998 at free.fr> writes:
> 
> Hi,
> 
>  >> We could do that as well. We then need to merge in the other direction
>  >> (stable->master) to ensure fixes after rc1 (and updates to the CHANGES
>  >> file) are not dropped,
> 
>  > Well, usual version control best practices suggests the opposite: all
>  > fixes are done on master, and when relevant, back-ported to the stable
>  > branch(es).
> 
>  > This is no different than what you do today when you backport changes
>  > from master to the stable branches, except it happens right from -rc1
>  > instead of after the final release. It is the exact same process.

 However, the cherry-picking process is much labour-intensive than just merging
next into master. And we expect a *lot* of patches to still go into the stable
branch during the release month. So if we choose this approach, we'll be
applying onto stable and merging into master.

> 
> Correct.
> 
>  >> and website changes needs to happen on master
>  >> rather than stable.
> 
>  > But that's already the case, no?
> 
> Yes. This does mean that the website copy in the tarball doesn't match
> the real website for "normal" releases, but that isn't really a big
> deal.

 The website in the tarball only matches the real website in the time between
the release and the next modification to the website. For 2019.05, that time was
15 minutes (update of news.html with the new release).

>  >> It seems a bit more complicated to me, but that might just be because I
>  >> have done the other way around for 10+ years by now ;)
> 
>  > Yeah, I know habbits, as bad as they might be, are hard to break! ;-p
> 
> Heh. Notice that the choice for a next branch rather than branching of
> for releases was done on purpose to motivate people to focus more on the
> upcoming release rather than new stuff. I think this has largely
> succeeded, and I am somewhat afraid of a shift of focus if we change
> this. I see very little outside contributions to the stable/lts
> branches.

 I'm not sure if this focus on the upcoming release is really related to the
state of the master branch. I think the key factor is that the branch for the
upcoming release gets most of the testing in the autobuilders.

 Actually, I think the inverse effect is bigger. We regularly see patches that
are for next (but not marked as such) but that don't actually apply to next,
because they've been created on master. I expect that if we swap the branches,
we'll get a lot less of that: patches that are for the upcoming release either
apply to both branches (95% of the cases), or the contributor is likely to have
intentionally created it for the upcoming release (e.g. because it is a patch
cherry-pick instead of a version bump).


>  >> >> But then we should probably also update the branches info for the autobuilders
>  >> >> to make sure the stable branch gets sufficient testing.
>  >> 
>  >> > This is relatively easy: just update http://autobuild.buildroot.org/branches
>  >> > with new branches and new ratios.
>  >> 
>  >> Yes, but this file in manually maintained and only accessible by Thomas,
>  >> right?
> 
>  > How would that be different from today? I would say that today, for each
>  > release cycle, there are two changes:
> 
>  >   - one to introduce next in the list (after -rc1)
>  >   - one to introduce the new stable rbanch and remove next and the
>  >     oldest stable branch (after the release)
> 
>  > with the proposed change, there would be a single change per release:
> 
>  >   - one to add the new stable branch and remove the oldest stable branch
>  >     (after -rc1)
> 
> But that doesn't take the weights into consideration, so we would end up
> spending most of the autobuilder time on master (E.G. what we now call
> next).

 Indeed, we still need both actions: one to add the new stable branch with a
large weight, and one to reset the weight of master.


> Anyway, I am OK with giving it a try for 2019.11, but I'm not completely
> convinced about it.

 Sounds like a plan!

 Regards,
 Arnout