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)