[zeromq-dev] Discuss: 0MQ releases and stability

Pieter Hintjens ph at imatix.com
Wed Feb 16 09:28:03 CET 2011

On Wed, Feb 16, 2011 at 4:57 AM, Brian Granger <ellisonbg at gmail.com> wrote:

> Because of the scale of zeromq development, I would recommend that all
> new development go on in topic branches.

There's a real conflict of interest here. Code stays on topic branches
until it's 'ready' but without being tried by fairly large numbers of
people it takes a long time to become ready. I'd rather see people who
aren't ready for some instability to use releases, and those who use
master getting new (even raw) functionality literally as soon as it
builds. The onus then is on new code not breaking old code.

>> 4. Use github pull requests instead of email patches
> I highly recommend going to this workflow (github pull requests).  We
> are using this for a number of other projects (including pyzmq) and it
> has really helped.  The only thing that is lacking is a way of
> assigning a pull request to someone that can be in charge of reviewing
> it and making sure it gets merged into the appropriate branches.

Github's tools are poor and this could easily make it impossible to
scale. Imagine three different groups of committers trying to share
one set of issues and pull requests on the main git. It's going to

So... a refined proposal. Instead of using branches in one git, how
about separate gits, clearly named per minor release? So we can start
on a http://github.com/zeromq/zeromq2.1 repository, with its own
issues and pull requests. No stepping on each others' toes, and
entirely safe for each group of committers to manage as they please.
E.g. using maint branches if wanted or releasing from master if

I think that better suits github, and our own organization as a community.


More information about the zeromq-dev mailing list