[zeromq-dev] C++ assertion failed with Java client

[Pieter Hintjens]

On Mon, Feb 6, 2012 at 5:15 AM, Staffan Gimåker <staffan at spotify.com> wrote:

> We want to avoid relying on features that will never make it upstream as
> much as possible, so a work flow as outlined below makes more sense to
> me personally.
>
>  * Propose a change upstream, either as an idea or a patch.
>  * Hopefully get it reviewed and accepted.
>  * Start using it internally, maintain it until it's available in an
> upstream release.
>
> If there was a "staging" repo where things got discussed and reviewed
> first, then accepted, and eventually merged to master, with any changes
> in it having a higher chance of survival, it's a work flow I'd consider.

Indeed. This makes much sense. I've previously argued for using
multiple repos for such separation but consensus was to use branches
in one repo. Thus, the master branch is a staging area, and we then
merge surviving (tested, proven) changes onto version branches.

The main problem with relying on a review process is that, by
experience, it rarely happens. We've proof of that over the last years
as Martin Sustrik has diligently sent patches to this list, yet they
are rarely reviewed. At the same time, downstreaming such "trusted"
patches to 2.1 stable has on more than one occasion created broken
releases.

And the notion that some team has the right to "accept" or "reject"
patches is bogus in an open source community. Who elects these group?
Why are they special? What if they never actually use 0MQ themselves,
how then do they judge the economics of a change? In fact the only
people who can judge the pros and cons of a feature are real users.
And they can't do this by review, they have to be able to use the
code.

My conclusion, from observing our work over years, is that only real
use can validate patches, and this will take time, often many
iterations as patches zoom in on the right solution. One cannot demand
every contributor to immediately produce perfect solutions. It creates
an insurmountable barrier. Thus, the goal of getting changes into use
rapidly, via a "this is experimental" area. And the least surprising
place is libzmq master.

I'm writing a detailed analysis and explanation of the history of our
current processes, which should allow an empirical approach to our
work. Opinions don't have much value, they are by definition biased.
We need quantitative measures that can be tracked over time. This is
what I'd like to capture.

As for feature creep, we have the tools to manage that. They are the
documented APIs and protocols. These are contracts that cannot be
broken. They may be extended but anything that people do not use can
be removed (and is, over time).