[webkit-dev] style-queue entering beta

[Kenneth Christiansen]

Maybe in the case of failure, provide a link to further information?

Kenneth

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>
>> 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
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



-- 
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...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091129/a5560a6c/attachment.html>