[webkit-dev] Yet another bug-less change hosed the tree.

Peter Kasting pkasting at google.com
Mon May 10 13:30:09 PDT 2010

On Mon, May 10, 2010 at 1:23 PM, Geoffrey Garen <ggaren at apple.com> wrote:

> I thought it was generally good practice to have bug.webkit.org bugs
> with changes?
> I wasn't aware of that.
> What value would a bug report add in a situation like
> http://trac.webkit.org/changeset/59086?
> Personally, I'd prefer it if we kept the TPS reports in our project to a
> minimum. In this case, a TPS report would have been more typing than the
> patch itself.

I agree that a 1:1 association between patches and bugs (which has been
suggested to me in the past, thus mentioning it here) seems like a mistake.
 For patches that don't need a bug (although I'm not sure this is in that
category), they're just noise/overhead.  For some bugs whose fixes require
more than one patch, I would much prefer a single bug containing the entire
logical context than separate "bugs" for each piece (especially when the
pieces don't make tons of sense, or have any effect, on their own).

Reading between the lines of Eric's post, it seems like the issue is not so
much that "all patches should have a bug" as that when a patch is posted for
review, the EWS bots can double-check it, whereas if the patch is committed
directly it stands a greater chance of breaking things.  I would take from
this that it seems wise to run the bots over (and thus have a bug for)
things that aren't build fixes, changes in only comments, or patches so
trivial (e.g. adding a "- 1") that the patch is clearly safe by inspection.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100510/528cfee1/attachment.html>

More information about the webkit-dev mailing list