ubuntu-phone team mailing list archive

[Alexander Sack <asac@xxxxxxxxxxxxx>]

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.