Sent from the wrong email address the first time, sorry. >> 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.
I'm not a big fan of the current delay. We need to make the EWS cycletime shorter. That said, I commonly see the Qt bot and Style bots cycle before I even get a chance to go pull up my bug URL to send it to someone. The bots themselves are generally very quick (except windows), but they only poll every 5 minutes, which makes them feel slow. In either case, there is no minimum cooling off period. You can always chose to ignore the bots. But not posting to a patch means you asked someone to do a review without critical data like "does it build". :) Personally I reject any patches which aren't submitted to me via bugzilla, the bots take care of so much of the reviewing for me. :) >> 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? Opening bugs after the fact is possible. The sherriffbot knows how to do that, iirc. But it's much easier if the commit itself has the bug number so that no one has to go searching for a bug number after the fact. :) >>> 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. Less TPS is entirely the reason for webkit-patch. :) At least my reasons. > 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 - I would be interested to know more. > * It didn't handle subdirectory-only work - Yes, not being an SVN user I don't feel this pain, but I agree this needs fixing. https://bugs.webkit.org/show_bug.cgi?id=28445 is one related bug. > * It often failed with mysterious error messages - Would love to know more. :) >> 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. Well, in the 3 commits in question all of them broke Snow Leopard, which means that either whoever wrote them isn't using a Mac, or they just didn't build themselves. Including a bug number has numerous benefits, but it certainly isn't a panacea and certainly doesn't solve the general shoot-from-the-hip-and-run-away behavior. :) -eric _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
