ubuntu-phone team mailing list archive

[Alexander Sack <asac@xxxxxxxxxxxxx>]

Hi all,

Since we branched off last week there has been a good amount of
productive and emotional discussion about the difficulties the ramp up
the new RTM landing process puts on landers and landing team.

After discussing with the wider team and stakeholders, we identified
three key points that we want to make everyone aware of. We believe
these 3 points will allow us all to continue to effectively move
forward with a reasonable safety net in place. These points should
give us a good enough compromise on velocity vs. safety to ensure that
we can deliver bugs and features continuously without the risk of
accidentally busting our baseline.  Breaking the baseline might mean
the precious features of the engineering team won't make it into the
product.

Following are the 3 points:

1. SRCCOPY from utopic silo to RTM silo landing option AVAILABLE
====================================================
This wasn't clearly announced, but has been done successfully at least
twice and I think it should eliminate a big concern of requiring teams
to maintain two branches just to deliver the same code into two
baselines. It was discussed on IRC, but since you might not have
gotten it, here the good news that it is official: YES, YOU CAN DO
SRC-COPIES from the utopic silo into the ubuntu-rtm silo WITHOUT TWO
BRANCHES for your tree.

The way this works for now is that you just have your trunk and if you
want to keep this in sync on both sides, you just fill in your landing
in the spreadsheet. Unless you state otherwise when requesting the
silo, the LT will by default do the RTM silo for you; remember to
explicitely opt out from this option if you don't want your landing to
go into RTM branch to avoid busy work on LT side and unnecessary silo
allocation. sil2100 and robru will help and guide you through your
initial landings while we work to make this a built-in feature to our
loved spreadsheet :).

We will also work on bringing up  a wiki page documenting the
recommended landing approach

2. QA sign off improvements
======================

First, the QA sign off of landings in our rtm branch is a safeguard to
ensure we don't risk breaking our branch in a way that makes it
difficult to resurrect issues in time for market. The approach is
similar to the TRAINCON-0 approach we used successfully many times to
bring our quality up and keep it there i.e. you are done with testing
your feature silo for ubuntu-rtm and QA, will come along, double check
and sign off before you publish into ubuntu-rtm.

Anticipating that this extensive pretesting will cause some slowdown,
we prearranged 3 times the usual QA support to ensure that this will
move as quickly as possible for all of you.

In addition, we discussed today how to ensure there is more confidence
for landers that this sign off is not stuck and that QA is actively
working on it and what QA agreed to do is to be more proactive with
their communication to the landers. For that QA Engineers that work on
your silos will give you a heads up in person when they start,
progress and end doing your silo testing. They might also have
questions about your test plans etc., which should be helpful for
establishing an awesome quality gate of our landings.

Please remember that this process is kind of new for some QA members,
so help them. For that don't sit and wait if you feel your silo is not
getting attention for too long; rather reach out to jfunk or the
appropriate main point of contact for the right timezones:

 - US: jfunk
 - EU: jibel
 - AUS: thomi


3. QA sign off for features only
=======================
One concern was about how we can land all the fixes for all the bugs
with this QA sign-off burden. This was never planned to be the case,
but since the TRAINCON-0 rule seem to be not clear for everyone, I
want to reiterate that you can land isolated bug fixes without QA sign
off. Isolated means that they are one component, can be backed out and
are reasonably unintrusive.

If you have a landing that you think does not need it just put a
comment in there and when done testing ask LT for publishing these
without waiting for QA sign off.


I think with these measures we managed to clear the path to from now
on delivering effectively into our ubuntu-rtm branch. If you still
feel hesitant, please give it a try; doing this early and oftern for
your features and bug fixes will give you good confidence that your
change has made it into RTM (which helps sleep etc.).


With that, thanks again for the feedback so far and let me know if I
can do anything for you.
If you feel in any way stuck at any point in time or are still in
doubt about something, just ping me on IRC or shoot me a mail. In
urgent cases just text or even dial my mobile!

Cheers and happy landings!

 - Alexander