juju-core feature uploads during feature freeze

[Steve Langasek]

On Mon, Aug 24, 2015 at 11:26:56AM +0100, Robie Basak wrote:
> > At some point during the release cycle I imagine you'll want to start using
> > the SRU process anyway instead of pushing into release, so that you have the
> > added flexibility and protection of -updates in the event of regressions.  I
> > assume you will let us know when you get to that point, if you need to do
> > any uploads of juju-core in this window before the release.

> If I understand you correctly, I think we have the
> flexibility/protection you suggest by virtue of our current process,
> which doesn't need the -updates pocket during the development release at
> all. Please could you confirm? The original thread discussing this is at
> [1], but here's a summary of what we're doing based on that thread:

> We've been using the 'block-proposed' tag in our tracking bugs, thus
> holding the upload (the proposed upstream release) in the -proposed
> pocket in the development release in combination with holding the update
> in the -proposed pocket in stable releases as part of the normal SRU
> verification process.

> Then, if any tests fail (eg. SRU verification failure), the idea is that
> upstream won't release that particular version at all (burning the
> upstream version number) and we won't have regressed anything. We can
> fail the SRU process and continue to block proposed migration in the
> development release until we have a newer proposed release from upstream
> ready.

> If tests pass, then upstream release and then we remove 'block-proposed'
> and add 'verification-done'.

> In practice due to sponsorship delays we often don't have uploads ready
> before upstream have released quite yet, but we hope to close this gap
> soon. In the meantime it doesn't actually make any difference in Ubuntu
> since if necessary we would still fail SRU verification and development
> release proposed migration after testing anyway.

> Once we've closed the gap then upstream releases will be more closely
> synced to availability in the Ubuntu archives (both development and
> stable -updates pockets).

> [1] https://lists.ubuntu.com/archives/ubuntu-release/2014-October/003041.html

So to clarify the question: for -updates pockets, we have phased-update
support which will automatically notice increases in the rate of crashes for
an SRUed package.  If an SRU shows as having regressions, the phasing rate
drops to zero so that we stop rolling it out to users, and we can sort this
out with a follow-on SRU.  There is no equivalent for the release pocket -
if the package is uploaded to SRU pockets for < 15.10, and to release for
15.10, then users of 15.10 would be stuck with that version until the next
SRU goes out because there will be no earlier version available that they
can fall back to.

Supposing a regression is found after the juju-core SRU has been released,
how would that be handled?  And what implications does this have for
publishing to wily-updates instead of wily, close to the time of the
release?

Also, I anticipate juju-core being included on the server images for 15.10.
So it's possible that the cutoff date for redirecting juju-core uploads to
-updates will be "when we need to get testing done on the release images".

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- 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/20150824/13dc0d2b/attachment.pgp>