<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 25, 2023 at 5:12 AM Steve Langasek <<a href="mailto:steve.langasek@ubuntu.com">steve.langasek@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Oct 23, 2023 at 04:26:53PM +0200, Christian Ehrhardt wrote:<br>
> > I have been reluctant to sign off on this as written because it could be<br>
> > taken to imply that all freezing in the development cycle is ignorable for<br>
> > these purposes.<br>
<br>
> As you can imagine that was not the purpose, good call to straighten that<br>
> before approval.<br>
> OTOH I do not want this to cause yet another 4 month detour, so let me try<br>
> to make a suggestion below.<br>
<br>
> > While FeatureFreeze starts out fairly relaxed, as we<br>
> > progress to the end of the development cycle the Release Team deliberately<br>
> > becomes more and more strict on exceptions until, around 3 weeks before<br>
> > release, the actual freeze is STRICTER than the requirements for SRUs with<br>
> > the simple rationale that unlike a bad SRU, we cannot roll back a bad<br>
> > freeze<br>
> > exception that finds its way into the release pocket and onto a release<br>
> > image if the breakage is discovered too late.<br>
<br>
> You are right, there is some freezing and deep freezing here :-)<br>
> We already have this statement in the document:<br>
<br>
> "However, beta freeze and final freeze will still apply in order to manage<br>
> risk in the release itself."<br>
<br>
> And of those, while Beta itself is short, it starts the mentioned ~3 strict<br>
> weeks before release.<br>
> If we'd just extend that statement to something like the following, do you<br>
> think that would work or do you expect wider modifications?<br>
<br>
> "However, beta freeze and final freeze will still apply in order to manage<br>
> risk in the release itself. In fact we consider the intentionally more<br>
> conservative three week period from beta freeze to release one that we can<br>
> not just ignore, we might have uploads but would expect them to be part of<br>
> the same scrutiny any upload gets at that time."<br>
<br>
I propose the following modified language, which I think captures the intent<br>
as simply as possible:<br>
<br>
   Since these feature changes may land in stable releases at any time,<br>
   adhering to feature freeze during the development cycle would be<br>
   counterproductive as those changes would be forced to land after release<br>
   instead.  Therefore, feature freeze will not apply when the changes are in<br>
   scope of this document.  However, from beta freeze on uploads of this<br>
   package will be subject to the same additional scrutiny by the Release<br>
   Team as any other package.<br></blockquote><div><br></div><div>That works perfectly fine for us.</div><div>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.</div><div><br></div><div>[1]: <a href="https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates">https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates</a><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> But this all falls under "FeatureFreeze", we don't have any separate freeze<br>
> > checkpoints to externally communicate this gradual ratcheting, it's instead<br>
> > a judgement call by the Release Team.<br>
> ><br>
> > So by saying the feature freeze does not apply, I don't want to wrongly<br>
> > give<br>
> > an impression that these other issues are automatically ignorable, or that<br>
> > the Release Team is bound by agreement to ignore them.<br>
> ><br>
> > I do not immediately have proposed alternate language that I think<br>
> > appropriately addresses this concern, but as you've been waiting for a<br>
> > response for some time now, I wanted to make sure to surface this.  (And<br>
> > apologies for not mentioning it sooner when considering the document, as I<br>
> > was focused on considering the proposed exception with an SRU lens at the<br>
> > time.)<br>
> ><br>
> > > Reference document: <a href="https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates</a><br>
<br>
Thanks,<br>
-- <br>
Steve Langasek                   Give me a lever long enough and a Free OS<br>
Debian Developer                   to set it on, and I can move the world.<br>
Ubuntu Developer                                   <a href="https://www.debian.org/" rel="noreferrer" target="_blank">https://www.debian.org/</a><br>
<a href="mailto:slangasek@ubuntu.com" target="_blank">slangasek@ubuntu.com</a>                                     <a href="mailto:vorlon@debian.org" target="_blank">vorlon@debian.org</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Christian Ehrhardt<br><span style="color:rgb(34,34,34)">Director of Engineering</span>, Ubuntu Server<br>Canonical Ltd</div></div></div>