June 11, 2012 [dmd-internals] This is why the auto tester is important | ||||
---|---|---|---|---|
| ||||
Hi folks, http://d.puremagic.com/test-results/pulls.ghtml Something like two browser pages of these were 100% green before the master breakage. It's extremely hard to keep track of what pull requests are passing whenever master breaks. I'm not writing this just because I want to whine about red builds for the sake of whining. I'm writing this for practical reasons: Whenever master breaks and all pull requests are reset to a red state, we have to wait for the *entire* pull auto testing queue to process before we can start gaining an overview of what's currently mergeable and what's not. And for the record, this is not a fast process. It takes days, literally. Our pull request review/merge/reject process is slow enough as it stands, and this is not helping. It's very frustrating, as a contributor, to see something this trivial slow down possible merging of pull requests. I imagine I am not alone in feeling this way. All I'm asking is that a look be given to a pull request's state in the auto tester *before* it's merged, so that we don't slow everything down for everyone unnecessarily. Brad's GreaseMonkey script[1] makes this even easier than just opening a separate browser tab. I don't think it's an exaggeration to say that it takes less than 10 seconds to check a pull request's state. (I think I ought to mention that I have been the cause of master breakage at least two times, if memory serves me right. I didn't realize the impact it had until I started reviewing pull requests. Now that I actually rely heavily on the pull auto tester, I've realized just how annoying these master breakages can be when reviewing pull requests (setting aside the issue of master being, well, broken/unbuildable; this is easily rectifiable, but getting all the pull requests into a green state again is very much *not*).) So, please, let's all use the auto tester infrastructure properly. It should not be a guideline, but a *requirement* to check the auto tester before something is merged, IMHO. Thanks and regards, Alex [1] http://d.puremagic.com/test-results/greasemonkey.ghtml _______________________________________________ dmd-internals mailing list dmd-internals@puremagic.com http://lists.puremagic.com/mailman/listinfo/dmd-internals |
June 11, 2012 Re: [dmd-internals] This is why the auto tester is important | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | On 11 June 2012 10:54, Alex Rønne Petersen <xtzgzorex@gmail.com> wrote: > Hi folks, > > http://d.puremagic.com/test-results/pulls.ghtml > > Something like two browser pages of these were 100% green before the master breakage. It's extremely hard to keep track of what pull requests are passing whenever master breaks. > > I'm not writing this just because I want to whine about red builds for the sake of whining. I'm writing this for practical reasons: Whenever master breaks and all pull requests are reset to a red state, we have to wait for the *entire* pull auto testing queue to process before we can start gaining an overview of what's currently mergeable and what's not. And for the record, this is not a fast process. It takes days, literally. Our pull request review/merge/reject process is slow enough as it stands, and this is not helping. It's very frustrating, as a contributor, to see something this trivial slow down possible merging of pull requests. I imagine I am not alone in feeling this way. > > All I'm asking is that a look be given to a pull request's state in the auto tester *before* it's merged, so that we don't slow everything down for everyone unnecessarily. Brad's GreaseMonkey script[1] makes this even easier than just opening a separate browser tab. I don't think it's an exaggeration to say that it takes less than 10 seconds to check a pull request's state. > > (I think I ought to mention that I have been the cause of master breakage at least two times, if memory serves me right. I didn't realize the impact it had until I started reviewing pull requests. Now that I actually rely heavily on the pull auto tester, I've realized just how annoying these master breakages can be when reviewing pull requests (setting aside the issue of master being, well, broken/unbuildable; this is easily rectifiable, but getting all the pull requests into a green state again is very much *not*).) > > So, please, let's all use the auto tester infrastructure properly. It should not be a guideline, but a *requirement* to check the auto tester before something is merged, IMHO. > > Thanks and regards, > Alex > Big +1 from here. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0'; _______________________________________________ dmd-internals mailing list dmd-internals@puremagic.com http://lists.puremagic.com/mailman/listinfo/dmd-internals |
Copyright © 1999-2021 by the D Language Foundation