ubuntu-phone team mailing list archive

[Alexander Sack <asac@xxxxxxxxxxxxx>]

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 <ted@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>