[zeromq-dev] Proposal for next stable release

Pieter Hintjens ph at imatix.com
Mon Mar 19 02:30:41 CET 2012


On Sun, Mar 18, 2012 at 7:12 PM, john skaller
<skaller at users.sourceforge.net> wrote:

> 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,

If you read C4 it says that for all changes, a ticket should exist
first. You can (I do) and it's constructive to see *all* change as bug
fixes. For stable releases, a reproducible test case is also required.
There is no reason to put test cases in the source repository; they
can be attached to issues, or placed elsewhere (e.g. 0MQ 'issues'
repo).

> 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.

For sure. But you're stating this as if C4 doesn't already cover it.
It'd be more useful to work by identifying issues in C4 so we can fix
those, rather than by restating what we already know and have been
applying to 0MQ's stable process for ages.

> Note this applies ONLY to BUGFIXes.

You're missing some key points with this.

* All change can, and IMO should, be presented as bug fixes of one
sort or another. Issue #1 in my new projects is "lack a proof of
concept".

* There is no benefit, and some real costs, to over-formalizing the
process in raw code. You do not need or want to make people publish
reproducible test cases unless you're in a stabilization phase.

> 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.

They can all clearly be framed as fixes to identified problems.

"Lack of feature X means we have to take workaround Y, which is costly"
"Internal complexity means we have to do A, B, C, which is costly"
"External complexity means learning curve is too high, which is costly"

Once you realize that all change can be profitably problem-driven you
can stop making the artificial distinction between "bugs" and
"features", and interestingly, you can ensure your code only comprises
real solutions to real problems, instead of inaccurate solutions to
assumed problems.

> None of those kinds of change are bugfixes and none are
> simply "patches to fix an identified problem".

I'll ask you to read this: http://unprotocols.org/blog:19

This is a common argument I have with engineers who are used to COD,
until they try SOD and realize that it works much better. The fact
that most people make solutions without proper agreement as to the
problems is sad but doesn't require us to follow suit.

If you can identify a single valid change to 0MQ over the last years
that was *not* a solution to a real problem, I'll change my mind.

Conversely I can list dozens of bad changes (as in, people did not
like them and eventually removed them) that were caused by not getting
consensus on the problem up front.

-Pieter



More information about the zeromq-dev mailing list