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