On Fri, 2012-05-11 at 02:27 +0200, Alexander Sack wrote:
On Fri, May 11, 2012 at 1:43 AM, Jon Medhurst (Tixy) tixy@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:
- 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?