[webkit-dev] Yet another bug-less change hosed the tree.
abarth at webkit.org
Mon May 10 14:26:13 PDT 2010
On Mon, May 10, 2010 at 2:09 PM, Peter Kasting <pkasting at google.com> wrote:
> On Mon, May 10, 2010 at 2:05 PM, Adam Barth <abarth at webkit.org> wrote:
>> On Mon, May 10, 2010 at 1:30 PM, Peter Kasting <pkasting at google.com>
>> > 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.
>> Your email appears to be discussing having more than one patch
>> associated with a given bug report. That seems like a different topic
>> than Eric's email, which was about a patch with no bug at all.
> My email was mostly discussing Eric's email, but also mentioned "multiple
> patches" in passing (one full sentence was devoted to them; the rest of the
> email was about Eric's issue).
My apologies, I misread your email. Responses below.
On Mon, May 10, 2010 at 1:30 PM, Peter Kasting <pkasting at google.com> wrote:
> For patches that don't need a bug (although I'm not sure this is in that
> category), they're just noise/overhead.
That's somewhat tautological. I think the question for which patches
does creating a bug out-weigh the noise and overhead.
> 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.
If you'll allow me to climb higher on my horse, I'll advocate for
landing patches like this through the commit queue. I don't know the
full context of this patch, but if you don't need the patch to be
committed synchronously, the added vetting by the commit queue reduces
the likelihood that you'll break the world.
As a point of reference, the commit queue lands about 30% of all
patches and cause much less than 30% of the forest fires.
If you wish to land your patch using the commit queue, here's the TPS
report you need to fill out:
That will take your working diff and upload it to the bug mentioned in
the ChangeLog and mark it for commit by the bot. I usually follow
that command with "git reset --hard" to clean my working copy, but
what you do after that is up to you.
> 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.
Indeed. However, in addition to bot integration, there are also
"people integration" benefits to using the bug tracker.
More information about the webkit-dev