Yeah, good point... this could be a good task for gardeners. Perhaps we could have a tool help us here.-Darin
On Tue, Sep 29, 2009 at 10:26 PM, Dmitry Titov <[email protected]> wrote: > It seems that if the deps were the same though, the rolls would be on > average less breaking because at least it would test WebKit on WebKit bots > with same versions of V8, Skia etc as post-roll. So single DEPS could make > gardening simpler but other changes (like update Skia for UI) harder. I see > the point. Yeah, it is optional for gardener to roll WebKit DEPS, although > someone will have to do this periodically so why not? > > > > On Tue, Sep 29, 2009 at 9:08 PM, Darin Fisher <[email protected]> wrote: > >> 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 -~----------~----~----~----~------~----~------~--~---
