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

On Thu, Nov 16, 2023 at 12:30:30AM +0000, Glen Barber wrote:
> 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
> 
> 

What ahappened was that I inititated the freebsd-upgrade RELEASE upgrade command.

question should that RELEASe been released?

-- 
Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism ; unsubscribe from Google Groups to be seen
Lest we forget 11 Nov 2023 Beware https://mindspring.com