ubuntu-phone team mailing list archive

[Ken VanDine <ken.vandine@xxxxxxxxxxxxx>]

On Tue, Jan 7, 2014 at 10:26 AM, 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).
>

I think putting the checklist in the repository is a great idea!  And if we
could keep it in a machine readable format, eventually we could have
friendly tools for validating each item in the checklist.


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