[petsc-dev] Updating MOAB version during download

[Vijay S. Mahadevan]

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

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 <bsmith at mcs.anl.gov> wrote:
>
> 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.
>