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 <e...@webkit.org> wrote: > I agree, I think a commit-...@webkit.org user would be slightly better > than e...@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 <timo...@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-...@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 <jor...@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 <k...@google.com> wrote: >>>>> >>>>> On Wed, Feb 24, 2010 at 3:48 PM, David Levin <le...@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 <k...@google.com> wrote: >>>>>>> >>>>>>> On Wed, Feb 24, 2010 at 12:02 PM, Alexey Proskuryakov <a...@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@lists.webkit.org >>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>> >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org >>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>> >>>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
