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

[Eric Seidel]

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