[petsc-dev] Updating MOAB version during download

[Vijay S. Mahadevan]

> 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 <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.