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. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
