[Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.) (original) (raw)

Nathaniel Smith njs at pobox.com
Fri May 29 09:36:25 CEST 2015

On Thu, May 28, 2015 at 11:40 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 29 May 2015 9:17 am, "Antoine Pitrou" <solipsis at pitrou.net> wrote:

On Thu, 28 May 2015 08:48:11 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote: > After all, the real difference between the alphas and the final releases > isn't about anything we do, it's about the testing other people do > that > picks up gaps in our test coverage. A gated trunk makes it more feasible > for other projects to do continuous integration against it. Long ago (before I became a core developer) we had "community buildbots" for that. They didn't receive any attention or maintenance from third-party projects. Right, but it's hard to integrate against trunk when trunk itself may be broken. If we had a way of publishing "known good" commit hashes that passed the test suite on all the stable buildbots, that could potentially provide a basis for integration testing without needing to switch to merge gating first.

ISTM the most natural way to publish a "known good" commit hash is by updating a branch head to point at the latest good version. In fact this is pretty much the exact use case that motivated the invention of DVCS back in the day :-). Unfortunately hg makes this a little trickier than it could be, because in hg the same commit can't be in two different branches; but this just means you have to insert some no-op merges, oh well.

Interestingly, this is almost identical to merge gating (at least, if I'm correctly guessing what you mean by that -- the "not rocket science rule"?), just with different names for the branches :-).

-n

-- Nathaniel J. Smith -- http://vorpus.org

More information about the Python-Dev mailing list