[petsc-dev] Updating MOAB version during download

[Barry Smith]

On Jun 16, 2014, at 2:20 PM, Satish Balay <balay at mcs.anl.gov> wrote:

> On Mon, 16 Jun 2014, Barry Smith wrote:
> 
> 
> 
> for such rapid changes - I don't think Vijay is reying on 'petsc
> configure' manage this petsc+moab sync.  I'm sure he is fixing things
> in both repos as required - and commiting things manually [in
> appropriate branches].
> 
> And if someone else is in sync with Vijay in this incremental work - I
> think the normal thing is for the two [or group] to co-ordinate.


   No, no no and no!!!! 

   When Vijay, or some one else doing something else says; hey Barry please take a look at my branch xyz and build it and test and add features a, b, c,  ALL THEY SHOULD NEED TO TELL ME IS branch xyz, I check it out and start building. If they need to tell me also get branch wyx of moab and branch abc of XYZ then we are NOT using tools efficiently (let’s just email the files back and forth). Each branch should have all the information needed to build for that branch, this simply means each branch has IN the appropriate xxxx.py package file the correct information about what other packages versions to use. This is actually easy except for 

   merging to next and master where you may not want to drag along exactly the repository branch info that was used with the branch. (this relates to Vijay’s question).

   The tools manage the coordination, people don’t mange coordination with notes on scraps of paper and rumors in the hallway about what commit of moab they should use with what branch of petsc.

   Jed has pointed out that a “branch” is not enough information, so what should we use in the xxx.py so that the correct thing is built when I build PETSc with a particular branch??? 

   Barry

> 
> I don't belive petsc configure should be in the business of automating
> this workflow.
> 
> [the usual workflow - similar to prior buildystem is]
> 
> <example 1>
> cd petsc
> git checkout moab-branch
> git pull
> cd PETSC_ARCH/externalpackages/moab
> git checkout new-petsc-interface-branch-code
> git pull
> cd -
> ./configure --download-moab
> 
> However once its in a useable state by petsc users - a consistant
> git-url and/or tarball-url should be added to the petsc 'moab-branch'
> - and eventually merged to next/master.
> 
> 
>>>>> [so I think its best to avoid listing moab-nightly as a default in
>>>>> petsc-dev branches]
>> 
>>   It is not the “default”, it would be in certain branches, the issue comes up when those certain branches are merged into master. Then does master somehow lock onto the current commit of moab so that further changes don’t break master. (Meanwhile other petsc branches may be tracking the further moab changes)
> 
> This is fine. One can use wathever url desired in this feature-branch
> - but one would make sure only the 'release/snapshot' git/tarball urls
> get into next/master. [and make sure other feature-branches don't
> merge this moab-freature branch]
> 
> <One way to do this is:>
> 
>   loop:
>        <work on moab-feature-branch>
>        change moab-url to latest git/tarball url
>        < update petsc/moab in corresponding feature branches>
>        < update petsc/moab in corresponding feature branches>
>        *create moab snapshot - and fix urls *
>        *merge to next/master*
>        [does one freeze development between merge to next and merge to master?]
> 
> <Alternative>
>    loop:
>        <work on moab-feature-branch>
>        <git pull on  moab>
>        < update petsc/moab in corresponding feature branches>
>        < update petsc/moab in corresponding feature branches>
>        *create moab snapshot - and fix urls *
>        *merge to next/master*
> 
> 
> Satish