> 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

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to