Date: Thu, 16 Nov 2023 00:07:36 -0500 From: Glen Barber <gjb@freebsd.org> To: The Doctor <doctor@doctor.nl2k.ab.ca> Cc: John Baldwin <jhb@freebsd.org>, FreeBSD Release Engineering Team <re@freebsd.org>, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule Message-ID: <5F24BC3A-88D9-4295-AA94-435C11A1F445@freebsd.org> In-Reply-To: <ZVWOpeS8CIi5gsTm@doctor.nl2k.ab.ca> References: <ZVWOpeS8CIi5gsTm@doctor.nl2k.ab.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
And if there is a reason to reissue a release, the update will reflect such.= So to answer your latter question, yes. Unless it needs to be replaced. Glen Sent from my phone. Please excuse my brevity and/or typos. > On Nov 15, 2023, at 11:38 PM, The Doctor <doctor@doctor.nl2k.ab.ca> wrote:= >=20 > =EF=BB=BFOn 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 be= fore >>>>>>>> the announcement of 14.0-RELEASE will be ready. >>>>>>>>=20 >>>>>>>> It should only be another day or so before these things complete. >>>>>>>>=20 >>>>>>>> Thank you for your understanding. >>>>>>>>=20 >>>>>>>=20 >>>>>>> I always just installed my copy. >>>>>>>=20 >>>>>>=20 >>>>>> 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 intend= ed >>>>>> for the general public of consumers of official releases, not "yeah, >>>>>> but"s. >>>>>>=20 >>>>>=20 >>>>> Howver if you do a freebsd-update upgrade, you can upgrade. >>>>>=20 >>>>> Is that suppose to happen? >>>>>=20 >>>>=20 >>>> That does not say that the freebsd-update bits will not change *until* >>>> the official release announcement has been sent. >>>>=20 >>>> In my past 15 years involved in the Project, I think we have been very >>>> clear on that. >>>>=20 >>>> A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT. >>>>=20 >>>> I mean, c'mon, dude. >>>>=20 >>>> We really, seriously, for all intents and purposes, cannot be any more >>>> clear than that. >>>>=20 >>>> So, yes, *IF* an update necessitates a new freebsd-update build, what >>>> you are running is *NOT* official. >>>>=20 >>>> For at least 15 years, we have all said the same entire thing. >>>=20 >>> 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). >>>=20 >>> 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. >>>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> My email was intended to be informative. Period. >>=20 >> 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. >>=20 >> 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. >>=20 >> The alternative would be to say nothing at all. >>=20 >> 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. >>=20 >> Glen >>=20 >>=20 >=20 > What ahappened was that I inititated the freebsd-upgrade RELEASE upgrade c= ommand. >=20 > question should that RELEASe been released? >=20 > --=20 > Member - Liberal International This is doctor@nk.ca Ici doctor@nk.ca > Yahweh, King & country!Never Satan President Republic!Beware AntiChrist ri= sing! > 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 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5F24BC3A-88D9-4295-AA94-435C11A1F445>