Open Stack

> - it's usually quicker to push downstream because it's needed. When it
> comes to upstream, it's challenged by the developers (and it's good),
> so it take time and can be discouraging.

I'm sure many operators push downstream first, and then chuck a patch
into upstream gerrit in hopes of it landing upstream so they don't have
to maintain it long-term. Do you think the possibility of it not landing
for a year (if they make it in the first one) or two (if it goes into
the next one) is a disincentive to pushing upstream? I would think it
might push it past the event horizon making downstream patches more of a
constant.

> - writing unit tests is a job, some tech operators are not necessarily
> developers, so this could also be a challenge.

Yep, and my experience is that this sort of "picking up the pieces" of
good fixes that need help from another developer happens mostly at the
end of the release, post-FF in a lot of cases. This is the time when the
pressure of the pending release is finally on and we get around to this
sort of task. Expanding the release window increases the number of these
things collected per cycle, and delays them being in a release by a long
time.

I know, we should just "do better" for the earlier parts of the cycle,
but realistically that won't happen :)

--Dan