Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule

On Wed, Nov 15, 2023 at 08:39:39AM -0800, John Baldwin wrote:
> On 11/14/23 8:52 PM, Glen Barber wrote:
> > On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote:
> > > On Wed, Nov 15, 2023 at 02:27:01AM +0000, Glen Barber wrote:
> > > > On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote:
> > > > > On Tue, Nov 14, 2023 at 08:36:54PM +0000, Glen Barber wrote:
> > > > > > We are still waiting for a few (non-critical) things to complete before
> > > > > > the announcement of 14.0-RELEASE will be ready.
> > > > > > 
> > > > > > It should only be another day or so before these things complete.
> > > > > > 
> > > > > > Thank you for your understanding.
> > > > > > 
> > > > > 
> > > > > I always just installed my copy.
> > > > > 
> > > > 
> > > > Ok.  I do not know what exactly is your point, but releases are never
> > > > official until there is a PGP-signed email sent.  The email is intended
> > > > for the general public of consumers of official releases, not "yeah,
> > > > but"s.
> > > > 
> > > 
> > > Howver if you do a freebsd-update upgrade, you can upgrade.
> > > 
> > > Is that suppose to happen?
> > > 
> > 
> > That does not say that the freebsd-update bits will not change *until*
> > the official release announcement has been sent.
> > 
> > In my past 15 years involved in the Project, I think we have been very
> > clear on that.
> > 
> > A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT.
> > 
> > I mean, c'mon, dude.
> > 
> > We really, seriously, for all intents and purposes, cannot be any more
> > clear than that.
> > 
> > So, yes, *IF* an update necessitates a new freebsd-update build, what
> > you are running is *NOT* official.
> > 
> > For at least 15 years, we have all said the same entire thing.
> 
> Yes, but, if at this point we had to rebuild, it would have to be 14.0.1
> or something (which we have done a few times in the past).  It would be
> too confusing otherwise once the bits are built and published (where
> published means "uploaded to our CDN").  It is the 14.0 release bits,
> the only question is if for some reason we had a dire emergency that
> meant we had to pull it at the last minute and publish different bits
> (under a different release name).
> 
> Realistically, once the bits are available, we can't prevent people from
> using them, it's just at their own risk to do so until the project says
> "yes, we believe these are good".  Granted, they are under the same risk
> if they are still running the last RC.  The best way to minimize that
> risk going forward is to add more automation of testing/CI to go along
> with the process of building release bits so that the build artifacts
> from the release build run through CI and are only published if the CI
> is green as that would give us greater confidence of "we believe these
> are good" before they are uploaded for publishing.
> 

You are correct on all points.  If there were a need to re-roll 14.0, it
would indeed necessitate a release/14.0.1 tag.  Note, release/14.0.0 has
not yet been tagged, and I find it extremely unlikely that it will be
necessary to rebuild from a release/14.0.1 tag.

I also agree we cannot prevent people from downloading the images,
installers, whatever before the announcement.  That is the lovely race
condition with which we have to live at the moment.

My email was intended to be informative.  Period.

There were no suggestions that 14.0-RELEASE was not yet final.  And to
be fair, I had to personally deal with the fallout of a release "too
soon", notably 11.0-RELEASE, where I thought a critical issue had been
addressed, but I was wrong.

My only point, in being overly open to the public on the delay, is that
we (the Release Engineering Team) are not yet ready to rubber-stamp this
as complete, as there are some outstanding items that are pending that
have not yet completed.

The alternative would be to say nothing at all.

Either way, it is a productivity, communication drain.  It is
a lose-lose situation no matter how one looks at it given the above
context.  We either get chastised for being "too open" into insights
delaying an official announcement, or for being "not open enough" when
there is silence from RE when a release does not meet its scheduled
announcement date.

Glen