[petsc-dev] Updating MOAB version during download

[Satish Balay]

On Mon, 16 Jun 2014, Barry Smith wrote:

> >>   I think we should stop making dev snapshots, see below.
> > 
> > I don't see why this unrelated thing is pulled in here..
> 
>    It is directly related to the issue of whether snapshots can use git to download some packages instead of always tar balls. If there is no snapshot then the issue of making sure snapshots download only tar balls is gone.

I don't understand why 'making sure snapshots download only tar balls' is required - and
why a fix here is needed - and how removing petsc-dev.tar.gz helps [helps more than it hurts]..



> >>   We can’t do this. This would mean making a new moab-snapshot-xxx.tar.gz  every few hours.
> > 
> > Why every few hours?
> 
>    Because some one is making changes to moab branch and to petsc (using that rapidly changing moab branch) and they want to share what they do with other people. For example what Vijay is doing right now.


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.

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