ubuntu-phone team mailing list archive

[Alexander Sack <asac@xxxxxxxxxxxxx>]

Hi,

since some folks wondered what  alert state our CITrain operates now
that we got a promotion done. What everyone seem to agree is that we
should continue to push for an even better and more bug free
experience by Thursday. In consequence, we will continue operating
using TRAINCON-0 (highest alert level) until release.

Thanks!


On Wed, Apr 9, 2014 at 5:14 PM, Alexander Sack <asac@xxxxxxxxxxxxx> wrote:
> Hi all,
>
> (UPFRONT: this mail includes guidelines and rules outlined below are
> only meant to apply for our Ubuntu Touch upstream engineering work
> that goes through the CI Train. So, if you are not working for
> Canonical on the Ubuntu Touch, this is almost certainly just a FYI for
> you. If you are interested in this topic anyway, or would like ideas
> how you can apply extra care when uploading components touch, the LT
> offer stands to answer your questions in #ubuntu-ci-eng... )
>
> With 14.04 release pending and a bunch of promotion blockers plaguing
> us still, engineering leadership team has agreed that we put our tree
> and landing engine into high alert mode again (e.g. TRAINCON-0). Since
> we don't want to provoke a rush to deliver non-finished stuff,
> TRAINCON-0 (v2) landing rules will be in effect starting yesterday :).
>
> Note, that we looked at feedback received during our last TRAINCON-0
> (v1) alert a couple weeks back and decided to do something slightly
> different this time. For that we have come up with slightly relaxed
> operational/landing guidelines for TRAINCON-0 (v2). These are:
>
>  1. isolated regression and blocker fixes: can land easily; will get
> extra peer review by LT; otherwise normal landing practices with some
> extra care of the experienced lander.
>
>  2. small features and not-isolated bugfixes: can land, but special
> care applies; includes revisiting the test plan by LT/QA and
> potentially pumping test plan up to include more tests as well as more
> dogfooding/exploratory elements. Also, we want to introduce peer
> review test results by QA to ensure we don't make fatal mistakes on
> our way to green. Note: please mark your landing entries in the
> self-service spreadsheet prominently as FEATURE if your case falls
> into this category.
>
>  3. large features can land in case-by-case exceptions  - these need a
> case-by-case test and landing plan; should be the rare exception and
> resourcing can be done adhoc. Note: please mark your landing entries
> in the self-service spreadsheet prominently as BIGFEATURE if your case
> falls into this category.
>
> Depending on how well this goes or not, we might change to an even
> more restrictive approach in a couple of days. Key is that every
> engineering team really focuses on the regression/blocker bugs at
> hands with all manpower they have available. So let's stay focused and
> we will succeed.
>
> Thanks and keep on rocking everyone!
>
>  - Alexander
>
> p.s. since you will surely ask, the QA peer review mentioned for 2.
> and the special case-by-case discussion needed for 3. will be arranged
> by LT. If you need this service as you fall into category 2. or 3.
> above, just ensure you explicitly label your landings as FEATURE and
> be patient. We have put capacity for that silo peer review by QA to
> max. 1 QA engineer for now, so please be patient and think if you
> really need a feature landing to go in before we promote the image
> that will go out for 14.04.