ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

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

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

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.

Glad to see progress happening here,
Ted

Attachment: signature.asc
Description: This is a digitally signed message part