On 28/01/2012, at 1:45 PM, Martin Lucina wrote: > [email protected] 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 [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
