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

[Adam Barth]

On Tue, May 11, 2010 at 2:11 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>> For fun, I scrolled back through WebCore/ChangeLog looking for a
>> non-build fix that was missing a bug link.  The first one I found was
>> 160 revs ago.  I suspect the vast majority of patches already have bug
>> reports.
>
> Did you verify that they all waited for EWS bot results before committing?

Nope, although I suspect that most patches are up for review for more
than a few minutes.  :)

>> We require a ChangeLog for every patch.  Isn't that a TPS report?
>
> No. A ChangeLog is much less time-consuming to manage.

I think a good goal is for bug management to take less time than
dealing with ChangeLogs.

>> Another perspective is that we have lots of tools to help you not
>> break the build.  If you bypass those tools and break the build,
>> you're going to piss people off.
>
> We've discussed having a rigid green tree policy in the past. This line of discussion seems to say, "We know the project decided against a rigid green tree policy, but we'd like to have one anyway."

You're saying that breaking the tree doesn't piss people off?  As a
random example, I've had dhyatt yell at me in IRC when I've broken the
tree.  In fact, before we had these tools, I used to break the tree a
lot and got yelled at by plenty of folks, including Mark Rowe.

On Tue, May 11, 2010 at 2:30 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>>> Maybe I would use webkit-patch if it really were quite easy. I tried it in earnest for a while, but I had to give it up because:
>>> * I couldn't find a ChangeLog workflow that fit its demands, so using it was actually more complicated than doing everything by hand
>>
>> Can you explain this in more detail?
>
> I don't know how to do either of these steps in an easy way:
>
> 1. Once I have a patch with a ChangeLog, say, "File a new bug and upload this patch for review." (Bonus points if the tool automatically made the first line of the ChangeLog the title of the bug.)

Yeah, we don't handle that case very well.  I've filed
<https://bugs.webkit.org/show_bug.cgi?id=38945>.  We need some code to
fill the bug URL into an existing ChangeLog that similar to the code
we use to fill in the reviewer.

> 2. Once the patch has been reviewed, say, "Add bug # and reviewer information from Bugzilla, commit, and close the bug." (Bonus points if the commit happens via the bugzilla patch, so I can move on to working on another patch.)

There are two cases here:

A) Your working copy has a ChangeLog that references the bug but says
"Reviewed by NOBODY."
B) Your working copy has a ChangeLog that does not reference a bug,
but the patch was already reviewed in bugs.webkit.org.

In case (A), all you need to do is type "webkit-patch land" as Maciej
mentioned in a later email.  (Note, you might have to update to
top-of-tree if your checkout is out of date, like you need to with svn
commit.)

If you mean case (B), you shouldn't get into that case once we fix (1)
above because we'll fill in the bug number into the ChangeLog when you
upload it to bugs.webkit.org (which happens before the patch can be
reviewed in bugs.webkit.org).

> I'd be willing to try any set of steps that accomplishes these tasks.

Great.  I'll ask you to be a beta tester once we fix Bug 38945.

> The last time I tried it, webkit-patch was close, but it never quite got there. The ChangeLog seemed to be the main sticking point.

Any feedback you have is quite helpful.  From my perspective, the tool
is "done" in the sense that it does everything I want it to do.  If
you want it to do more, please ask.

>>> * It didn't handle subdirectory-only work
>>
>> I think here you're refer to the fact that SVN is slow.  There was a
>> thread earlier about making webkit-patch operate on the current
>> directory instead of on whole working copy.  We can certainly do that
>> if you'd find that helpful.
>
> Yes, I'd find it helpful.
>
> Slow is one problem. But I also tend to have patches in different parts of the tree -- for example, WebKitTools -- which I don't want to include in my uploaded patch.

Ok, I think we've had enough folks ask for this that we should do it.
I'll work up a patch and post a separate thread letting people know of
the change.

Thanks,
Adam