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
-- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
