[zeromq-dev] Proposal for next stable release

[john skaller]

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
skaller at users.sourceforge.net
http://felix-lang.org