<p dir="ltr"><br>
On 29 May 2015 20:24, "Stephen J. Turnbull" <<a href="mailto:stephen@xemacs.org">stephen@xemacs.org</a>> wrote:<br>
><br>
> Nathaniel Smith writes:<br>
><br>
>  > DVCS back in the day :-). Unfortunately hg makes this a little<br>
>  > trickier than it could be, because in hg the same commit can't be in<br>
>  > two different branches; but this just means you have to insert some<br>
>  > no-op merges, oh well.<br>
><br>
> Don't use named branches ("friends don't let friends ...").  Use<br>
> bookmarks.  Theoretically that should work fine.</p>
<p dir="ltr">The key is whether or not we can readily notify people when the "most recent known good" hash *changes*, and less about the mechanics of how we then record the history of which commits *were* stable, or the identity of the most recent commit.</p>
<p dir="ltr">That said, prompted by Nathaniel's comment, I realised that having a "post-BuildBot" stable repo is one possible way we could achieve that. That way we could introduce merge gating without needing to change anything at all about how we manage the current development repo, we'd just push stable versions to a separate repo that only the BuildBot master (or a dedicated service monitoring for successful cross-platform BuildBot runs) and the release managers had permissions to push to.</p>
<p dir="ltr">The commit hooks on that *stable* repo could then be used to trigger third party test suites only for builds that at least passed CPython's own test suite.</p>
<p dir="ltr">Cheers,<br>
Nick.<br>
</p>