[petsc-dev] Updating MOAB version during download

[Satish Balay]

Yes - I'm unable to think clearly because the problem is twisted with
solutions that don't make sense to me - and othrogonal issues.

So if you can restate the primariy requirement - I'll start fresh.

I'll respond to the issues reaised here [which I think are unrelated
to your primary requirement]

thanks,
Satish

On Mon, 16 Jun 2014, Barry Smith wrote:

> 
> On Jun 16, 2014, at 1:33 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> > On Mon, 16 Jun 2014, Barry Smith wrote:
> > 
> >> 
> >> On Jun 16, 2014, at 12:13 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> >> 
> >>> On Mon, 16 Jun 2014, Barry Smith wrote:
> >>> 
> >>>>>>   My feeling is that ONLY a git OR a .tar.gz should be listed at any one time and not both at the same time (the other should be commented out). 
> >>>>> 
> >>>>> The issue is - that would require all users having git installed.
> >>>> 
> >>>>  Releases would ONLY list tar balls. Branches in petsc-dev (in git) could list either a tar ball or a git repository. Hence end users do not need git. 
> >>>> 
> >>>>  This would require that when making a release branch any git based urls would need to be replaced with tar ball ones. Which we kind of need anyways.
> >>> 
> >>> Either both are equivalent [and should work with both releases and dev
> >>> snapshots] - or its too combersome - so only tarballs should be used
> >>> for both releases and dev snapshots.
> >> 
> >>   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 see why one should use git urls for dev
> >> 
> >>   Not always. Only use git urls for dev branches that are tracking some particular package feature that is being updated regularly. For most packages that are not changing regularly the url will be the tar ball for that package.
> > 
> > git vs tarball is orthogonal to 'use snapshot' vs 'track latest'. So I don't see
> > why doing the above is helpful.
> > 
> >> 
> >>> and change them to
> >>> tarball urls for release [which is error prone and fragile]
> >> 
> >>  I agree changing them manually at release is error prone. Hopefully it will only be for a very small number of packages.
> > 
> >> 
> >>> 
> >>> 
> >>>>>> I think the correct fix is for the values in moab.py (for each package) are changed over time and may be different in different branches and then at a release they are “locked” into the correct value for that release. Yes, this may mean manually setting some of the values when the release branch is made. Tough, there is no way around it.
> >>>>> 
> >>>>> This is fine by me. This is what we do with every other package. We
> >>>>> could keep updatingmoab-snapshot-xxx.tar.gz as required.
> >> 
> >>   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.
> 
> > 
> >>>>> 
> >>>>> Thei issue came with MOAB becase at some point we decided 'petsc-dev
> >>>>> should always use latest moab-dev’.
> >>>> 
> >>>>  well no. moab.py had hardwired some ancient git version of moab while the tar ball that it used was the nightly. So the git version did not match the tar ball version!
> >>>> 
> >>> 
> >>> I consider 'hardcoding' git version' a bug. It should match the url.
> >>> 
> >>> gitversion = 'HEAD' [or equivalent] would have matched moab-nightly  approximately.
> >>> 
> >>> If the match is not possible - one of them should be removed. [if git
> >>> was prefered - then the tarball wold not have been tested. Currently
> >>> tarball, git-clone have different install procedures - complexity that
> >>> I don't like - but someone insisted that we need both]
> >>> 
> >>> However there is a fundamental problem with 'petsc-dev should always
> >>> use latest moab-dev, petsc-release should use moan-release’
> >> 
> >>  On the release of PETSc petsc-release will have to point to a moab snapshot (since moab won’t be released the same time as PETSc). When moab is released then the petsc-release can now point to the moab release instead of the snapshot.
> >> 
> >>> 
> >>> For one - releases should be synced - and then there is all this extra
> >>> manual change for every release - before and after [there is already a
> >>> bit list of manual changes required during release time].
> >>> 
> >>> Secondly we have some users who freeze old petsc-dev snapshots [and
> >>> upgrade at a different schedule]. They are likely to have inconsistant
> >>> moab.
> >> 
> >>   I propose we stop making PETSc snapshots and instead people who want to work with the development version can use git. If people have machines they want to use petsc-dev on but they don’t have git on that machine that is their problem, not ours. 
> > 
> > Again an orthogonal issue. One can freeze at a commit-id with git aswell.
> > 
> >>> 
> >>> [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)
> 
>    You are not thinking properly in terms of multiple petsc branches that may be tracking branches in other packages git repositories. How do we handle that with master and next? 
> 
>    Barry
> 
> 
> >> 
> >>   We can’t. Some packages change quickly along with PETSc’s use of them changing quickly so the branch needs to track the other package. 
> > 
> > I don't understand why one needs to track 'moab-master' automatically.
> > 
> > - if moab-latest has interface changes - then tracking moab-master
> > automatically would result in broken petsc state.
> > 
> >> 
> >>   Now this gets complicated but when a branch is merged to next or master the git url could automatically get frozen to what it pointed to when the merge was made.  This way master (and next) are not broken when someone changes the API of the other package (Jed can easily write code to do this!).
> > 
> > And I think we don't need this complexity.
> > 
> > Perhaps we should rephrase the problem - so that a simpler procedure
> > can we worked out..
> > 
> > Satish
> 
>