[petsc-dev] Updating MOAB version during download

[Barry Smith]

On Jun 16, 2014, at 11:20 PM, Vijay S. Mahadevan <vijay.m at gmail.com> 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 <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.
>>