[petsc-dev] [petsc-users] MatMPIBAIJSetPreallocationCSR i and j indices

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>> On the Reported-by tags, could you do them in a structured way as
>> 
>> Reported-by: Matteo Parsani <parsani.matteo at gmail.com>
>> Reported-by: Lisandro Dalcin <dalcinl at gmail.com>
>
>    This is fine, but there needs to be a mechanism to ensure this,

We already have whitespace conventions, a convention that there are no
memory leaks, a convention that type-specialized functions use dynamic
composition, a convention that we do not create dependency loops, a
function naming convention, a convention about avoiding globals, a
branch usage convention, etc.  None of these are enforced and only some
have automated checking.

>    imposing requirements on developers that do not have enforcement
>    mechanisms (besides being yelled at later) don't work. 

Patch review is more flexible than any automated tool can be.  It is
only time to write an automated tool when the effort to do so, and the
attainable accuracy, is a better use of human time than had the same
time been devoted to patch review.  Note that patch review can catch
many things, but automated tools can only catch that which has been
automated.

>    Note that this is the same kind of situation as me accidentally
>    editing directly into maint.  I did
>
> git branch barry/fix-matmpibaijsetpreallocationcsr

This creates a branch without checking it out.  If you want to create
the branch _and_ check it out, use

$ git checkout -b barry/fix-matmpibaijsetpreallocationcsr

> happily edited away and tested
> git commit -a 
> git push
>
> Now what should have happened is as soon as I tried to happily edit
> away, something should come back and said to me: "are you sure you
> want to edit in maint?" 

This is policy on the branch rather than the fact that you created a new
branch prior to starting this work.  (I do that sometimes so that I'll
be able to easily compare to the old state later.)  We could perhaps
prevent direct commits on 'maint'.

> And don't go and mail me some elisp that I can stick in somewhere to
> warn me about the maint editing business; that would only solve the
> problem for me, not for the n-1 other people in the world who make the
> same mistake. Git needs some way of "baking in" a set of standards
> (optional obviously) that it does its best to enforce and not leaving
> it up to each user to remember 324 things they need to constantly be
> checking depending on what project they are working on.

There is a security problem with making normal commands behave
differently when run inside some repository that you just cloned.  Any
such policy would need to be opt-in.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130929/91d67201/attachment.sig>