On Jun 16, 2014, at 10:36 PM, Vijay S. Mahadevan <[email protected]> wrote:
>> 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. Do it but only in the feature-dmmoab branch. Not any other PETSc branch. > 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. No it cannot be the gitcommit on PETSc/master! Because PETSc/master may lag behind feature-dmmoab branch and thus may not work with the latest Moab. When I merge feature-dmmmoab into next and master I need to manually set the commit hash in moab.py for those branches to the current petsc branch head. (The manual part I can easily forget that I want to automate but Jed wants me to have perfect memory). > > 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 ? Jed wants the commit hash because otherwise you cannot map each PETSc commit to a single moab commit. Don’t worry about this until we figure out how we are going to handle things on the PETSc side. > > 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. Currently Buildsystem does not handle updates in the external packages. The current model is to do rm -rf $PETSC_ARCH and then reconfigure and have all updated packages built. This isn’t something you can fix but is instead PETSc/Buildsystem will need to resolve someday. Let me know when to pull the latest feature-dmmoab, test it and merge it into next. Barry > > 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.
