W dniu 16.11.2023 o 12:19, The Doctor pisze:
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 <doc...@doctor.nl2k.ab.ca> 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.
Thank you for testing and reporting, that's appreciated.
Anyway, not using real name and escalating this way you look more like a
troll than FreeBSD tester to me. Instead of complaining here you'd
better support FreeBSD and Glen's effort by donating a few bucks to either:
https://www.gofundme.com/f/gjbbsd
and/or
https://freebsdfoundation.org/donate/
With kind regards
--
Marek Zarychta
