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

Pieter Hintjens ph at imatix.com
Wed Feb 16 16:02:38 CET 2011

On Wed, Feb 16, 2011 at 3:29 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> That's not going to fly IMO.
> Given that the latter requires half the work and that developers are (in
> general) lazy, I would expect everyone take that path, making stable branch
> little more than a simple tag on the master.
> In short, unless there's a maintainer actually willing to actively backport
> patches from the master (and so far I haven't seen anyone volunteering to do
> that) the whole discussion about stable is kind of pointless.

It seems the choice is between (a) one person who knows the code well
enough to take any patch, check it, modify it, apply it, and fully
test it, and back/forward port if needed, or (b) one group of people
who can do this for their own patches and a further group of people
(overlapping, for sure, but with different hats on) who administrate
the process of applying patches to branches, or (c) just ignore the
need for patched releases and tell users they won't get them.

One thing is for sure, if we rely on individuals to do too much, they
will burn out, they will become bottlenecks, and their work won't
scale. So this is not only about stable releases, it's also about
finding ways to separate the different types of work we do

Honestly, when I make a patch, I'm *not* lazy, and I'd be more than
happy to explicitly work, test, and send a pull request against the 2
or (max.) 3 gits or branches it might take, especially if it results
in new packages I can give my own clients, rapidly and predictably.

Remember it's not just about people using 0MQ for their own fun. It's
about people and businesses building deliverables that depend on 0MQ,
finding problems in 0MQ, and needing a reliable process for turning
patches for those problems into deliverable 0MQ packages.

Today a team needs to make their own unofficial releases to get this.
That's really neither efficient (why can't they invest that same
effort into an official release everyone benefits from), nor
sustainable (clients get angsty when they get weird 'unofficial' tar
files, as they should).

The discussion about stable is necessary unless you reject the
problems I started by listing.

Do you have alternative proposals?  Just saying "it won't work" isn't
terribly helpful.


More information about the zeromq-dev mailing list