<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"></div></div><div dir="auto"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 20 Dec 2019, 10:06 Thierry Carrez, <<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Mark Goddard wrote:<br>
> [...]<br>
> As kolla PTL and ironic release liaison I've proposed a number of <br>
> release patches recently. Generally the release team is good at churning <br>
> through these, but sometimes patches can hang around for a while. <br>
> Usually a ping on IRC will get things moving again within a day or so <br>
> (thanks in particular to Sean who has been very responsive).<br>
<br>
I agree we've seen an increase in processing delay lately, and I'd like <br>
to correct that. There are generally three things that would cause a <br>
perceptible delay in release processing...<br>
<br>
1- wait for two release managers +2<br>
<br>
This is something we put in place some time ago, as we had a lot of new <br>
members and thought that would be a good way to onboard them. Lately it <br>
created delays as a lot of those were not as active. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2- stable releases<br>
<br>
Two subcases in there... Eitherthe deliverable is under stable policy <br>
and there are *significant* delays there as we have to pause to give a <br>
chance to stable-maint-core people to voice an opinion. Or the <br>
deliverable is not under stable policy, but we do a manual check on the <br>
changes, as a way to educate the requester on semver.<br>
<br>
3- waiting for PTL/release liaison to approve<br>
<br>
That can take a long time, but the release management team is not really <br>
at fault there.<br>
<br>
Could you describe where you've seen "sometimes patches can hang around <br>
for a while"? I suspect they belong in the (2) category?<br></blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I hadn't realised there was a requirement for the stable team to review stable patches. That could explain some of my experience. It could also be due to kolla being cycle-trailing, we often make releases at unusual times.</div><div class="gmail_default" style="font-family:verdana,sans-serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> [...]<br>
> I have a few questions for the release team about these reviews.<br>
> <br>
> * What manual checks do you do beyond those that are currently automated?<br>
<br>
See <a href="https://releases.openstack.org/reference/reviewer_guide.html" rel="noreferrer noreferrer" target="_blank">https://releases.openstack.org/reference/reviewer_guide.html</a><br>
<br>
> * Could the above checks be automated?<br>
<br>
We aggressively automate everything that can be. Like I'm currently <br>
working to automate the check that the release was approved by the PTL <br>
or release liaison.<br>
<br>
> * What issues have you caught that were not caught by CI jobs?<br>
<br>
It's generally semver violations, or timing issues (like requesting a <br>
release during a freeze). Sometimes it's corner cases not handled (yet) <br>
by automation, like incompatibility between the release version asked <br>
and the deliverable release model. You can look at the history of <br>
releases for examples.<br>
<br>
> Hopefully I haven't offended anyone here. There's often more involved <br>
> with these things than you first suspect.<br>
<br>
Decentralizing would be a lot of work to create new systems and <br>
processes... and I don't think we can automate everything. It's <br>
unreasonable to expect everyone to know the release process by heart and <br>
respect timing and freezes. And releases are the only thing we produce <br>
that we can't undo.<br>
<br>
I would rather eliminate the issue by making sure release processing is <br>
back to fast. So here is my proposal:<br>
<br>
- go back to single release manager approval<br></blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">This seems like it should make a big difference - reducing the load on reviewers and the requirements for approval should reduce time in flight.</div><div class="gmail_default" style="font-family:verdana,sans-serif"> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- directly approve stable releases after a cursory semver check, not <br>
waiting for stable-maint-core approval.<span style="font-family:verdana,sans-serif"></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
That should make sure all releases are processed within a couple of <br>
days, which I think is a good trade-off between retaining some releases <br>
for 10+ days and not having a chance to catch odd ca<span class="gmail_default" style="font-family:verdana,sans-serif"></span>ses before releases <br>
at all.<br>
<br>
Thoughts?<br></blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Thanks for the detailed response. I tend to prefer models where teams can be self-sufficient using shared tooling and policies, but I'm also missing some context and history, and don't have to clean up when things go wrong. Ultimately, you've proposed some simple changes which should improve the situation, so that's a good result in my view.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
Thierry Carrez (ttx)<br>
<br><br>
</blockquote></div></div>
</div>