On 19/03/2012, at 7:24 AM, Pieter Hintjens wrote: > I've finished C4, which aims to turn our ZeroMQ collaboration process > into something reusable by others. > > Would you take a look and critique it? http://rfc.zeromq.org/spec:16
I have some problem with the "pointed change" policy. First: the process for a BUGFIX should be: 1. Document the problem with a bug tracker ticket. 2. Submit a change which consists of either: (a) A test case which is added to the regression test suite OR (b) A note which is added to the "to hard to figure out a test" regression test suite. This is because it isn't always possible or sane to create a simple test case. 3. The maintainer must merge in this test case FIRST, and ensure by compilation and testing that indeed the test case if provided by (a) actually fails. 4. On merge of a bugfix, the maintainer SHALL ensure that the code compiles and the regression tests actually pass. If not, the patch SHALL BE reverted. [Note: this means all the previously passing tests pass AND the new regression test also now passes BUT it does not require failing tests to pass, these WILL exist because of concurrent bugfixes] The description of the bugfix in the patch must refer in a specified way to the regression test it fixes AND the bugfix ticket on the bugtracker. 5. In the event (b) notification is used, the Maintainer instead shall open up discussion and make a considered decision based on it whether or not to (i) accept the note and, if so, finally, to retain the patch purporting to fix the bug. ====== The purpose of the above is to improve quality control. The maintainer no longer simply automatically merges in a patch. For a bugfix, the ticket must exist first, the regression test or a note "in lieu" must exist next, and the patch finally applied must actually fix the problem as demonstrated by the state of the submitted regression test changing from fail to pass. Where there's no actual test code a note "in lieu" is used and community discussion used to advise the maintainer instead. Note that this is Quality Control. It is NOT about whether people like or dislike the change, simply an assurance that there is a bug, and it is fixed, either by a simple proof by way of actual code, or, at least a discussion if that isn't feasible. The discussion must centre around whether the *description* of the bug is comprehensible and whether, with a suitable test case the current code base WOULD fail. Similarly, the community examines the actual patch to see if they believe it WOULD fix the problem. Note this applies ONLY to BUGFIXes. I have serious concerns this approach to change will lead to product stagnation. I don't have a problem with fixing bugs, but a lot of important kinds of change are left out of the process. Advances are left out. Refactoring is left out. Simplifications are left out. None of those kinds of change are bugfixes and none are simply "patches to fix an identified problem". -- john skaller [email protected] http://felix-lang.org _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
