<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:Arial,Helvetica,sans-serif">On Fri, Apr 12, 2019 at 2:27 PM Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/11/2019 3:47 PM, Lingxian Kong wrote:<br>> <br>> I've already replied in the patch, since you also mentioned the patch <br>> here, i think it's necessary also reply you here.<br>> <br>> That patch failed to get attention from other team members and the <br>> community who are not interested in such change, as the PTL, i have to <br>> merge it myself to not block other patches. At the same time, some users <br>> were complaining the current trove image build approach, which could be <br>> improved with that patch.<br>> <br>> If self-approved is something you disagree, I'd appreciate if you could <br>> offer some help for the review.<br>
<br>I realize Trove is in a tough spot so I'm not trying to criticize and I <br>understand the frustration of waiting to get something merged that you <br>or your customers need. I don't have great answers for these problems. I <br>was simply trying to highlight the fact that while that patch may be <br>appropriate to merge on master it may not be appropriate to merge on <br>stable, so there are different rules if you're following the stable <br>policy and that's why cores on master aren't necessarily cores on stable <br>branches.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">Totally understand, thanks for the explanation. That's why I explained in the above email that it's not my original requirement to become a stale core, the first email was just a heading up to ask help for the stable branch review.</div></div><div class="gmail_default" style="font-family:monospace,monospace"><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>At the same time I'm coming from a place where we try to enforce some <br>kind of standards across projects under openstack TC governance, and <br>trove is in a tough spot there.<br>
<br>But as Mohammed pointed out, if Trove elects to *not* follow the stable <br>policy then we simply have to remove the "stable:follows-policy" tag <br>from governance and trove is free to backport as it pleases (I think? <br>Tony can correct me).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">In the current situation, i prefer to follow the ways that people who care about the project(I mean, Trove) and are willing to offer help to fix things should have the permission to merge patches to stable. So, according to <a href="https://governance.openstack.org/tc/reference/tags/stable_follows-policy.html#deprecation">https://governance.openstack.org/tc/reference/tags/stable_follows-policy.html#deprecation</a>, as Trove PTL of Train dev cycle, can I ask to remove stable:follows-policy tag for Trove?</div></div><div><div class="gmail_default" style="font-family:monospace,monospace"></div></div><div class="gmail_default" style="font-family:monospace,monospace"><div class="gmail_default">---</div><div class="gmail_default">Cheers,</div><div class="gmail_default">Lingxian Kong</div><div class="gmail_default">Catalyst Cloud Team</div></div></div></div></div></div></div>