Sorry for not replying earlier, but somehow the reponses to this mailthread didnt make it in my inbox until today? really odd...
On Tue, Jan 7, 2014 at 4:26 PM, Ted Gould <t...@ubuntu.com> wrote: > On Tue, 2014-01-07 at 11:51 +0100, Alexander Sack wrote: > > To start off this amazing new year, I wanted to share a slide deck > that outlines two exciting improvements to our engineering process > that we will roll out during January. > > - > https://docs.google.com/a/canonical.com/presentation/d/1LiDK3nVWUFKPbOCOPQEWdpXuTVpIQNU2SWjTiQaIGxE/edit#slide=id.g258bded9d_0120 > > > Ah, interesting. Seems like it still has some rough edges, but it's nice > that there is a goal to have more Upstream control of what is in the images. > > It seems to me that having the merge review checklist in the Wiki, while > good for getting things started, isn't ideal as we move forward. It seems > that we'd be better of having it in the repository for the project at some > known location (i.e. /MERGE-CHECKLIST) so that it's clear when you check it > out. Also, it'd be really nice if when Jenkins (or his replacement) sees an > MR if he could post a message to it with the contents of the file. That way > a reviewer can reply to the MR e-mail filling it out. We could also then > have Jenkins fail the MR right then if the file doesn't exist (eventually). Whatever we do we should use a standardized approach. The wiki was the initial pick and for me its about having the content and having it in a way that we can easily look at it and browse without finding and checking out the bzr branch. > > One of the key goals listed in the slides was for Upstreams to control their > trunks, but it seems that later in the deck it mentions that each MR has to > be approved by a "Super Reviewer" that is called a "Landing Engineer." It > seems that running everything through this super reviewer process creates a > bottle neck for the team, for instance if he or she is on vacation or gets > sick. Can everyone on the team be a "Landing Engineer"? What's different > between a "Landing Engineer" and a "Software Engineer"? The Landing Engineer is a role filled by the upstream engineering team. e.g. it's the upstream engineer that does the landing. It's just that while long term we want to get to a point where every upstream engineer can do everything, we want to focus on initially training a managable set of people, hence we ask the upstream engineering teams to appoint a primary landing engineer for the time being... > > For manual test plans we've previously used restructured text in a format > that, in theory, makes it easy to automate the tests later if we were able > to (new technologies for instance). For example the manual tests that are > in Unity: > > > http://bazaar.launchpad.net/~unity-team/unity/trunk/files/head:/manual-tests/ > > Is there a reason you didn't continue on this approach? It seems to be > stronger in that there is a better possibility for tooling to help with > running the tests, plus they can be updated with MRs as they change the > features/UI that they're based on. It seems like they could be more easily > integrated into test management tools as well. Its the same argument as with the checklist. Its important that both the merge checklists as well as the testplans can easily be browsed by anyone. So if this is something that could automagically go on a webpage like read the doc and we have a way to make an easy to navigate index there so someone who wants to test the hell out of component X can easily find all the test plans of component X and all components that might see a side effect I am all for maintaining this content in bzr... However, I don't want to invest CI engineering time in additional tooling before starting this approach ... but if you guys can come up with something smart, lets talk about that so we can coordinate moving to such an approach. However, I think whatever we do, content should come first, so lets not stop working on the content while we discuss tooling :).... > > Glad to see progress happening here, > Ted Thanks! > > > -- > 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 > -- 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
