On Fri, 29 May 2015 21:39:55 +1000 Nick Coghlan <ncogh...@gmail.com> wrote: > 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. > > 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.
Any amount of merge gating or other automated workflow is dependent on stabilizing our test suite and buildbot fleet, so that regressions can be unambiguously spotted. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
