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

[Geoffrey Garen]

>> What value would a bug report add in a situation
>> like http://trac.webkit.org/changeset/59086?
> 
> Having a bug serves a couple useful purposes:
> 
> 1) Your patch can be reviewed by other members of the project who
> aren't sitting next to you on couch.

I don't think anyone else had a review comment about this patch. Did they?

> 2) Your patch can be vetted by the various bots that analyze patches
> posted for review.

True, if what you're really asking for is not just a bug report but also a "cooling off period" during which you wait for a result from the EWS bot, even if you get a review right away. You get greater value in the case of a bad patch, but also greater cost in the case of every patch.

> 3) The but serves as a coordination point for dealing with bustage
> caused by a patch and for regressions detected later.

Isn't it just as easy to open a bug on demand, if regressions are detected?

>> 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.
> 
> That's part of what motivated us to create webkit-patch, which makes
> creating and managing bugs and patches quite easy.

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
* It didn't handle subdirectory-only work
* It often failed with mysterious error messages

> When you go cowboy and commit without
> building and testing, you impose costs on everyone else in the
> project.

Probably not fair to conflate shooting a six-shooter with committing without filling out a bugzilla form first.

Geoff