[petsc-dev] Updating MOAB version during download

[Jed Brown]

"Vijay S. Mahadevan" <vijay.m at gmail.com> writes:

>> 2. It assumes that there will be sufficient communication among other
>> MOAB developers so that they know the branch has hidden connections with
>> a different project and thus must be treated specially.
>
> I created a "petsc" branch in MOAB from the current master and can
> update moab.py to track this by default. 

No, this model is broken because you cannot reproduce states.

> This branch will be rebased against MOAB/master when we do releases,

Even worse, now you're going to change those commits in your branch.

> feature additions, bug fixes etc relevant to all DMMoab
> functionality. This should also be the default gitcommit branch in
> PETSc/master.

No, PETSc 'master' needs to always work regardless of what is happening
in MOAB.

> If the API is broken due to upstream changes, appropriate changes will
> be made in PETSc feature branches (linked with MOAB/petsc branch) to
> keep it up to date. Then anyone working on both these projects on
> different feature branches can update appropriate branches in each
> repo and get them matured together to get them into PETSc/master and
> MOAB/petsc. Is this a reasonable workflow ?

Terrible.

> There is the however a conditional here that MOAB/petsc branch needs
> to be guaranteed to be stable. This should be possible with the
> requirement that anyone rebasing this branch against master needs to
> confirm that all MOAB and PETSc DMMoab tests pass before updating the
> remote. Do we still then need a commit hash in moab.py ?

Requirements outside of your repository is an extremely fragile model.
You need a complete test suite in moab.git and you can make releases
(can just be a certified commit) that PETSc is (eventually) updated to
depend on.

> Also is there a way to instruct PETSc users to reconfigure when there
> are upstream changes (thereby pulling the latest commit in MOAB/petsc
> branch, reconfiguring, recompiling etc) as a default way to develop on
> the interface to both the packages in general ? If not, their repo in
> arch/externalpackages configured with --download-moab could become
> stale. Initiating git fetch and git pull on the petsc branch should
> accomplish this but I'm not sure if that's how you would want to go
> about it in the BuildSystem.

This is not implemented yet.  Some people think --download is a simple
mechanism for getting things installed and other people want it to be a
comprehensive deduplicating, installing, and upgrading package manager.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140617/aa9bd291/attachment.sig>