I'm not a developer so it's perfectly normal that I can't understand anything about your talk; nevertheless, please, remember of KISS principle when building any installing tools for poor, final users. I'm waiting for something like "pip install core".
Alex 2014-06-11 15:58 GMT+02:00 C. Scott Ananian <[email protected]>: > I will mention that any solution short of sucking in the third party > dependencies into the main repo (not as a submodule) -- which no one > wants to do anyway -- will be slightly awkward to git bisect. Not > impossible; the pain is about the same for both main options: > > a) in theory git-bisect should adjust submodules to the correct hash. > in practice you need to run `git submodule update` after every step in > order to check out the appropriate submodule commits. > > b) similarly, for composer you need to run a command to update the 3rd > party packages, if any dependencies have changed. (for node.js > projects, which have similar issues, you need to run `npm install` > after every step. > > For regressions that are easily found by running a test suite, you can > arrange for `git bisect run` to do the appropriate git, composer, or > npm command before running the test. > > So, it's somewhat awkward, but manageable. And usually the 3rd-party > dependencies don't typically change as often as the core code, so this > doesn't come up all that often. > > Two main benefits of `git submodule`: (1) perhaps one day `git bisect` > and `git submodule` will play nicer together; (2) since references are > to a git hash, crawling through history is repeatable. One > disadvantages: (1) because git allows `.gitmodules` to differ from > your local set of module repo sources (in `.git/config`), it is rather > too easy to forget to push a submodule commit referenced from the main > repo -- although hopefully jenkins will catch errors of this sort, > > The main disadvantage of using `composer`/`npm`/etc directly is that > you are at the mercy of the upstream package repo to behave well. > That is, if the upstream repo allows uploaders to change the tarball > associated with version X.Y.Z, you may find it hard to reproduce past > configurations. Similarly, if you specify loose package version > constraints, you are at the mercy of the upstream maintainers to > actually maintain compatibility between minor versions or > what-have-you. > > Parsoid and some other WMF projects actually use a hybrid approach > where we use `npm` and not submodules, but we maintain a separate > "deploy" repo which combines the main code base (as a submodule) and > specific versions of the third party code. > --scott > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
