That seems optional to me. I don't see why it matters that much. The canary bots will still be using DEPS from svn.chromium.org, so we should get sufficient coverage there. That will allow us to be confident about updating WebKit, right? The upstream builder is first and foremost designed to help non-Chromium WebKit contributors build and repair the PLATFORM(CHROMIUM) port. So, all we need for that is a stable set of dependencies. They don't strictly speaking need to be up-to-date unless there is an interface change of course.
-Darin On Tue, Sep 29, 2009 at 8:44 PM, Dmitry Titov <[email protected]> wrote: > I guess WebKit gardener will need to bump the WebKit DEPS to the version > numbers from Chromium if Chromium's go ahead... To have more predictable > result of roll and to keep them more or less in sync... > > On Tue, Sep 29, 2009 at 7:43 PM, Darin Fisher <[email protected]> wrote: > >> That's basically what we had before. >> You can add entries to a DEPS file that have the value From("foo"), and >> that causes the value of the entry to be taken from the path foo/DEPS, where >> foo is a directory at the same level as the directory containing the DEPS >> file that mentioned From("foo"). Originally, chrome's DEPS file lived in >> chrome/DEPS instead of src/, and the submodules were the ones that were >> siblings to the chrome directory. >> There's a lot of shared dependencies. I'm not sure that for trunk >> development, it makes sense to require a WebKit roll to update DEPS for all >> of those shared dependencies. I'm concerned that will slow us down. >> >> Can we try having separate sets of dependencies for now? I think the >> point of the WebKit standalone build is to help vet changes to WebCore. It >> is less about vetting changes to the modules. The canary bot can cover >> those. >> >> We could write a tool to sync deps, which we run periodically. I think >> the Chromium repository should probably hold the truth. >> >> -Darin >> >> >> >> On Tue, Sep 29, 2009 at 4:46 PM, David Levin <[email protected]> wrote: >> >>> What about the override approach that I mentioned? >>> Have the dependency listed in webkit alone. If you need to roll the deps >>> before rolling webkit, add a line in the chromium deps that overrides the >>> one from webkit. >>> >>> >>> On Tue, Sep 29, 2009 at 3:00 PM, Darin Fisher <[email protected]>wrote: >>> >>>> On Tue, Sep 29, 2009 at 1:12 PM, David Levin <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> > Q: When I change src/DEPS, do I also have to change upstream >>>>>> > third_party/WebKit/WebKit/chromium/DEPS? >>>>>> > A: It depends why you update src/DEPS. Theoretically, you should >>>>>> only update >>>>>> > the upstream DEPS if the fix to the dependency actually changes the >>>>>> way >>>>>> > webkit interacts with it, or fixes a bug in the webkit layout tests. >>>>>> > However, if the change is only relevant to chromium, than webkit's >>>>>> DEPS need >>>>>> > not be updated. If that change breaks webkit, we will surely find it >>>>>> when we >>>>>> > build chromium. >>>>>> >>>>> >>>>> This seems like a mistake having out of sync rev may cause all sorts of >>>>> issues. Here's a simple one suppose there is a rev that fixes some issue >>>>> and >>>>> adds an assert and it is only done in chromium. >>>>> >>>>> Now code is changed in webkit which would trigger this assert. This >>>>> increases the pain for rolls and seems like a mistake. >>>>> >>>>> >>>> Ask anyone who was around when we had transitive deps. It royally >>>> sucked. I really do not want to go there again ;-) >>>> >>>> Once we finish the WebKit API, we'll be able to make Chromium >>>> tip-of-tree use a snapshot of WebKit. However, we might need to rev Skia >>>> independently to pick up features for the Chrome UI. We shouldn't have to >>>> branch WebKit just to update Skia. Same goes for the majority of the >>>> shared >>>> dependencies. >>>> >>>> I think it is better if we have two separate configurations. Testing >>>> WebKit in isolation just depends on some reasonable set of dependencies. >>>> Then, we'll also test Chromium+WebKit(head) using the canary bots. This >>>> will test with dependencies matching those used by Chromium+WebKit(stable). >>>> So, I think we'll get the coverage we need. >>>> >>>> Another choice is to have a shared master location for dependencies. >>>> However, both svn.webkit.org and svn.chromium.org would need to >>>> hardcode the revision of that master location, so you are back to having to >>>> rev a number in two locations. We don't want to have either repository >>>> pointing to the head of the master location since that would make it >>>> difficult to cut branches or refer to a particular revision of the >>>> repository. >>>> >>>> -Darin >>>> >>> >>> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
