[webkit-dev] style-queue entering beta
kenneth.christiansen at openbossa.org
Sun Nov 29 08:26:00 PST 2009
Maybe in the case of failure, provide a link to further information?
On Sun, Nov 29, 2009 at 3:44 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Nov 28, 2009, at 10:53 AM, Adam Barth wrote:
> On Sat, Nov 28, 2009 at 10:21 AM, Maciej Stachowiak <mjs at apple.com>
>>> On Nov 28, 2009, at 2:21 AM, Adam Barth wrote:
>>>> 1) "Adding an extra flags is going to cause confusion." The
>>>> style-queue does not add any flags to Bugzilla. Instead of storing
>>>> it's state in Bugzilla flags (like commit-queue does), we built an
>>>> AppEngine web service to hold the queue's persistent state. Instead
>>>> of indicating style errors with a negative flag, the bot adds a
>>>> comment to the bug.
>>> It does seem that flags are noisy in an unappealing way, but it would be
>>> much better (IMO) to store this information in the bugzilla database
>>> of externally. Is there any way we can do that?
>> From an implementation point of view, either way is easy now that
>> we've got the infrastructure built. It's a question of which you'd
>> Could we make a flag that is
>>> hidden in the default UI, or use specially formatted comments that the
>>> knows how to recognize?
>> From my point of view, a hidden flag could work. We considered
>> specially formatted comments, but that would make the bot more chatty.
>> For example, if the style-queue has some internal error that prevents
>> it from processing the patch, it wants to remember that, but it
>> doesn't want to spam the bug with that information.
>> I'm not sure representing all the state in Bugzilla is necessary. We
>> should represent the "most interesting" state (e.g., pass / fail)
>> there. For the rest, we can have a dashboard similar to
>> build.webkit.org that shows the status of various patches before they
>> are committed. I've started sketching something rough here:
> Pass/fail status sounds fine to me. I agree that an error by the bot should
> not be highly visible in the bug, as that is not as useful to the review and
> submitter as Pass or Fail and Here's the Mistakes.
>> You can imagine clicking those squares to see the full log of what
>> happened. For example, if the build failed on Qt, you might want to
>> see the full output of build-webkit --qt, but we don't need to post
>> all that to Bugzilla. The comment might just say:
> Looks like a decent design.
>> Patch 86912 did not build on Qt. Build log:
>> At a higher level, I'm sympathetic to Mark's concerns about what the
>> system will look like when we have a number of bots. Bugzilla flags
>> work well for receiving input from humans. There are lots of choices
>> for how to present output. For example, another option is to have a
>> bunch of colored squares next to each attachment that represent that
>> patch's row on the dashboard.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev