Open Stack

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
.