On Jun 16, 2014, at 8:45 PM, Jed Brown <[email protected]> wrote:
> Barry Smith <[email protected]> writes:
>> The only tricky time is when zzz gets merged into PETSc master or
>> next. At that time presumably we want the merged moab.py to point to
>> the commit-hash of the xxx branch in moab. Can this be automated, of
>> course because anything can: if yyyy.py package points to a branch
>> when merged into next or master (or any branch) the branch gets
>> switched to the commit-hash of the head of the branch? Now translate
>> to git language.
>
> This is funky logic and there isn't a nice place to put it in the
> workflow, but I'm more worried about the semantic problem: we can't
> test/review the petsc commits because there could be new commits in the
> moab branch that break the petsc commits.
If a pull request is made obviously the moab branch needs to be converted to
a commit-hash for that review, then reviewers are looking at a stable “other
package”. Or one just needs to freeze both branches until the review is
complete.
If someone is pushing new commits on the moab branch associated with the
petsc branch they are obligated to test them against PETSc so if I come in
later and access the PETSc branch and the moab branch they will work together.
One could not just pick an arbitrary moab branch (that people may be changing
willy-nilly) and say my PETSc branch is tracking that rather it is a moab
branch specifically associated with the PETSc branch. For example
petsc-feature-dmmoab could be a branch in moab that is tracked by the
feature-dmmoab branch in PETSc.
> And we have no way to know
> while reviewing that something in moab has changed. This is a fragile
> mess for reviewers.
Agreed, and we won’t be in that situation.
Note that all this is the same regardless of whether one manually git clone ;
check checkout the moab branch or used —download-moab. You just seem to have it
in your head that Barry should be doing a lot more git clone xxx himself rather
than letting —download-xxx do it for him.
Barry
