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

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 <doctor@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