[zeromq-dev] Contribution process, revisited

Martin Lucina mato at kotelna.sk
Tue Mar 22 23:08:06 CET 2011

ph at imatix.com said:
> On Tue, Mar 22, 2011 at 9:38 PM, Martin Lucina <mato at kotelna.sk> wrote:
> > Nice to see a formal discussion, after the changes which were made in
> > February.
> This was discussed quite heavily, on IRC and on this list. You were
> absent. That's your right, but no-one is obliged to wait for you to
> come back online.

I didn't say "wait". All I'm saying is that I would have appreciated a
friendly ping saying "we're going to do this, what do you think?". Or even
just "we've decided on this, thanks for your work until now". 

Anyhow, this is beside the point now, I just wanted it down for the record
that it feels like my work on the Git process, and the effort made on the
releases leading up to when you took over, was steamrollered without so
much as a thank-you note.

> > So, no problem with having 2.0.x. or 2.1.x. maintenance branches.
> For various reasons both Martin and I prefer to work in separate gits,
> rather than on branches in one git. You, a third person, are free to
> create your own processes but it's not really your job to try to force
> your view of process onto other people.

Fair enough.

> [...]
> > I see no such safeguards now, and I see changes such as ROUTER/XREP going
> > into 2.1 at the last minute.
> This, again, was discussed extensively here on the list and there was
> consensus. You may feel there was not sufficient discussion but I've
> been asking for fixed socket type names since June 2010. The changes
> in 2.1 are aimed at cleaning up the nomenclature now, rather than
> later, so there is less pain all around. The ROUTER/DEALER names have
> been proposed and discussed over and over, you are the only voice that
> has voted against the changes, and your reasoning seems to be "don't
> change stuff", which is unhelpful. We're making software, and change
> is necessary.

You are conveniently ignoring e.g. a rather nice email from Andrew Hume (if
I dare massage my own ego and say so myself):


So, I am not always alone.

My proposal was "can we find a way to do it right?", i.e. support all the
people who want to do custom routing, detect when peers connect and
disconnect, etc. *and* do this in a way that is inclusive within the

Your proposal is "I can do this with XREP, hence XREP must be the generic
ROUTER everyone needs". That's a pretty big claim.

> > When I discuss these with Martin Sustik personally, he tells me that XREP
> > will not be going away in 3.0, which is completely contrary to your making
> > it as deprecated in 2.1.
> Again, shrug. My recollection is agreement with Martin to rename XREP
> to ROUTER, XREQ to DEALER, and to keep those X- names for internal
> plumbing.

Yes, but that's not what the patch you submitted actually does :-)

--- a/include/zmq.h
+++ b/include/zmq.h
@@ -175,12 +175,14 @@ ZMQ_EXPORT int zmq_term (void *context);
 #define ZMQ_SUB 2
 #define ZMQ_REQ 3
 #define ZMQ_REP 4
-#define ZMQ_XREQ 5
-#define ZMQ_XREP 6
+#define ZMQ_DEALER 5
+#define ZMQ_ROUTER 6
 #define ZMQ_PULL 7
 #define ZMQ_PUSH 8
 #define ZMQ_XPUB 9
 #define ZMQ_XSUB 10
+#define ZMQ_XREQ ZMQ_DEALER        /*  Old alias, remove in 3.x               */
+#define ZMQ_XREP ZMQ_ROUTER        /*  Old alias, remove in 3.x               */
 #define ZMQ_UPSTREAM ZMQ_PULL      /*  Old alias, remove in 3.x               */
 #define ZMQ_DOWNSTREAM ZMQ_PUSH    /*  Old alias, remove in 3.x               */

You're describing ZMQ_XREP as an "old alias, remove in ...", when in fact
it's not. A request/reply forwarder device uses XREQ/XREP, not

> > Actually, I've seen review happen fairly often, most recently yesterday
> > with the HTTP proxy patches. And the reviewes we see are only those where
> > people speak out publicly.
> Indeed, the HTTP transport layer patches were reviewed. However you
> make my point - the review was of commits on github, not of code
> published to the list. My proposal is to do exactly this, send people
> to commits on github, and discuss on this list.
> > Is it really *that much work* to send the output of git-format-patch?
> As a manual process it's more error prone and slower than
> copying/pasting one URI. Martin has been sending me commit tags for
> 2.1 maintenance, and I'm fairly sure it would be annoying for him to
> switch to git format-patch output. Applying patches is also more work
> than reviewing commits online. Finally, it's harder to apply workflow
> to patches, whereas we do this for cherry-picking. E.g.
> https://github.com/zeromq/zeromq2-1/issues#issue/10. (With a patch
> would require creating a gist, then referring to that gist in the
> issue.)

Fair enough, thanks for explaining.

> > Indeed. See above.
> I'll just point out that your own ego is dominant and not always
> pleasantly for others. I vaguely recall an original proposal for
> multiple release branches that was quashed without sympathy (though
> now you are arguing for exactly that). However without egos, and the
> desire to dominate the work we do, this community would not exist, so
> let's embrace that rather than deny it.

Yes please, let's embrace it. But then we need to find a way to work
together without continuing to step on each other's toes.


More information about the zeromq-dev mailing list