Juju SRU and QA plans

[Robie Basak]

Dear Release Team,

I'd like to change how I upload Juju to the archive, both to the
development release and SRUs, for QA purposes.

I'd like to understand if this is 1) workable technically and the best
way to do it; and 2) reasonable and acceptable process-wise.

First, an explanation of why I want the process to be different.

In Ubuntu, we want QA on binaries in trusty-proposed before accepting
them into trusty-updates. If a bug is found, then we will remove the
binary from trusty-proposed and not publish it in trusty-updates.

Juju upstream want to consider any bug that prevents inclusion into
trusty-updates as an upstream release blocking bug. That is: upstream do
not want to release something that would subsequently fail to enter
trusty-updates.

So there is an ordering issue here. With the normal process, we'd
consider entry into trusty-updates after an upstream release. But here,
upstream don't want to release until the update has passed Ubuntu's QA.

A Juju upstream release follows a step that is relevant to us here,
which is that upstream also now have a -proposed equivalent.

Can we tie these together in a way that would be acceptable to our
existing processes in Ubuntu?

For example:

(I'm not sure my understanding is accurate about devirt PPAs, pocket
copies, our process around them and who has permission to do them, and
thus if this would even work technically. Corrections appreciated.)

What if I arrange a devirt PPA and upload to it when upstream proposes a
release. I would target both utopic and trusty-proposed, but instead of
uploading as I might to do the archive, I upload to this PPA instead.

Then upstream QA (and anyone else) can test the proposed binary packages
from this PPA to help decide whether upstream should release. If QA
fails at this stage, upstream will not release, fix the issue and skip
the version number for the next proposed release. In this case I'll just
delete from the PPA.

When upstream release, I can pocket copy (including binaries) to both
utopic-proposed and trusty-proposed respectively. After the upload to
trusty-proposed is accepted by the SRU team, our QA result from the
devirt PPA should still be valid, so we should be able to mark
verification-done immediately.

I'm not proposing to reduce the 7-day minimum aging period, who can
upload, or the control the SRU team has of what enters trusty-proposed.
I would have only src:juju-core packages in a dedicated devirt PPA used
for this task.

I think I'm just asking:

1) Will this work technically
2) Is it acceptable for us to have pre-verified a binary and pocket copy
it into trusty-proposed?
3) Any other issues?

Thanks,

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/20141007/c13d9cf0/attachment.pgp>