ubuntu-advantage-tools SRU exception policy review

[Steve Langasek]

On Mon, Oct 23, 2023 at 04:26:53PM +0200, Christian Ehrhardt wrote:
> > I have been reluctant to sign off on this as written because it could be
> > taken to imply that all freezing in the development cycle is ignorable for
> > these purposes.

> As you can imagine that was not the purpose, good call to straighten that
> before approval.
> OTOH I do not want this to cause yet another 4 month detour, so let me try
> to make a suggestion below.

> > While FeatureFreeze starts out fairly relaxed, as we
> > progress to the end of the development cycle the Release Team deliberately
> > becomes more and more strict on exceptions until, around 3 weeks before
> > release, the actual freeze is STRICTER than the requirements for SRUs with
> > the simple rationale that unlike a bad SRU, we cannot roll back a bad
> > freeze
> > exception that finds its way into the release pocket and onto a release
> > image if the breakage is discovered too late.

> You are right, there is some freezing and deep freezing here :-)
> We already have this statement in the document:

> "However, beta freeze and final freeze will still apply in order to manage
> risk in the release itself."

> And of those, while Beta itself is short, it starts the mentioned ~3 strict
> weeks before release.
> If we'd just extend that statement to something like the following, do you
> think that would work or do you expect wider modifications?

> "However, beta freeze and final freeze will still apply in order to manage
> risk in the release itself. In fact we consider the intentionally more
> conservative three week period from beta freeze to release one that we can
> not just ignore, we might have uploads but would expect them to be part of
> the same scrutiny any upload gets at that time."

I propose the following modified language, which I think captures the intent
as simply as possible:

   Since these feature changes may land in stable releases at any time,
   adhering to feature freeze during the development cycle would be
   counterproductive as those changes would be forced to land after release
   instead.  Therefore, feature freeze will not apply when the changes are in
   scope of this document.  However, from beta freeze on uploads of this
   package will be subject to the same additional scrutiny by the Release
   Team as any other package.

> But this all falls under "FeatureFreeze", we don't have any separate freeze
> > checkpoints to externally communicate this gradual ratcheting, it's instead
> > a judgement call by the Release Team.
> >
> > So by saying the feature freeze does not apply, I don't want to wrongly
> > give
> > an impression that these other issues are automatically ignorable, or that
> > the Release Team is bound by agreement to ignore them.
> >
> > I do not immediately have proposed alternate language that I think
> > appropriately addresses this concern, but as you've been waiting for a
> > response for some time now, I wanted to make sure to surface this.  (And
> > apologies for not mentioning it sooner when considering the document, as I
> > was focused on considering the proposed exception with an SRU lens at the
> > time.)
> >
> > > Reference document: https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates

Thanks,
-- 
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                                   https://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: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20231124/becae5b6/attachment.sig>