[release] making releases fast again (was: decentralising release approvals)

Radosław Piliszek radoslaw.piliszek at gmail.com
Thu Jan 9 17:08:53 UTC 2020


Hi Sean,

just to verify my interpretation.
This means e.g. [1] is now good to go?
2 release team members, 1 liaison and 1 PTL extra (for stable release).

[1] https://review.opendev.org/701080

-yoctozepto

czw., 9 sty 2020 o 18:03 Sean McGinnis <sean.mcginnis at gmx.com> napisał(a):
>
> On Fri, Dec 20, 2019 at 11:04:36AM +0100, Thierry Carrez wrote:
> > Mark Goddard wrote:
> > > [...]
> > > As kolla PTL and ironic release liaison I've proposed a number of
> > > release patches recently. Generally the release team is good at churning
> > > through these, but sometimes patches can hang around for a while.
> > > Usually a ping on IRC will get things moving again within a day or so
> > > (thanks in particular to Sean who has been very responsive).
> >
> > I agree we've seen an increase in processing delay lately, and I'd like to
> > correct that. There are generally three things that would cause a
> > perceptible delay in release processing...
> >
> > 1- wait for two release managers +2
> >
> > This is something we put in place some time ago, as we had a lot of new
> > members and thought that would be a good way to onboard them. Lately it
> > created delays as a lot of those were not as active.
> >
> > 2- stable releases
> >
> > Two subcases in there... Eitherthe deliverable is under stable policy and
> > there are *significant* delays there as we have to pause to give a chance to
> > stable-maint-core people to voice an opinion. Or the deliverable is not
> > under stable policy, but we do a manual check on the changes, as a way to
> > educate the requester on semver.
> >
> > 3- waiting for PTL/release liaison to approve
> >
> > That can take a long time, but the release management team is not really at
> > fault there.
> >
>
> Coming back to hopefully wrap this up...
>
> We discussed this in today's release team meeting and decided to make some
> changes to hopefully make things a little smoother. We will now use the
> following guidelines for reviewing and approving release requests:
>
> For releases in the current development (including some time for the previous
> cycle for the release-trailing deliverables) we will only require a single
> reviewer. If everything looks good and there are no concerns, we will +2 and
> approve the release request without waiting for a second. If the reviewer has
> any doubts or hesitation, they can decide to wait for a second reviewer, but
> this should be a much less common situation.
>
> For stable releases, we will require two +2s. We will not, however, wait for a
> designated day for stable team review. If we can get one, all the better, but
> the normal release team should be aware of stable rules and look for them for
> any stable release request. Keeping the requirement for two reviewers should
> help make sure nothing is overlooked with stable policy.
>
> We do still want PTL/liaison +1 to appove, so we will continue to wait for
> that. Thierry is working on some job automation to make checking for that a
> little easier, so hopefully that will help make that process as smooth as
> possible.
>
> If there are any other questions or concerns, please do let us know.
>
> Sean
>



More information about the openstack-discuss mailing list