> On 25 Nov 2021, at 13:37, Thomas Deutschmann <whi...@gentoo.org> wrote: > For the records: > I hope that this news item won't get delayed by the recent ComRel bug someone > filled against me regarding this news item.
No need to reference that here. Please keep that to e.g. -core. > While we often rush with news items and don't wait the 72h listed in GLEP 42, > this one should go out as soon as possible. > Why? > Because every minute we wait will increase the chance that someone affected > by this will be unable to recover. This is (for those not familiar with > database engines) because bin logs are about to expire (getting overwritten) > in typical setups after 3-5 days. And in case someone will learn about this > not before next week and has to do a full restore, that user will lose about > one week of data... While it seems like the news item may be worth pursuing out of caution, I would expect people operating sophisticated database setups to do at least one of: - slot the DB version in their world file; - mask newer versions and unmask when ready; - upgrade all machines to the same version at the same time (for clustering); - read the world upgrade output and not permit the downgrade? I also echo the other requests to add a downgrade warning based on ${REPLACING_VERSIONS} given this is a common issue with databases. Also, while this does not affect the rationale for this news item, I would note that I would expect anybody using Gentoo in production to be using stable or at the very least to have backups of a server running on ~arch that they're upgrading without reading the upgrades/downgrades carefully for software they rely on. thanks, sam
signature.asc
Description: Message signed with OpenPGP