On Fri, 2012-05-11 at 02:27 +0200, Alexander Sack wrote: > On Fri, May 11, 2012 at 1:43 AM, Jon Medhurst (Tixy) <t...@linaro.org> wrote: > > On Fri, 2012-05-11 at 07:14 +0800, Andy Green wrote:If > >> the current one performs best and is on a random HEAD commit, we > >> certainly shouldn't wind it backwards to last -rc that performs worse > >> just because that's "easier to communicate". > > > > I agree, I wasn't envisioning winding backwards, more that we stop > > winding forwards at a chosen -rc, or stop merging topics on a Friday, > > bring the common tree up-to-date with the weekends Torvalds -rc, then > > build, test and fix this ready for Linaro RC on the Friday. > > I think we agree ... here is how I thought so far should linux-linaro > could be driven forward: > > 1. we have an automated -tracking baseline running that always > reflects how your topics look like on tip > 2. linux-linaro moves forward on the day a new RC comes around. > 3. linux-linaro will not wait for topics to be ready before doing the RC jump > 4. in between RCs, we only move mainline on our linux-linaro release > baseline forward if we see a working tracking build that wouldn't drop > any topics that already made it into this RC cycle.
I'm not sure this differs much from linux-linaro == last good automated -tracking baseline, which might be simpler to understand. But I thought linux-linaro was meant to be this tracking baseline anyway? -- Tixy _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
