On Mon, May 10, 2010 at 1:23 PM, Geoffrey Garen <[email protected]> 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. PK
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
