SGTM. I'll write the check. On Tue, Sep 29, 2009 at 11:12 PM, Darin Fisher <[email protected]> wrote:
> 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.orgwould >>>>>>>>> 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 -~----------~----~----~----~------~----~------~--~---
