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 <[email protected]> wrote: > > > On Mon, 16 Jun 2014, Barry Smith wrote: > > > >> > >> On Jun 16, 2014, at 12:13 PM, Satish Balay <[email protected]> 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 > >
