Bug 56251 – REGRESSION(r80919): all windows bots failed to compile this change (Requested by loislo on #webkit).

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[WebKit Review Bot]

http://trac.webkit.org/changeset/80919 broke the build:
all windows bots failed to compile this change (Requested by loislo on #webkit).

This is an automatic bug report generated by the sheriff-bot. If this bug
report was created because of a flaky test, please file a bug for the flaky
test (if we don't already have one on file) and dup this bug against that bug
so that we can track how often these flaky tests case pain.

"Only you can prevent forest fires." -- Smokey the Bear

[WebKit Review Bot]

Created attachment 85594 [details]
ROLLOUT of r80919

Any committer can land this patch automatically by marking it commit-queue+.  The commit-queue will build and test the patch before landing to ensure that the rollout will be successful.  This process takes approximately 15 minutes.

If you would like to land the rollout faster, you can use the following command:

  webkit-patch land-attachment ATTACHMENT_ID --ignore-builders

where ATTACHMENT_ID is the ID of this attachment.

[Ilya Tikhonovsky]

Comment on attachment 85594 [details]
ROLLOUT of r80919

Clearing flags on attachment: 85594

Committed r80938: <http://trac.webkit.org/changeset/80938>

[Ilya Tikhonovsky]

All reviewed patches have been landed.  Closing bug.

[Oliver Hunt]

80919 was landed by the commit queue how can it break the build.  The whole point of the commit queue is that you can set cq+ and it will be safe.  That's the only reason I use it.  If it can't be trusted to ensure only non-breaking patches are landed it should be disabled.

[Adam Barth]

(In reply to comment #4)
> 80919 was landed by the commit queue how can it break the build.  The whole point of the commit queue is that you can set cq+ and it will be safe.  That's the only reason I use it.  If it can't be trusted to ensure only non-breaking patches are landed it should be disabled.

It says right here <https://bugs.webkit.org/show_bug.cgi?id=56214#c12> that the patch will break the win build.  The commit-queue just does what human contributors do: it builds and tests the patch on one platform (in this case Apple Mac).

[Oliver Hunt]

(In reply to comment #5)
> (In reply to comment #4)
> > 80919 was landed by the commit queue how can it break the build.  The whole point of the commit queue is that you can set cq+ and it will be safe.  That's the only reason I use it.  If it can't be trusted to ensure only non-breaking patches are landed it should be disabled.
> 
> It says right here <https://bugs.webkit.org/show_bug.cgi?id=56214#c12> that the patch will break the win build.  The commit-queue just does what human contributors do: it builds and tests the patch on one platform (in this case Apple Mac).

The commit queue lands at a random point in the future, if it's not checking all platforms, or ensuring that all platforms successfully built then anyone using it saying "i don't care if this breaks other builds at some point in the future when i may not be around".  My _only_ reason for being okay with the commit queue was the (apparently mistaken) belief that it would not break the build.  Given that it is willing to land breaking changes all it does is delay the failure until some time when the person most able to fix the failure is possibly no longer available.

The commit queue has removed the need for a committer to land and watch the patch and placed that work onto whoever updates on the broken platform first, rather than whoever landed the patch.

[Adam Barth]

If you're interested in continuing this discussion, I'd recommend emailing webkit-dev on the subject.  Before doing that, you might wish to review the previous webkit-dev threads on this topic as it has been discussed before and I'm not aware of any facts that have changed.