<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote" style>Thanks for clarification.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Jul 2, 2014 at 6:59 PM, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 2014-07-02 16:14:52 +0400 (+0400), Yuriy Taraday wrote:<br>
> Why do we need these short-lived 'proposed' branches in any form?<br>
> Why can't we just use release branches for this and treat them as<br>
> stable when appropriate tag is added to some commit in them?<br>
<br>
</div>The primary reasons are:<br>
<br>
1. People interpret "stable/juno" as an indication that it is a<br>
stable released branch, so "proposed/juno" makes it a little more<br>
obvious to those people that it isn't yet.<br></blockquote><div><br></div><div style>That could be dealt with by naming them "release/juno" instead, I think.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


2. Current process delegates pre-release change approval to a<br>
different group of reviewers than post-release change approval, and<br>
the easiest way to enforce this is through Gerrit ACL matches on<br>
different git ref patterns for their respective target branches.<br></blockquote></div><div class="gmail_extra"><br></div>But this one is rather hard to overcome without temporary branch or constant ACL changes.</div><div class="gmail_extra">

<br></div><div class="gmail_extra">It looks like mirrors will have to bear having a number of dead branches in them - one for each release.<br clear="all"><div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>