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
