[webkit-dev] Frustrated at inconsiderate behavior
jorlow at chromium.org
Wed Jul 7 09:49:43 PDT 2010
I agree with Maciej's response, but at the same time I can understand why
Adam was so frustrated. He (and others) have pointed out stuff like this on
and off list over and over again with little apparent change...
But that's not what I'm most worried about; why this was broken in the tree
for 12 hours?? It seems like, at the very least, every single person who
committed in that time frame should have taken a look at the tree after
committing . Why did not one of those people roll the patch out when it
was clear that there were failures and Alexey wasn't in the process of
 Yeah, in theory looking before hand and not landing while it's on fire
is better, but I'm talking about the _bare minimum_ of what should have
On Thu, Jul 8, 2010 at 12:18 AM, Adam Barth <abarth at webkit.org> wrote:
> Sorry for singling you out Alexey. I was just frustrated last night.
> On Wed, Jul 7, 2010 at 8:58 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
> > 07.07.2010, в 00:47, Adam Barth написал(а):
> >> If you're tired of my complaining about the tree being red, you can
> >> skip this message.
> > I understand that you're frustrated, but I think that you're
> misinterpreting what happened.
> >> 1) He could have run-webkit-tests before committing his change.
> > I did that. I made the mistake of running a wrong subset though (forgot
> that local xmlhttprequest tests were no longer in fast/dom).
> Maybe the root cause here is that the test suite takes too long to
> run? We can make run-webkit-tests faster...
> >> 2) If he didn't have time to run the tests locally, he could have used
> >> the commit-queue to run-webkit-tests before it landed his patch.
> > Using commit-queue while it still doesn't provide correct svn blame is
> trading short term problems for longer term ones. Yes, one can still open a
> changeset by number, but having names really helps read svn blame.
> This problem is now fixed thanks to William Siegrist. Patches written
> by committers show up correctly in SVN blame and trac even if they're
> landed by the commit-queue.
> >> 3) He could have looked at the tree when sheriff-bot informed him that
> >> he might have broken Leopard Intel Debug by pinging him in #webkit and
> >> commenting on his bug:
> >> <https://bugs.webkit.org/show_bug.cgi?id=41156#c8>.
> > I worked with Qt guys on fixing tests on Qt, and I watched the tree,
> which didn't show any sign of a problem from my patch at the time. Perhaps
> I'm starting to rely on sheriff bot too much - it didn't complain about any
> platforms besides Leopard Intel Debug.
> It only complains once to avoid spamming when it makes a mistake.
> > Leopard builder was seriously broken yesterday, so I didn't pay attention
> when it complained about a problem many hours later. In retrospect, that was
> a mistake.
> I think we can improve this by having sheriff-bot say which tests
> broke. I bet if you saw these tests listed, you'd have realized what
> was going one.
> >> these failures remained in the tree until I cleaned them up
> > I see that Tiger bot still has a unique failure, and will investigate it
> as soon as possible.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev