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

[Staffan Gimåker]

On Sun, 2012-02-05 at 21:52 +0100, Pieter Hintjens wrote:
> On Sun, Feb 5, 2012 at 7:28 PM, Staffan Gimåker <staffan at spotify.com> wrote:
> 
> > I'd probably be more interested in contributing patches to such a repo than
> > to what the zmq master is becoming.
> 
> Would you explain the logic of that? The reason for pushing changes
> rapidly to libzmq master is to expose them to critique sooner, rather
> than later. This is where all automatic testing has its focus.

I may have been a little rash in writing that reply, let me elaborate.

But first, let me point out that I haven't been around here for very
long, so I'm not intimately familiar with what lead up to the new
governance model, nor have I had time to read all the e-mails going back
and forth about it recently.

I personally prefer any changes I (personally or as part of part of my
work) make are reviewed first, and then accepted. Why? Because once
they're reviewed and accepted they will probably stay accepted. In the
model where things are merged immediately but might end up being
reverted at much later date, we risk ending up in a situation where we
have started depending on a feature that is later deemed unacceptable,
which sort of puts us in the awkward spot of having to maintain our own
changes forever.

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.

I also have some concerns about quality and feature creep, although it's
too early to tell if those concerns are valid or not.

/S