On Sat, Mar 19, 2011 at 9:46 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote: > To the extent the buildbots are not overloaded, this strategy will > indeed save developer time, as most changes are more or less > independent of each other (that's why automated merging works at all > well), and most of the time something that passes in a branch will > also pass after merging. So it's probably easier, and certainly less > wearing on other developers, if you detect breakage in the branch > rather than waiting for it to happen in the trunk. However, such > early detection is not guaranteed because not all semantic conflicts > are syntactic conflicts. Ie, the merge may succeed but the code > break. Committers would still be obliged to run the tests *locally* before pushing, so it's only cross-platform issues that would potentially slip through the cracks. That may still turn the buildbots red, of course, but the combination should keep them green more reliably. (e.g. in retrospect, I never would have committed test_crashers in its original state if I had easily been able to run it across the buildbot fleet from my sandbox) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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