[webkit-dev] Are roll-outs getting a little out of hand?
oszi at inf.u-szeged.hu
Mon Jun 20 06:39:48 PDT 2011
Darin Adler wrote:
> I noticed these three roll-outs:
It broke all non-V8 build as you mentioned later because of stricter
gcc treats warnings as errors. I checked the bug today , and suggested
a fix for the build fail: https://bugs.webkit.org/show_bug.cgi?id=62904
The original change was committed by a Qt developer. I think the minimum
requirment is that a developer should build his/her patch at least on
his/her platform before landing. (Fixed patch was already landed.)
It broke 22 tests on all platform, and the author, Oliver Hunt
confirmed this rollout was fine. (Fixed patch was already landed.)
> Were all of these necessary? Was there a way to fix the problem instead of rolling out in any of these cases?
It might be. Fix for the 1st and the 2nd build break was quite simple.
But I don't have time to fix them on saturday morning. I think rolling
out was better than leaving the build broken for 2 days and let the
authors to fix their bugs themselves.
Broken build is the worst thing, because buildbot can't catch new layout
regressions if the build is broken. In my opinion WebKit developers should
take contributing rules seriously to make the lives of other developers easier.
"Once you have made your changes, you need to run the regression tests, which
is done via the run-webkit-tests script. All tests must pass. Patches will not
be landed in the tree if they break existing layout tests."
Keeping the tree green
"Your change must at least compile on all platforms."
Rolling out is the last thing what I do with a wrong patch. First I try to contact
the author and/or the reviewer on #webkit. If he/she doesn't answer, I try to fix
the bug myself (if I have time and enough knowledge to do it.) After a roll-out I
usually help the author to fix the Qt part of the patch.
Csaba Osztrogonác (Ossy)
University of Szeged
More information about the webkit-dev