On 3/27/2013 7:37 PM, Robert O'Callahan wrote:
Adding a subrepository just for Moz2D seems like it could add global
complexity for the benefit of just a small set of people. So it seems much
more worthwhile if we regard it as an experiment to blaze a trail other
modules would follow if the experiment succeeds, or be backed out if the
experiment fails (costs are found to exceed benefits). I'm still skeptical
the experiment will succeed but I'd support trying it.
We definitely have this problem in multiple places already. We include many external projects already, including NSPR, NSS, zlib, libbz2, freetype2, libevent, pymake, skia, and I'm pretty sure there are quite a few others. Some of these we import unmodified from tags; others we modify, and if we're good about it we check in the patches against named tags or revisions to make future updating easy. In at least some of these cases, we use the root client.py script to actually perform the update, e.g. `python client.py update_nspr TAGNAME`. Although reading client.py, I see that we must not be using it any more, since it still tries to pull from CVS, and NSPR has moved to mercurial!

If submodules/subrepos were proved to be a workable solution, we would definitely consider moving some or all of these imports to use them. Given the discussion I've seen so far, I think that mercurial subrepos are probably pretty satisfactory. But I think it's essential that we have a pretty good solution for git as well, and git subrepos are not nearly as good. I have personally experienced the confusion about having to run `git submodule update` at non-obvious times when hacking shumway. I expect that we'd be introducing additional developer confusion.

I haven't experienced significant problems with the current import system, and I propose that we try that for moz2d as well. It isn't currently designed to be run daily, but I don't see any particular reason it couldn't scale to daily imports, driven either manually by the moz2d developers or automatically by some continuous integration system. Are any of the original goal/problem statements left unsolved by this approach?

--BDS

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to