ubuntu-advantage-tools SRU exception policy review
Christian Ehrhardt
christian.ehrhardt at canonical.com
Mon Oct 23 14:26:53 UTC 2023
On Sat, Oct 14, 2023 at 2:32 AM Steve Langasek <steve.langasek at ubuntu.com>
wrote:
> On Thu, Oct 05, 2023 at 12:30:31AM +0100, Robie Basak wrote:
> > On Thu, Sep 14, 2023 at 05:39:50PM +0100, Robie Basak wrote:
> > > This is now ready for feedback and review. We will need sign-offs from
> > > the Pro client developers (the subset of the Server Team that is
> > > maintaining this package) as well as the SRU team, Release Team and
> > > Technical Board. Please see the wiki page for details.
>
> > There's been no feedback, and I understand the SRU team are generally
> > happy with this. So can we move to sign-offs, please?
>
> > Release team: please sign off on "Feature freeze in the development
> > release shall not apply".
>
> 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."
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
>
> --
> 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
>
--
Christian Ehrhardt
Director of Engineering, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20231023/daf6d96f/attachment.html>
More information about the technical-board
mailing list