On 2/28/24 09:45, Tony Breeds wrote:

Hi there,    Happy to approve this as an FFE.  Although if we can get the release out in the next few days.  It'll just be a last minute release rather and FFE :)

Hi there! Well technically, the non-client libs like Oslo were supposed to be released last week according to the schedule, which is why I (and probably others) began packaging them. I'm not against a FFE if needed. Though this really *IS* a FFE, and not a "last minute release" as you worded. Please do remember that any artifact upgrade *after* the planned schedule means double work for package maintainers (and everyone else downstream), which is why we try to follow the schedule, have freeze time, and have FFE when needed. Cheers, Thomas Goirand (zigo)

On 2/29/24 02:36, Takashi Kajinami wrote:

I've received similar feedback in a few other places. This is becoming off-topic from the original FEE discussion but probably it's worth discussing now to avoid the same confusion in the future.

The main factor here is that we create releases at the freeze timing, and then start testing the releases AFTER the freeze, when requirement bump is proposed. This means that any problems found after the release immediately become exceptions. Because of oslo's nature, it's quite difficult to catch all problems in oslo side (we can't run all tests from all projects to gate any change). If we more strictly aim non-client lib freeze then we may need to change some of our workflows here  1. Create the final releases some time BEFORE the freeze  2. Each project adds CI jobs with oslo master to catch problems early  3. Send out email for requirement CI failure to get more attention from project side

Probably having 2. as a non-voting job in each project is the most easily actionable way forward. On 2/29/24 02:36, Takashi Kajinami wrote:

Another factor I'd like to raise is the negligence to deprecation. There are multiple functionalities in oslo which were deprecated some time ago, but literally every time we attempt to remove these, we face the situation where these really old items are still used in some of the projects, with noisy warning ignored for years. The recent situation with sqlalchemy-migrate and sql-a is a clear example I'd say. I'd like to take this time to ask all to pay some more attentions to these ...

I can't agree more (even though the SQLA 2.x fixes were not trivial to write...). Some times ago, we had also some Python language deprecations that were ignored. I'm thinking namely for example about the collection -> collection.abc transition, but that's not the only one. Then guess who's patching when the feature is removed? An example of things that need to be fixed *now*: we currently have a number of datetime.utcnow() calls in Keystone, for example, that have to be removed ASAP. After this summer, Python 3.13 will be released, and then Keystone will fail hard if not fixed (the current workaround is to set warning as ignore instead of failing). This must be fixed at least for Dalmatian, but preferably before, and backported to Caracal, if possible. Cheers, Thomas Goirand (zigo)