[webkit-dev] Commit queue blocked because of failing tests

[Eric Seidel]

Also, I think that the argument that the (common) "commit-queue breaks
annotate" is not really accurate.

The commit-queue does change what user name it puts next to the line
in the default annotate view (in the command line)[1].  But the
username in that view is almost entirely useless (at least for
tracking down bugs).  I always find myself needing to look at the
actual commit diff (including ChangeLog) to understand what changed.
At which point what username did the commit is meaningless.

The commit-queue does make it more difficult to write scripts which
try to attribute changes to a person.  But not much harder given how
easy ChangeLogs are to parse and how we already have a parsing library
(and a committer full-name lookup library). :)

-eric

1.  Trac doesn't even display the user name, just the revision number:
http://trac.webkit.org/browser/trunk/WebCore/page/PrintContext.cpp?annotate=blame&rev=54533

On Thu, Feb 25, 2010 at 2:22 PM, Eric Seidel <eric at webkit.org> wrote:
> I agree, I think a commit-bot at webkit.org user would be slightly better
> than eric at webkit.org committing everyone's patches.
>
> I disagree that committers should feel any need to land their own
> patches.  Humans suck at repetitive tasks.  Humans break the build all
> the time and then go AFK.  The bot has caused remarkably few tree
> fires in its 6 months of operation.  Any tree fires it does cause are
> (fixable) bugs in the bot.  Once we see it happen, we can fix the bot
> to make it never happen again.  We can't fix humans who break the
> build.
>
> There are also ways that submission queues can make svn/git blame
> work.  But the only two that I know: having a script fix up the SVN
> repository after the commit, or converting the project to use a Git
> repository -- which tracks committer separate from author -- seem
> difficult to implement for WebKit.
>
> -eric
>
> On Thu, Feb 25, 2010 at 6:57 AM, Timothy Hatcher <timothy at hatcher.name> wrote:
>> I agree with Jeremy and David. If you are a committer you should try to land patches on your own when you can. I mainly think this because it lets svn/git blame work as intended instead of always blaming who ran the bot. Maybe we should have a commit-bot at webkit.org user?
>>
>> On Feb 25, 2010, at 5:41 AM, Eric Seidel wrote:
>>
>>> On Thu, Feb 25, 2010 at 5:26 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
>>>> It also frees up the queue for those who need it.
>>>
>>> A common misconception, but looking at the logs the commit-queue looks
>>> to be no where near capacity.  I believe it could commit every change
>>> done to WebKit in a day and still not be near capacity. :)
>>>
>>> The only thing that prevents the commit-queue from cycling regularly
>>> is the bots breaking (this includes flakey tests). :(
>>>
>>> -eric
>>>
>>>>
>>>> On Thu, Feb 25, 2010 at 1:17 AM, Kenneth Russell <kbr at google.com> wrote:
>>>>>
>>>>> On Wed, Feb 24, 2010 at 3:48 PM, David Levin <levin at chromium.org> wrote:
>>>>>> 1. It looks like you are a committer, so you don't need to wait for the
>>>>>> commit queue to do this for you :)
>>>>>
>>>>> Understood -- but I prefer to use the bots where possible. I've seen
>>>>> multiple instances where the commit scripts failed to add new files
>>>>> for some reason, but the bots have always been 100% reliable.
>>>>>
>>>>> -Ken
>>>>>
>>>>>> 2. But it still would be good to have this fixed. If you'd like to help
>>>>>> move
>>>>>> this along, you can go to http://build.webkit.org/waterfall and find
>>>>>> which
>>>>>> patch caused the test to start failing. Then ping the relevant person.
>>>>>>
>>>>>> On Wed, Feb 24, 2010 at 3:41 PM, Kenneth Russell <kbr at google.com> wrote:
>>>>>>>
>>>>>>> On Wed, Feb 24, 2010 at 12:02 PM, Alexey Proskuryakov <ap at webkit.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 24.02.2010, at 11:47, David Levin wrote:
>>>>>>>>
>>>>>>>> Actually, it doesn't appear to be do to recent changes in this
>>>>>>>> area. They
>>>>>>>> started failing after r55177
>>>>>>>> (http://build.webkit.org/waterfall?last_time=1266975298), but that
>>>>>>>> change is
>>>>>>>> unrelated to these test as far as I can tell.
>>>>>>>>
>>>>>>>> It looks unrelated, but it somehow broke these editing tests
>>>>>>>> nonetheless.
>>>>>>>> I'm investigating now.
>>>>>>>
>>>>>>> Thanks. Our patch (from https://bugs.webkit.org/show_bug.cgi?id=34459)
>>>>>>> was about to be landed by the bot when the tree went red again. The
>>>>>>> test now failing is:
>>>>>>>
>>>>>>> fast/dom/prototype-inheritance-2.html -> failed
>>>>>>>
>>>>>>> Could someone please look?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> -Ken
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> webkit-dev mailing list
>>>>> webkit-dev at lists.webkit.org
>>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>
>>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>