>> 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
