[petsc-dev] 'master' RESET after bad merge! - 'tisaac/thplex' was based on 'next'

[Jed Brown]

Matthew Knepley <knepley at gmail.com> writes:

> On Wed, Sep 3, 2014 at 2:30 PM, Jed Brown <jed at jedbrown.org> wrote:
>
>> Matthew Knepley <knepley at gmail.com> writes:
>> > The concrete proposal has been made many times. Here it is again: Do not
>> > let anyone merge next into master.
>>
>> Which 'next'?  What about parents of 'next' or abandoned branches?  Do
>> we care about the local 'next' or the 'next' associated with a remote?
>> Which remote?  Recall that in this case, it wasn't "git merge next", but
>> someone starting a branch in a different repository that contains
>> commits not present in 'master'.  Define what you mean there.  What if
>> someone starts that branch and rebases onto 'master' (rewriting commits
>> From 'next' so that they are not longer in the history of 'next')?
>>
>> But "don't merge 'next' into 'master'" is laughably short of the scope
>> of what you are really asking for.  If you want to make a serious
>> proposal, do that.
>
>
> Pretending not to see a problem will not make it magically go away.

You didn't make a serious proposal.

>> > Babbling about how easy errors are to avoid is senseless, and
>> > completely blind to all the neurological research.  People make simple
>> > mistakes all the time in every endeavor.
>>
>> Add "review the commits in branch" to your merge checklist.
>>
>
> Of course, and a manual checklist is obviously better than automating
> the check.  Lets get rid of all pointer checks in PETSc. 

This is a red herring because "this argument must not be NULL" is a
precise and enforceable statement.

"Don't merge commits that are undesirable in the target branch" is not a
statement that a machine can interpret.  If you can make it precise, you
can retire now because your strong AI has just automated software
maintainership.

I have outlined ways to guard against very specific kinds of commits
that are undesirable in the target branch, but the solutions are not
perfect and have tradeoffs.  The bottom line is that you still have to
review branches before merging; that requirement will not go away until
you have strong AI.

My personal opinion is that maintaining a catalog of undesirable commits
and detection/enforcement logic is not the best use of maintainer time
and will not result in a more efficient system.  But if you want to
spend your time on it, give it a shot and maybe others will use it too.
-------------- 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/20140903/264bbfee/attachment.sig>