[zeromq-dev] Proposal for libzmq maintenance

[Pieter Hintjens]

Hi all,

This is a proposal and request for comments on onward maintenance of
libzmq. Authors of this proposal are Pieter Hintjens and Mikko
Koppanen.

Our goals are:

* To make it easier for anyone to become a core contributor to libzmq.
* To remove the need for separate repositories for stable releases.
* To make the libzmq repository structure simple and unsurprising.
* To reduce the risk of human error or negligence.
* To ensure there are no single points of failure, i.e. individuals
whose absence would be catastrophic.

Some basic principles:

* Anyone can become a contributor to libzmq by making a fork of the
repository and making changes to their private copy.
* We do not mix development and packaging in the same repository:
there will no longer be direct changes to libzmq.
* Experimental and raw work exists as unofficial repositories that we
do not document nor attempt to manage.
* Changes are merged from forked repos into libzmq as pull requests,
after discussion and consensus.
* A separate team is responsible for merging changes, enforcing
process (e.g. issues and test cases) and making official releases.
* One may be on both teams but not at the same time (i.e. one may not
ship one's own work).
* Authors of such repositories can apply any change process they like,
privately.

The organization of the libzmq repository will be simple and
predictable. Master will hold the latest version and is assumed to
always build though will usually be considered "unstable". Releases
each have their own branch (major/minor, e.g. 3-1, 3-2) which goes
from unstable to stable, with tags for each formal release.

To contribute a new feature, one forks libzmq, writes and tests the
feature and makes a pull request. All pull requests would be
automatically published to zeromq-dev for review and comment. When a
feature gets consensus approval the maintainers merge the pull request
onto master. From then on, it will be included in automatic builds and
tested by early adopters.

To contribute a bug fix, one forks libzmq, writes and tests the bug
fix, and makes a pull request to master. The maintainers check that
there is a proper test case (for fixes to stable branches) and retest
the fix after merging the pull request. The maintainers then merge
that fix to the various branches it affects, and the bug fix is then
included in automatic builds of that branch and will go into new
packages.

To make a new official package, the maintainers create a branch, where
the branch evolves through to maturity and eventual shuttering.

Comments and discussion welcome.

-Pieter