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 -- 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
