Juju SRU and QA plans

Robie Basak robie.basak at ubuntu.com
Wed Oct 8 10:19:00 UTC 2014

On Wed, Oct 08, 2014 at 06:49:05AM +0200, Martin Pitt wrote:
> Steve Langasek [2014-10-07 17:14 -0700]:
> > Given that Juju is covered by a provisional micro release exception[1], I
> > don't understand the ordering concern.  MREs are granted on the condition
> > that the upstream release process is sufficient to QA the update, without a
> > separate verification step in Ubuntu.
> Well, it only means that we don't need individual bug reports, test
> cases, and bug fix verification for each issue. We still *do* require
> running the regression test plan to ensure that the binary was
> correctly built and works with the corresponding release. That of
> course can be done in a PPA beforehand as well (and any failure of the
> rebuild in *-proposed would then be a really improbable
> surprise/disaster). But there still *is* a separate verification step
> for MRE SRUs normally.

Right. I test juju-quickstart against a juju-core in trusty-proposed
(and before an upload to utopic-proposed) manually right now, pending
some automation with a dep8 test.

We don't have automatic dep8 test runs in trusty-proposed yet (which is
bug 1321691), but this is something that is desirable. When we do have
it, we're going to have a ton more QA going on in trusty-proposed which
upstream can't realistically run.

I also now have a Canonical team that consumes Juju interested in
testing any updates destined for trusty-updates this time round. It
would be easier for them to do this with a package in trusty-proposed
(or a PPA) than to test from upstream's proposed release directly, since
it is the packaged archive version that they consume in the end. And
this applies equally to any third party that is interested.

I think the more QA is done by third parties, the better. We will still
have the aging time in trusty-proposed, so that wouldn't be taken away,
but it would be nice if upstream could also make use of this third party
testing to prevent a release going out in the first place.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20141008/cb6ad4e3/attachment.pgp>

More information about the Ubuntu-release mailing list