Friday, 21 March 2014

Re: [Ubuntu-phone] ANN: TRAINCON-0 - CITRAIN all stop starting Friday

On Fri, Mar 21, 2014 at 1:36 PM, Oliver Grawert <> wrote:
> hi,
> Am Donnerstag, den 20.03.2014, 18:58 +0100 schrieb Alexander Sack:
>> Hi,
>> I am sending this as a proxy for the not-yet existing TRAINCON bot
>> that will give you updates about our touch image alert state that come
>> with individual landing rules.
>> The TRAINCON levels that were discussed at UDS are:
>> - TRAINCON-2 - everything green, normal landing rules apply
>> - TRAINCON-1 - no promotion for 2 days, restricted landing rules that
>> avoids risks and fastpath regression fixes apply
>> - TRAINCON-0 - no promotion for 5 days, regression fixes only rules apply
>> Since we were not able to promote a touch image since last friday, we
>> want to pursue according to the vUDS scheme above and move on to
>> TRAINCON-0 state for our touch images. To make that happen, I have
>> given the directive to the Landing Team to put the CITrain in "all
>> stop" mode first thing Friday morning in Europe. If you have
>> questions, concerns or want an exception of this "all stop" approach,
>> please contact me (asac) or in case I am not around rickspencer3
>> directly.
> While we should block on serious issues I think we are in a special
> situation with the current one. We had green images for the last few
> days, dogfooding results look good as well and all the listed issues are
> actually caused by one specific bug in Qt 5.2 (which seems to exist
> since 5.1, a version that we skipped).
> The bugs was identified and filed upstream as
> While we wait for a proper upstream fix the only option to work around
> the bug will be to hack up Mir to keep it rendering when the screen is
> off which will kill our battery life.
> I think we should not paint the world black and white here but accept
> that there have to be grey scales sometimes. Even on desktop we release
> with (non critical) bugs at times and release note them (in LTSes they
> then get fixed in point releases).
> I think this is a bug we should treat similar. Instead of killing our
> battery life with a hack, accept that it is there and currently
> unavoidable to have it, document it properly so users know what to
> expect and release one image that passes the tests and dogfooding.
> We can then block touch promotions again until it is properly fixed, but
> not block landings, so that the desktop team can still make their beta
> release. Some issues simply need to be decided on on a case by case base

So, you seem to suggest to go back to TRAINCON-1 so we can resume
careful landings.

what's not clear to me is what you suggest wrt to blocking promotion.
Please confirm whether its 1. or 2.:

1. declare this issue a non-blocker for one promotion, but a blocker
for next promotion?

2. continue block promotion, but keep landings flowing which would
risk delay promotion even if we find a fix today/monday?

...or something else?

> ciao
> oli
> --
> Mailing list:
> Post to :
> Unsubscribe :
> More help :

ubuntu-devel mailing list
Modify settings or unsubscribe at: