Juju SRU and QA plans

[Robie Basak]

Replying to both Steve and Adam here, since I think they touch upon the
same point.

On Tue, Oct 07, 2014 at 05:14:57PM -0700, Steve Langasek wrote:
> 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.  If this QA is happening as expected,
> what problems would you expect to turn up at the SRU verification stage that
> wouldn't have already been caught by upstream's own testing?

[answered in Martin's subthread]

> If upstream hasn't yet released, then it would seem incorrect to upload
> these packages to the devirt ppa using an upstream release version number.

I was assuming that it would be incorrect to upload to the archive using
an upstream proposed release version number, but that a PPA would be OK,
provided that I am careful to not copy anything to the archive before
and only if the version is actually released.

On Tue, Oct 07, 2014 at 07:30:49PM -0600, Adam Conrad wrote:
> If upstream doesn't intend to reuse version numbers...

Right. I've discussed this with upstream and they have committed to not
re-using version numbers that they have proposed for release and then
don't release.

>                                                   ...you're over-
> complicating with the PPA business.  Just do this "soft" release to
> proposed, test it and, if it sucks, remove and iterate, if it's good,
> everyone wins.

This sounds good to me, but this assumes that it's OK to push these into
the archive, and I had assumed that this wasn't the case.

Are Adam and Steve saying the opposite thing here? I think a crucial
point we need to agree is where it is and isn't acceptable to push
a proposed version with the final version number.

> If the concen is auto-migration in the devel series, you can file
> blocking bugs that you close when the upstream QA is complete, so
> that "bad" binaries don't slip in, thus mirroring the SRU process.

Ack.

Robie
-------------- 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/d3405d22/attachment.pgp>