Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Fri, Nov 17, 2023 at 11:00:07AM +0100, Olivier Certner wrote: > Hi Glen, > > > 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. > > Yes, and given that, I don't think you did anything wrong. > > It seems that the race is the same for freebsd-update(8), according to "The > Doctor". But maybe in this case it is easier to fix, perhaps if installing > the metadata signaling the new release to it can be delayed, by contrast with > big files containing the actual data (I don't know how freebsd-update(8) > works, so this is just a guess). > > > The alternative would be to say nothing at all. > > I really hope you and re@ will never choose this way. > > > 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. > > IMHO, a delay should always be announced (perhaps unless it's only a few > days). If it is too hard to decide on the right level of details, then only > mention that some (potential or verified) problem is being looked upon, but > don't let that prevent you from communicating. > > As for people saying that they have already installed the "release", I'd > suggest to have some text on the website (https://www.freebsd.org/releng/ > perhaps) explaining that images on mirrors can appear in advance of release > announcements and that they should not be considered as official until the > official mail is sent, and just kindly point them to it. I hope this can > contribute to at least attenuating the drain you're experiencing. > > Regards. > > -- > Olivier Certner > > just a suggestion for the future is that to have some sort of gpg/gpg check in freebsd-update . -- Member - Liberal International This is doc...@nk.ca Ici doc...@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
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
Glen Barber wrote: > No. It merely suggests the release is not officially official yet. Ok. Thanks for the clarification. Jamie.
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
Hi Glen, > 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. Yes, and given that, I don't think you did anything wrong. It seems that the race is the same for freebsd-update(8), according to "The Doctor". But maybe in this case it is easier to fix, perhaps if installing the metadata signaling the new release to it can be delayed, by contrast with big files containing the actual data (I don't know how freebsd-update(8) works, so this is just a guess). > The alternative would be to say nothing at all. I really hope you and re@ will never choose this way. > 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. IMHO, a delay should always be announced (perhaps unless it's only a few days). If it is too hard to decide on the right level of details, then only mention that some (potential or verified) problem is being looked upon, but don't let that prevent you from communicating. As for people saying that they have already installed the "release", I'd suggest to have some text on the website (https://www.freebsd.org/releng/ perhaps) explaining that images on mirrors can appear in advance of release announcements and that they should not be considered as official until the official mail is sent, and just kindly point them to it. I hope this can contribute to at least attenuating the drain you're experiencing. Regards. -- Olivier Certner
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Thu, Nov 16, 2023 at 09:22:52PM +, Jamie Landeg-Jones wrote: > > 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. > > Foe a recent new build, I just went to the ftp site to grab the latest rc, > only to see 14.0-release there, so I grabbed and installed that, many > hours before your original mail went out. > > No biggy, I generally track stable, but does this mean we can't rely > on the download sites without checking out the lists first? It's not > like I was plaing sneaky by doing "guess the URL" or anything like that. > No. It merely suggests the release is not officially official yet. Glen signature.asc Description: PGP signature
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
> 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. Foe a recent new build, I just went to the ftp site to grab the latest rc, only to see 14.0-release there, so I grabbed and installed that, many hours before your original mail went out. No biggy, I generally track stable, but does this mean we can't rely on the download sites without checking out the lists first? It's not like I was plaing sneaky by doing "guess the URL" or anything like that. Jamie
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 +, 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 +, 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 +, 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 > >>
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 +, 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 +, 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 +, 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 doc...@nk.ca Ici doc...@nk.ca > Yahweh, King & country!Never
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
Thank you for that. Glen Sent from my phone. Please excuse my brevity and/or typos. > On Nov 15, 2023, at 11:17 PM, Rich Reynolds wrote: > > On 11/15/23 20:19, Pete Wright wrote: >>> On 11/15/23 16:30, Glen Barber wrote: >>> 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 I appreciate your transparency and the efforts you have done to keep >> everyone in the loop. I think people get excited about new releases, which >> is probably a good thing. IMHO i feel you've been striking a good balance. >> As an operator these updates are really helpful for me as it allows me to >> adjust timelines on my end for updating my fleet of servers. You and the RE >> team do an incredible job - and personally I am thankful for the caution and >> common sense you all bring to this complex process. >> Cheers, >> -pete >> -- >> Pete Wright >> p...@nomadlogic.org >> @nomadlogicLA > +1 from a retired RE manager > yet another hard thankless job in the development chain... > > -- > When you beleve in things. that you don't understand, > then you suffer, superstition ain't the way. > Stevie Wonder - 1972 >
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Thu, Nov 16, 2023 at 12:30:30AM +, 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 +, 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 +, 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 doc...@nk.ca Ici doc...@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
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Wed, Nov 15, 2023 at 07:19:39PM -0800, Pete Wright wrote: > > > On 11/15/23 16:30, Glen Barber wrote: > > 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 I appreciate your transparency and the efforts you have done to keep > everyone in the loop. I think people get excited about new releases, which is > probably a good thing. IMHO i feel you've been striking a good balance. > > As an operator these updates are really helpful for me as it allows me to > adjust timelines on my end for updating my fleet of servers. You and the RE > team do an incredible job - and personally I am thankful for the caution and > common sense you all bring to this complex process. > Thank you very much, Pete, for your email on this. It is appreciated by all of us involved in FreeBSD releases. Best regards, Glen signature.asc Description: PGP signature
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On 11/15/23 16:30, Glen Barber wrote: 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 I appreciate your transparency and the efforts you have done to keep everyone in the loop. I think people get excited about new releases, which is probably a good thing. IMHO i feel you've been striking a good balance. As an operator these updates are really helpful for me as it allows me to adjust timelines on my end for updating my fleet of servers. You and the RE team do an incredible job - and personally I am thankful for the caution and common sense you all bring to this complex process. Cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 +, 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 +, 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 signature.asc Description: PGP signature
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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 +, 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 +, 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. -- John Baldwin
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
Well, today is your yesterday, so we might not be ready for another more tomorrows your time, yesterdays, my time. Or something. Glen Sent from my phone. Please excuse my brevity and/or typos. > On Nov 15, 2023, at 2:39 AM, matti k wrote: > > On Wed, 15 Nov 2023 04:52:31 + > Glen Barber wrote: > 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. > >> 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. > > Here I have been tracking 14.0 release candidates > > Reminds me of when slashdot would announce a new release days before it > was actually released and then someone would remind them of that > > I am using an Australian mirror so will probably need to wait an extra > day to be on the safe side :-) > > > >
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Wed, 15 Nov 2023 04:52:31 + Glen Barber wrote: > > > 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. > > > > 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. Here I have been tracking 14.0 release candidates Reminds me of when slashdot would announce a new release days before it was actually released and then someone would remind them of that I am using an Australian mirror so will probably need to wait an extra day to be on the safe side :-)
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote: > On Wed, Nov 15, 2023 at 02:27:01AM +, 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 +, 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. Glen signature.asc Description: PGP signature
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Wed, Nov 15, 2023 at 02:27:01AM +, 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 +, 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? > Glen > -- Member - Liberal International This is doc...@nk.ca Ici doc...@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
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote: > On Tue, Nov 14, 2023 at 08:36:54PM +, 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. Glen signature.asc Description: PGP signature
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
On Tue, Nov 14, 2023 at 08:36:54PM +, 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. > Glen > On behalf of: re@ > -- Member - Liberal International This is doc...@nk.ca Ici doc...@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
[HEADS-UP] Quick update to 14.0-RELEASE schedule
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. Glen On behalf of: re@ signature.asc Description: PGP signature
