On Jun 16, 2014, at 11:20 PM, Vijay S. Mahadevan <[email protected]> wrote:
>> Do it but only in the feature-dmmoab branch. Not any other PETSc branch. > > Understood and done. > >> 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 > > Well my reasoning was, eventually, when feature-dmmoab gets merged > onto PETSc/master, it would start tracking MOAB/petsc branch (wasn't > talking about right away). Yup the commit hash updates will need > manual tweaking during the merge. > >> 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. > > I actually have > > + self.gitcommit = 'petsc' # MOAB/petsc branch > > So instead should I update that to the latest hash before pushing an > update to feature-dmmoab ? No. Just track the petsc branch > > I commented out the tar file download stuff since I didn't know if we > were on consensus regarding the release tar files (equivalent to tags) > or nightly (equivalent to master HEAD). Perhaps, if we want > consistency, the tar file should provide MOAB/petsc branch HEAD ? > >> 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. > > It would be good to document this somewhere explicitly to specify how > to keep up to date with the dependencies using reconfigure. I was > originally under the impression that the updates do get pulled in if > there are newer changes upstream during reconfigure. Is there > something in the FAQ section ? > > Vijay > > On Mon, Jun 16, 2014 at 10:49 PM, Barry Smith <[email protected]> wrote: >> >> 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. >>
