[zeromq-dev] Proposal for next stable release

[john skaller]

On 19/03/2012, at 12:30 PM, Pieter Hintjens wrote:

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

Sure.  But I added a requirement to that: provided it is feasible
a regression test must be provided and shown to fail next.

After the patch is applied it has to pass.

AND the important thing: the Maintainer is *responsible*
for ensuring this procedure is followed. No regression test,
patch will NOT be merged. Test fails after patch: the patch
WILL be reverted.

You need to read what I wrote: I'm not restating C4 as you claim,
I'm adding new procedural requirements, and rules governing
maintainers.

I observe 0MQ is seriously lacking in regression tests.
The above procedure should fix that.

My own product has hundreds of tests, yet I still fear some
things which should be tested are not. This is because I don't
follow the rule above myself :)

> You can (I do) and it's constructive to see *all* change as bug
> fixes.

I can accept that definition of Bug for the point of discussion.

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

there *is* a reason to put test cases in the repository.
They're regression tests. They're a continued assurance of quality.

Felix has hundreds of regression tests and in a packaged build
like Debian they all have to run and pass or the build is deeded 
to have failed, just as if the compiler found a syntax error.

After all it was YOU (Pieter) that actually said that you wanted to drive
contributions based on whether they work or not. Ad hoc testing
is a bad idea. Too much work, not repeatable.

Testing should be done AS PART OF EVERY BUILD.

In my view "make check" is wrong. Plain old "make" should
not just compile the program .. it should run all the tests too.


>> Note this applies ONLY to BUGFIXes.
> 
> You're missing some key points with this.

No, we just took different definitions.

So I misread your C4 to some extent because you're using a very personal
viewpoint that I can understand, but very few developers would actually
use the same terminology.

Bugtrackers typically have "Bugfix" and "feature request" categories,
for example.


> * 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 don't agree. I'm not an Extreme Programming advocate or anything,
but at this point 0MQ is seriously lacking in regression tests.

This may not have mattered with the 2 Martins and the Cathedral
development model, but with the Bazaar model it does. IMHO.

It has nothing to do with "stabilisation" phase. That's a non-existent
thing in my view, just like "all change is a bug fix". There's no stability,
just cut points in a continuous process.

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

I accept the utility of your viewpoint (just not the words you used,
but now I understand your terminology that's fine).


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

Done ..  I guess I've been using this for some time with
a twist, a kind of "if you're unsure throw it in" for a while
and then a "lets cut out all the crud".

> 
> This is a common argument I have with engineers

I'll accept your terminology if you accept my view:
I'm not a dang engineer! Anyone that does programming that isn't
an artist should be fired.

Engineering is about formulas and rules. If you use this programming
you don't know what you're doing. The whole idea of computer is
to *automate* repetition and so all good programmers are continually
creating something new. If you get to repeat something enough to be
called an engineer and don't automate it you're not smart enough:
you're fired.

:-)

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

No idea, haven't been here long enough. But I can identify a couple
of serious problems with the interfaces, and some complexity
that I don't really like.

Unfortunately, compatibility stands in the way of Simplicity.

Hard for me to make a tradeoff here because I'm an integrator,
rather than a user. A such, bad interfaces affect me a lot, but
poor implementation goes un-noticed (because I wrap it,
but I don't use it: I make it for others to use).

--
john skaller
skaller at users.sourceforge.net
http://felix-lang.org