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

[AJ Lewis]

On Mon, Feb 06, 2012 at 05:08:22PM -0600, Pieter Hintjens wrote:
> 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.

Ok, this is what I was missing.

> 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 think this makes sense too.  "Check in early, check in often."   

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

Great! Looking forward to reading it.

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

Yeah - it seems like we definitely need some more tests to verify these
are maintained.  I guess as long as the binding authors are using the
master branch (at least occasionally), there should be early warnings if
things are broken.

Thanks for the explanation - this makes much more sense to me now.
-- 
AJ Lewis
Software Engineer
Quantum Corporation

Mobile:  612 860-8068
Work:    651 688-4346
YahooIM: vortechs2000
AIM:     v0r73chz
MSN:     vortechs2000 at yahoo.com
email:   aj.lewis at quantum.com

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.