[petsc-dev] Updating MOAB version during download

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:
>> The commit hash, which is exactly what we have now.
>
>   1) It is a manual beasty that someone has to edit moab.py and change
>   on a regular basis? This doesn’t work as proved by the current
>   fiasco.

One instance of misunderstanding the model is not an indictment that the
model is broken.

>   2) It does not give me access to the branch so that I can make
>   changes. Say I am working on feature-dmmoab in PETSc and see a
>   little bug in the moab branch that (indirectly only since I am at
>   some stupid headless commit-hash instead on a branch) I am pointing
>   to, that if I quickly fix I can push and make life easier for my
>   entire team of eight developers. I need to manual figure out what
>   branch corresponds to the commit-hash thing I had checked out,
>   change to that branch in moab, fix the branch in moab, push it and
>   then comeback and edit moab.py in PETSc to point to the new
>   commit-hash beasty of the moab branch.

If you find a bug, you have to fix it within the workflow of THAT
project.  If they use a workflow similar to PETSc, then a good option
would be to start a new branch from that critical commit and ask for it
to be merged.

>     So somehow I would like the moab.py to “know” about the associated
>     moab branch (if there is one) as well as a commit-hash. Now when I
>     checkout the PETSc feature-dmmoab I want the branch checked out
>     (at a particular commit-hash? Is that possible?) Now if I update
>     the moab branch with a new commit then when I commit my
>     feature-dmmoab I want it to automatically update the “commit-hash”
>     in the moab.py

--download-package is a feature for USING a third-party package, not a
framework for CONTRIBUTING to that project.

>    Manually expecting people to switch from a commit-hash to its
>    corresponding branch in the moab repository and to ALWAYS put the
>    right thingy in the moab.py is totally fucking unrealistic. It is
>    not a practical workflow.

External packages need their own test suites.  A bug discovered via
PETSc needs to make it upstream via a test case and fix.  When that is
released (perhaps a "micro-release" of a specific commit hash), PETSc
can use it.  PETSc should not be so intimately coupled to these external
projects that the commit/test/integration workflow is interwoven.

>    You might think this is all academic nonsense and not to worry
>    about it but say I am doing a project that involves 3 repositories
>    PETSc, moab, and saws and have a branch in each that coordinates
>    with a branch in each of the others (and I am changing code in all
>    three of them) and I am doing this with a team of five
>    people. Expecting all five people to always do the right thing in
>    coordination without automated help is impossible. So where does
>    the help come from, some git feature, some other tool????

Facebook has (or wants) one huge repository into which thousands of
people work on disparate things.  Then anyone can refactor anything and
everyone gets the result atomically.  But everyone also gets the bugs
and interface changes.  I think that workflow encourages undesirably
tight coupling.

For you, what is wrong with updating gitcommit when you change an
interface in MOAB?  If other people are also developing MOAB, they
should have their own clone and "git pull" each time, not use
--download-moab.
-------------- 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/20140616/de1bd9da/attachment.sig>