Home Original page

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

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