June 11, 2012
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
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