[all][tc] Relmgt team position on release cadence

Thomas Goirand zigo at debian.org
Tue Nov 9 18:07:39 UTC 2021

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

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... :)


Thomas Goirand (zigo)

More information about the openstack-discuss mailing list