- 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