On Nov 28, 2009, at 10:53 AM, Adam Barth wrote:
On Sat, Nov 28, 2009 at 10:21 AM, Maciej Stachowiak <[email protected]>
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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
