[petsc-dev] moab nightlybuild failure
Barry Smith
bsmith at mcs.anl.gov
Fri Jun 28 18:17:55 CDT 2013
Jed,
Fine. So
1) moab.py gitcommit will always point to moab master HEAD or older version of moab master
2) MOAB/PETSc developers who are synchronously changing code in PETSc and MOAB will manually manage appropriate branches in each. They will not touch gitcommit in moab.py!
3) MOAB/PETSc developers who are synchronously changing code in PETSc and MOAB will always merge the moab branch they've developed into moab master before or at the same time they merge the petsc branch into petsc master (updating the moab.py gitcommit at the time of updating the petsc master from the petsc branch).
I think this clarifies things.
Barry
What got me confused is thinking Jed saw a bigger role for gitcommit then it really has; which is ONLY to synchronize petsc master with moab master.
On Jun 28, 2013, at 6:06 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> Barry Smith <bsmith at mcs.anl.gov> writes:
>
>> Not at all! It is EXACTLY the workflow we expect to see as PETSc
>> and MOAB become best buds. Someone branches off of PETSc master and
>> moab master and make related changes to __both__ of those branches
>> over time (likely a small team of people is working on these
>> branches or branches of these branches). For example making another
>> PETSc hook into moab that requires some additions to the moab base
>> code as well as additional PETSc code*. When they are all done the
>> two branches are eventually (and at the same time) merged into
>> PETSc master and moab master for everyone to benefit from.
>
> I think that if we ever have "PETSc example as a test suite
> for a new feature in MOAB", it will be temporary and not necessary to
> automate.
>
>> Now I originally proposed doing this by simply requiring these
>> people (who are presumably somewhat competent) to simply manually
>> make sure the branches in the two packages match up appropriately
>> (with perhaps a naming convention) as they do other stuff and
>> checkout other branches then go back to work on their combined
>> PETSc moab project they manually make sure the appropriate branch
>> is set for each package.
>
> I think this is reasonable, and I think the PETSc branch should not
> merge to 'master' until the corresponding branch in MOAB has merged to
> master, so that we can point moab.py's gitcommit at it.
>
>> Jed implied that the manual matches of branches I proposed could be
>> handled somewhat automatically (mumbling about gitcommit; I didn't
>> understand what you proposed). My response is that __IF__ it can be
>> handled somewhat automatically then it should be handled properly
>> automatically; hence I asked if it could be handled completely
>> generally automatically (checking out matching partners
>> automatically) and your response was it is nebulous, complicated and
>> unnecessary.
>
> I think automating it is too hard, not because of the data model or
> interface, but because making the decision about what is correct
> behavior is so subjective and involves non-local information.
More information about the petsc-dev
mailing list