"Vijay S. Mahadevan" <[email protected]> writes: >> 2. It assumes that there will be sufficient communication among other >> MOAB developers so that they know the branch has hidden connections with >> a different project and thus must be treated specially. > > I created a "petsc" branch in MOAB from the current master and can > update moab.py to track this by default.
No, this model is broken because you cannot reproduce states. > This branch will be rebased against MOAB/master when we do releases, Even worse, now you're going to change those commits in your branch. > feature additions, bug fixes etc relevant to all DMMoab > functionality. This should also be the default gitcommit branch in > PETSc/master. No, PETSc 'master' needs to always work regardless of what is happening in MOAB. > If the API is broken due to upstream changes, appropriate changes will > be made in PETSc feature branches (linked with MOAB/petsc branch) to > keep it up to date. Then anyone working on both these projects on > different feature branches can update appropriate branches in each > repo and get them matured together to get them into PETSc/master and > MOAB/petsc. Is this a reasonable workflow ? Terrible. > There is the however a conditional here that MOAB/petsc branch needs > to be guaranteed to be stable. This should be possible with the > requirement that anyone rebasing this branch against master needs to > confirm that all MOAB and PETSc DMMoab tests pass before updating the > remote. Do we still then need a commit hash in moab.py ? Requirements outside of your repository is an extremely fragile model. You need a complete test suite in moab.git and you can make releases (can just be a certified commit) that PETSc is (eventually) updated to depend on. > Also is there a way to instruct PETSc users to reconfigure when there > are upstream changes (thereby pulling the latest commit in MOAB/petsc > branch, reconfiguring, recompiling etc) as a default way to develop on > the interface to both the packages in general ? If not, their repo in > arch/externalpackages configured with --download-moab could become > stale. Initiating git fetch and git pull on the petsc branch should > accomplish this but I'm not sure if that's how you would want to go > about it in the BuildSystem. This is not implemented yet. Some people think --download is a simple mechanism for getting things installed and other people want it to be a comprehensive deduplicating, installing, and upgrading package manager.
pgp89s2QfVsGg.pgp
Description: PGP signature
