[tc][stable] Changing stable branch policy

Jeremy Stanley fungi at yuggoth.org
Wed Nov 20 15:01:38 UTC 2019

On 2019-11-20 08:49:23 -0600 (-0600), Ben Nemec wrote:
> Even if something merges, it still has to be proposed for release,
> at which point the release liaison or PTL should be looking at it,
> and then once the release is proposed the release team is going to
> look at the changes included. So there is a safety net if a
> reviewer makes a mistake.

True in principle, but we've basically always treated stable
branches as a place from which downstream consumers can consume
patches, and the stable point releases on them are more of a
formality. I may simply not be connected with the right segments of
our community, but I haven't heard anyone say they specifically
wait to consume stable branch point releases vs just taking the
branch content at a random point in time or selectively picking
relevant patches out of it to incorporate into a packaged version...
and even the theoretical stable point release reviewer safety net
vaporizes for branches which pass into extended maintenance mode.

However, the above should not be taken as an objection on my part
for the plan. I agree the real safety net here is the users, and the
lessons a reviewer learns after helping a panicked user of their
software work around a regression or behavior change which should
never have been allowed to merge on a stable branch in the first
place. Failure is the best teacher.
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20191120/3c84161c/attachment.sig>

More information about the openstack-discuss mailing list