ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Thu, 2014-01-09 at 11:16 +0100, Alexander Sack wrote:

> Sorry for not replying earlier, but somehow the reponses to this
> mailthread didnt make it in my inbox until today? really odd...



Probably running on a cloud instance and this is the first time it got
I/O  ;-)


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


K, it seems that pulling from the Bazaar branches for all the projects
is pretty easy.  The harder part is coming up with the list of projects
that should have the file in them.  Is the cu2d list the authoritative
list?  If it's not, it'd be nice if we had one list to rule them all.


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


K, so I'm guessing training times, locations, etc. are still in the
works.  Thanks for clarifying.


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


Sure, just worried we're not integrating with what other teams are
doing.  It seems there are already tools that QA has for taking manual
tests and importing them into the QA tracker.

http://qa.ubuntu.com/getting-involved/manual-tests/

It seems less important to have the tests written than to have a process
where they can be run and tracked.  If we can't run them and track them,
having all the tests written is just bytes on a drive.

Ted

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