St. Valentine's Day Massacre

This page is to get feedback on a thread we had on IRC on St Valentine's Day. I'll start by noting a number of problems we face today using/packaging 0MQ, and then propose some solutions.

Problems:

1. It is rather hard to know what version of 0MQ to use:

The stable release is too out of date, has numerous flaws that have been properly fixed in later versions.
The development (beta) release, which fixes the major flaws, has no bug fixes since it was released, and many production users will not use a beta version out of policy.
The masterHEAD has no formality, and can't be used by teams that need a formal (fixed) release for their own downstream customers.

2. New code (like the new xsub/xpub sockets) is not tested in a timely fashion:

They are on long-lasting topic branches that few people know about or work with.
We have an unresolved conflict between stability and progress on the master.

3. It is not possible to make a sane stable release from the 2.1.x codebase:

New, untested code goes into this codebase almost daily.
Old, stable code is not separated from new code in any way.

4. There is no workflow for patches:

If a committer doesn't process a [PATCH] email immediately, it can & does get lost.
There is no way to manage one patch applied to more than one branch.

Proposals:

1. Merge topic branches aggressively into master, or stop using them altogether.
2. Rename the maintenance branch to match the actual version it covers (2.0.x).
3. Start a new maintenance branch for 2.1.x so that patches can be applied to 2.1.x releases.
4. Use github pull requests instead of email patches.

Justification:

1. Putting new code onto the master ensures it gets into daily builds and is tested by those of us who work on master, and it is possible to develop iteratively without topic branches (each committed version has to work and have test cases, even if it does practically nothing).
2. The current 'maint' branch concept is both too abstract (you need to investigate to see what version it refers to) and insufficient (excludes multiple maintenance branches).
3. Adding a maint branch for 2.1.x (and for each minor version in future) allows contributors to make patches on _any_ released version, in a clear and explicit way.
4. Using github pull requests ensures that patches do not get lost, can be commented on, etc. Pull requests are the standard way of working; the email submission process is not common, and does not support any workflow (e.g. quick view of open/closed requests). Those who absolutely need emails can get them from github.

The onus of providing a working patch remains with the contributor. Github pull requests are compatible with signed-off commits.

Of course any maintenance branch needs a maintainer; if the process for maintaining and testing a branch is easy (which it must become IMO) then that is not a burden.