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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
