Yes, we're working feverishly (is that a good word for this? :) to
make this situation a bit less hard.
However, in the meantime, the process could go like this:
1) Make sure the canary had a green run. This would really help the
WebKit gardener to know which revision to roll up to.
2) Land your patch upstream. There's no need to close the tree -- the
only thing you'll break is the canary bot.
3) Let the gardener to roll up to last green revision
4) In parallel, prepare a patch that rolls deps to your revision,
including your fix. Since the gardener's roll is green, you shouldn't
have any breakage. If you do, it's your fault :) <--- this is
basically the key to sanity. Don't land your one-revision roll if it
breaks your local compile.
5) Let the gardener land their patch
6) Sync and land your patch right after the gardener lands.
If you have more than one of these, rinse and repeat. I don't think it
is a good idea to land multiple breakages and then sort them out
downstream.
The situation is much muddier when you are already dealing with
multiple breakages upstream. That was the case early this week. In
this case, the gardener:
1) finds the breaking rev by studying the canary and trac.webkit.org,
2) checks that the rev before indeed builds, and sort out whatever
test regressions it may have locally
3) Lands the roll
4) Depending on the nature of the breakage, calls the expert. I am
working on a list that will include various parts of our port, but for
now you could just ping levin, darin, or me (in that order ;)
5) The expert will do a one-rev roll, fixing the breakage.
Basically, the idea is to let the gardener roll while green, and make
one-rev rolls/fixes for bustage.
For gardeners: I can not emphasize enough that it is *much* easier to
roll deps many times a day in small, green increments. Use the canary,
it'll tell you the revs that are safe to roll. Otherwise, you'll be
landing large swaths full of red and wonder at the fireworks in
amazement. Don't wait for the end of the day.
Another note: today, most of the layout test failures you'll see after
a merge are either new tests or changes in expectations that just need
rebaselining. The regressions should be rare and cause for alarm.
Please look at the tests, failing on the canary. Rebaseline or file
bugs if we're not passing for a good reason. Don't sweep them under
the test_expectations rug. It is *much* harder to dig through the
hundreds of lines of failures, trying to figure this out after the
fact.
Hope this helps. Sorry this is a bit too long, I am trying to get to
actually putting this in a more stable format, and this time is as
good as any.
:DG<
On Thu, Jun 25, 2009 at 4:46 PM, Darin Fisher<da...@chromium.org> wrote:
> I suspect there are things we can do that will avoid much of the need to do
> a Chromium side change in unison with a WebKit side change. #1 is probably
> upstreaming some .gypi files so that the set of files to build can be stored
> in svn.webkit.org. The WebKit API will also help, and completing the
> upstreaming of V8 is another biggie.
> -Darin
>
> On Thu, Jun 25, 2009 at 3:53 PM, Adam Langley <a...@chromium.org> wrote:
>>
>> Dear Lords of the WebKit, I come to you seeking guidance about how
>> best to avoid the mess that the tree got into this afternoon.
>>
>> Japhet and I both had two sided patches to land (where one needs to
>> land both the WebKit and Chromium sides together). We emailed the
>> merger for the day (jianli) and asked him to email us when the merge
>> landed.
>>
>> He did so and I closed the tree. japhet and I both started landing
>> upstream. I landed r45191 and the Chromium side (including a large
>> DEPS roll) in r19287. japhet landed upstream in r45193 and r19291.
>>
>> The tree went red because V8IsolatedWorld had landed upstream in the
>> mean time and needed an include file changed because of japhet's
>> upstreaming. I TBRed upstream (r45201) and rolled DEPS (r19295).
>> However, that pulled in several other upstream patches, one of which
>> broke the build in another way! So I TBRed upstream to fix that
>> (r45203) and rolled DEPS again (r19298). Thankfully, due to fleetness
>> of keyboard, no other patches landed upstream in the mean time.
>>
>> In the past, for small patches, I've emailed the WebKit merger with
>> the patch to land. However, for larger patches, esp those which might
>> have conflicts, this seems unfortunate. It also breaks the SVN
>> log/blame for the future.
>>
>> How best to deal with this now that we pull directly from upstream?
>> Should I just have reverted Chromium at the first sign of trouble?
>>
>>
>> AGL
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
