From nobody Thu Nov 16 03:38:13 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SW6k46qF7z518KR; Thu, 16 Nov 2023 04:38:52 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor.nl2k.ab.ca (doctor.nl2k.ab.ca [204.209.81.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SW6k44fDhz4dyZ; Thu, 16 Nov 2023 04:38:52 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Authentication-Results: mx1.freebsd.org; none Received: from doctor by doctor.nl2k.ab.ca with local (Exim 4.97 (FreeBSD)) (envelope-from ) id 1r3TCn-00000000J12-48Nx; Wed, 15 Nov 2023 20:38:13 -0700 Date: Wed, 15 Nov 2023 20:38:13 -0700 From: The Doctor To: Glen Barber Cc: John Baldwin , FreeBSD Release Engineering Team , freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule Message-ID: References: <20231114203654.GB52320@FreeBSD.org> <20231115022701.GM1307@FreeBSD.org> <20231115045231.GN1307@FreeBSD.org> <20231116003030.GO1307@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231116003030.GO1307@FreeBSD.org> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6171, ipnet:204.209.81.0/24, country:CA] X-Rspamd-Queue-Id: 4SW6k44fDhz4dyZ 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