[zeromq-dev] Contribution policy and quality of commits

[john skaller]

On 28/01/2012, at 1:45 PM, Martin Lucina wrote:

> cremes.devlist at mac.com said:
>> What specific suggestions do you have for improving the process?
>> (Demanding that all patches be rigorously inspected and tested by the
>> maintainers is not a reasonable, though specific, suggestion.)
> 
> Code review is in fact specifically what I am asking for. Every major FOSS
> project has a code review policy:


I believe there is a point to the policy. I am guessing the idea is this:
with the patches merged in "more or less mechanically" people are actually
in a position to try them out and review them in context.

Do not ask me to manually merge any patches posted
on the mailing list .. I wouldn't have the faintest idea how to do it, or to
undo it, especially if I were patching my own clone I'm working on.

Now, if the patch fails, it can be reverted or backed out.
This may be a bit tricky. But on the assumption a reasonable 
majority of patches are OK, it is still probably more efficient.

On Felix project everyone who shows some capability and interest
gets to write to the master repo. I don't want to mess around doing
pull requests .. an even more extreme policy. This way if there's
a bug or whatever I can just fix it. Not suggesting that here,
but the point is probably the same: work on the basis of
trust and minimal authoritarian management of contributions.

I think the real problem here is how to identify what has changed
after the commit so it can be inspected (without messing about
online with GitHub).

Perhaps we could ask people to "sign" their patches in a rigid style,
eg:

// JMS: 12/01/2011
my-patch here ...

Wikipedia does that (with ~~~ or so).

After a while, fully accepted patches could have the signature stripped out
to make the code look clean again.

--
john skaller
skaller at users.sourceforge.net