> 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. This branch will be rebased against MOAB/master when we do releases, feature additions, bug fixes etc relevant to all DMMoab functionality. This should also be the default gitcommit branch in PETSc/master. 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 ? 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 ? 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. Vijay On Mon, Jun 16, 2014 at 9:50 PM, Jed Brown <[email protected]> wrote: > Barry Smith <[email protected]> writes: >> If a pull request is made obviously the moab branch needs to be >> converted to a commit-hash for that review, then reviewers are >> looking at a stable "other package". Or one just needs to freeze >> both branches until the review is complete. > > You can't retroactively modify the petsc commits to use a moab hash. > You have to use the moab hash all along. > >> If someone is pushing new commits on the moab branch associated >> with the petsc branch they are obligated to test them against >> PETSc so if I come in later and access the PETSc branch and the >> moab branch they will work together. One could not just pick an >> arbitrary moab branch (that people may be changing willy-nilly) >> and say my PETSc branch is tracking that rather it is a moab >> branch specifically associated with the PETSc branch. For example >> petsc-feature-dmmoab could be a branch in moab that is tracked by >> the feature-dmmoab branch in PETSc. > > 1. This is special-cased for someone that simultaneously owns branches in > both projects. > > 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. > >> Note that all this is the same regardless of whether one manually >> git clone ; check checkout the moab branch or used >> --download-moab. You just seem to have it in your head that Barry >> should be doing a lot more git clone xxx himself rather than letting >> --download-xxx do it for him. > > I think you should be doing "git checkout -b barry/moab-branch" and > dealing with getting it upstream.
