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 # From my view, quite limited people other than requirements team pay attention to requirement CI failure, # which sometimes delays fixing the problems caused by library changes. 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 ... Finally, please be mindful that oslo team is now quite small (2 relatively active and 2 less active) while we have to maintain nearly 20 repos. I don't like insisting this really, but even I myself is not dedicated to oslo (Actually I'm not dedicated to even OpenStack...) but have had spent enormous time to deal with the oslo (and a few other dependencies) release works recently, to settle things down better. We can do further better, for sure, but I can't guarantee that I spend more effort like attending every single meeting of every project, checking every single line of code of every project to access any single change in oslo and so on, to address these problems only by oslo side. On 2/29/24 01:53, Thomas Goirand wrote:
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)