[webkit-dev] style-queue entering beta

[Maciej Stachowiak]

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>  
> wrote:
>> 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 instead
>> 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
> prefer.
>
>> Could we make a flag that is
>> hidden in the default UI, or use specially formatted comments that  
>> the bot
>> 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:
>
> http://webkit-commit-queue.appspot.com/static/details.html

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:
> http://webkit-commit-queue.appspot.com/patch-status/build-queue-qt/86912/all
>
> 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.
>
> Adam