[petsc-dev] Updating MOAB version during download

[Barry Smith]

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 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.

> 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.

>>> 
>>> 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. 

> 
> [so I think its best to avoid listing moab-nightly as a default in
> petsc-dev branches]

   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. 

   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!).


  Barry


> 
> Satish