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
signature.asc
Description: Digital signature
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release