On 9/1/2010 9:04 AM, Sim IJskes - QCG wrote:
On 09/01/2010 05:05 PM, Jonathan Costers wrote:
OK, looks like we have agreement.
I'll try to at least initiate my proposal later today.
Thanks
Jonathan
Can we add that we vote before merging, after a peer review, and provide
a quick path for securityfixes on the trunk?
I'm not sure that the quick path criterion should be
security/not-security. Some of Peter's security work seems to me to be
complicated enough that it should go through a peer review before
merging. On the other hand, as Jonathan has suggested in another e-mail,
a separate branch may be overkill for a very simple change. A fix may be
urgent for other reasons than security.
I do think that anything non-trivial should go through peer review
before merge into the trunk, for several reasons:
A reviewer may see a flaw, or ask a question that makes the programmer
see a flaw.
It is very desirable to have at least two people understand every recent
change, for backup.
Peer review automatically provides a check on code readability.
Reviewers can check that the test suite has been upgraded if necessary.
The new code may have flows that are not adequately covered by existing
tests.
Patricia
