Sounds like a good idea.-Darin On Tue, Sep 29, 2009 at 10:53 PM, David Levin <[email protected]> wrote:
> On Tue, Sep 29, 2009 at 10:41 PM, Darin Fisher <[email protected]> wrote: > >> Yeah, good point... this could be a good task for gardeners. Perhaps we >> could have a tool help us here. > > > Maybe there could be a test run on the canary that checks the DEPS to see > if they have the same versions, and if they aren't, it turns "orange" to > indicate some action should be taken. > > > >> -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 -~----------~----~----~----~------~----~------~--~---
