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

[Jeremy Orlow]

On Tue, May 11, 2010 at 10:11 PM, Geoffrey Garen <ggaren at apple.com> wrote:

> > We require a ChangeLog for every patch.  Isn't that a TPS report?
>
> No. A ChangeLog is much less time-consuming to manage.
>

For me, letting webkit-patch make the bug for me and post updates to the bug
is maybe 10-15 seconds longer than doing the entire process manually
_without_ creating a bugzilla bug.  That's far less time than I put into
change logs.


> > Another perspective is that we have lots of tools to help you not
> > break the build.  If you bypass those tools and break the build,
> > you're going to piss people off.
>
> We've discussed having a rigid green tree policy in the past. This line of
> discussion seems to say, "We know the project decided against a rigid green
> tree policy, but we'd like to have one anyway."


What exactly is a "rigid" green tree policy?  I know that WebKit has the
policy to roll out patches that cause redness after 15ish mins if the author
can't be contacted (or if the author can't quickly fix the problem).  I
consider that fairly rigid (in a good way), so I guess your use of "rigid"
is referring to the level of testing before committing a patch?

I took a look at http://webkit.org/coding/contributing.html and it only
lists compiling and testing as "recommended" steps.  Maybe we (as a project)
should better document our expectations regarding compiling/testing patches.
 Here's some proposed text:

"""
When possible, committers should test their patches at least by compiling
and running all the layout tests on them.  When your patch touches
port-specific code, you should ideally do the same on those platforms as
well.  The WebKit <a href=...>Early Warning System (EWS)</a>
tests compilation on several WebKit ports and runs the layout tests on the
mac port, so waiting for those bots to show green is an alternative to
running the tests by hand.
"""

I'm not exactly sure what page text like this would belong on, though.
 Maybe the contributing page?  Maybe the webkit committers/reviewers policy?


On Tue, May 11, 2010 at 10:28 PM, Peter Kasting <pkasting at google.com> wrote:

> On Tue, May 11, 2010 at 2:20 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>
>>  > Yes, this way of doing things has more overhead for you personally but
>> > saves overhead for everyone else in the project.
>>
>> I don't think it's fair to frame my perspective as "me personally" and
>> your perspective as "everyone else in the project."
>>
>
> I don't think that's a valid interpretation of the above sentence.  It
> seems to simply be saying "there is a cost to the patch creator of running
> the patch past the bots, and there is a cost to the developer community at
> large if the tree is broken", which is undeniably true.
>
> If you'll permit me to editorialize, my guess is that some Google employees
>> prefer a rigid green tree policy because it matches their internal
>> development process, and it makes integrating with that process and
>> committing patches for other Google employees easier.
>>
>
> As a Google employee I am puzzled as to how a green tree policy "makes
> integrating with the process and committing patches for other Google
> employees easier".  You seem to be suggesting that familiarity/similarity to
> another policy is some sort of benefit.  I can't see how that's true, nor
> have I ever heard a Google employee suggest such.  For the people who would
> prefer a green tree policy, I suspect the rationale is that they believe it
> lowers overall development costs, irrespective of what other policies on
> other projects may be, which clearly you do not agree with.
>

Exactly.  Chromium has a "WebKit Gardener" rotation for this purpouse.  The
current gardener watches the various bots to decide what the latest WebKit
CL that's safe to use with Chromium is.  If there's breakage in WebKit, we
obviously don't roll to one of those CLs.  So really, the WebKit tree being
red has almost no impact on Chromium development.  Note that Adam and Eric
are not on this rotation, so their arguments can't be based on what's
easiest for the integration process in Chromium (or anything like that).

That said, many WebKit developers (who happen to work for Google and/or on
Chromium) find the tree being red a problem for other reasons.  Whether or
not you personally agree with the commit queue, a lot of WebKit developers
do.  And tree redness is not compatible with that.  Personally, I like being
able to just sync to head and assume that there's a very good chance the
code will just work.  Requiring everyone who's syncing a tree to go to
build.webkit.org seems annoying.

But most importantly, when you allow failures to linger around, it becomes
much harder to pinpoint where regressions crept in.  I remember at least one
well documented case of such a thing happening (and taking several people
over a day to figure out) being posted to webkit-dev.  Avoiding such
problems is the primary reason why rolling out regressions and/or fixing
regressions quickly is important to many WebKit developers (including some
who happen to work on Chromium or for Google).

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100512/b4ea4665/attachment.html>