From nobody Thu Nov 16 11:19:35 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 4SWJn749Ngz50Zbh; Thu, 16 Nov 2023 12:12:11 +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 4SWJn72VrYz4Y5M; Thu, 16 Nov 2023 12:12:11 +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 1r3aPH-000000007FZ-1E0a; Thu, 16 Nov 2023 04:19:35 -0700 Date: Thu, 16 Nov 2023 04:19:35 -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: <5F24BC3A-88D9-4295-AA94-435C11A1F445@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: <5F24BC3A-88D9-4295-AA94-435C11A1F445@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: 4SWJn72VrYz4Y5M On Thu, Nov 16, 2023 at 12:07:36AM -0500, Glen Barber wrote: > 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 wrote: > > > > ???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? > > Here is what happened. Since Openssl 1.X is no longer supported I switch to 14.0-RC4 and found for the most part that RC4 is 98 % there. Given the web site saying expect a release notice around 10 Nov, I deciced to try to see if 14.0 RELEASE was ready. Since then I found 1, port openvpn is not stable 2, wireguard FrreBSD client to FreeBSD serve is not working 3) Dovecot is acting glitchy. -- 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