On Sat, Nov 25, 2023 at 5:12 AM Steve Langasek <steve.langa...@ubuntu.com>
wrote:

> 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.
>

That works perfectly fine for us.
The rest of [1] was already in the state that was discussed and agreed so
far, therefore I updated the paragraph in [1] to use your words and this
should now be complete.

[1]: https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates

> 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/
> slanga...@ubuntu.com                                     vor...@debian.org
>


-- 
Christian Ehrhardt
Director of Engineering, Ubuntu Server
Canonical Ltd
-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Reply via email to