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

Peter Korsgaard peter at korsgaard.com
Wed Aug 21 10:03:46 UTC 2019


>>>>> "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.

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.


 >> 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.


 >> >> 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).

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

-- 
Bye, Peter Korsgaard



More information about the buildroot mailing list