Neil-

Édouard Thuleau posted a similar fix [3] on 4th December, and we agreed that his was better, so I abandoned mine. His fix attracted a +2 on 11th December, but has been sitting like that ever since.

Expecting any fix - even a trivial one - to get merged in less than a month when that month includes most of December is expecting a lot. That said...

It's a fix that I would expect to be simple to review, so I wonder if there's something else we could have done here to get this moving?  Or if there is a systemic problem here that deserves discussion?

In this specific case I think the issue is a dearth of "core hours" available to the python-openstackclient project. Dean (dtroyer) and Monty (mordred) are the main cores there, and their time is *very* divided. Absent some signal of urgency to garner their attention and cause them to prioritize it over other work, a given change has a decent chance of languishing indefinitely, particularly as other more urgent work never ceases to pile up.

I'm struggling to say this positively, but... it feels like OpenStack promotes refactoring work that will likely break something, but is very slow when a corresponding fix is needed, even when the fix is trivial. Is there something we could do to get fixes done more quickly when needed?

Presumably this generalization is based on more than just the above fix. Certainly it doesn't apply to all patches in all projects. But to the extent that it is true, it often has the same root cause: shortage of maintainers. This is a message that needs to be taken back to companies that continue to expect OpenStack to be maintained without investing in the human power necessary to create cores. #brokenrecord efried .