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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4