On 11/9/21 4:17 PM, Dan Smith wrote:
- 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?
Don't ask your colleagues upstream about what we do! :) With my Debian package maintainer hat on: I will continue to send patch upstream whenever I can.
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.
It used to be that I was told to add unit tests, open a bug and close it, etc. and if I was not doing it, the patch would just stay open forever. This was the early days of OpenStack...
From packager view, that's not what I experienced. Mostly, upstream OpenStack people are nice, and understand that we (package maintainers) just jump from one package to another, and can't afford more than 15 minutes per package upgrade (considering upgrading to Xena meant upgrading 220 packages...). I've seen numerous times upstream projects taking over one of my patch, finishing the work (sometimes adding unit tests) and make the patch land (sometimes, even backport it to earlier releases).
I don't think switching to a 1 year release cycle will change anything regarding distro <-> upstream relationship. Hopefully, OpenStack people will continue to be awesome and nice to work with... :) Cheers, Thomas Goirand (zigo)