Maybe in the case of failure, provide a link to further information? Kenneth
On Sun, Nov 29, 2009 at 3:44 AM, Maciej Stachowiak <[email protected]> wrote: > > 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 > -- 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
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
