[petsc-dev] Updating MOAB version during download

[Barry Smith]

On Jun 16, 2014, at 10:36 PM, Vijay S. Mahadevan <vijay.m at gmail.com> 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 <jed at jedbrown.org> wrote:
>> Barry Smith <bsmith at mcs.anl.gov> 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.