Hi Pieter, all, On Mon, 9 Jan 2012 16:58:54 -0600 Pieter Hintjens <[email protected]> wrote:
> 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. This is great. +1 for coming back to the single-repository model. > 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. So the official zeromq/libzmq repository master branch essentially becomes a staging tree for "proposed updates to the next release", a.k.a. linux-next, "pu" or similar approaches used by other projects, right? The above, along with the "no direct changes to libzmq" means that libzmq/master should only see merge commits of pull requests. Right? As for how the release branches will work, I presume that is yet to be fleshed out in detail, but the commits there would also consist mostly of merge commits or cherry-pick, with the occasional direct commit to update e.g. NEWS, or zmq_version.h. > 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. It would be good to see "pull request" explicity defined as "an e-mail sent to the zeromq-dev mailing list by the repository owner, asking the maintainers to pull from git://.../some-branch". Further, pull requests created on Github but *not* also sent to the mailing list must be ignored by the maintainers, and this would be prominently documented. Rationale: This is needed to keep the process of accepting new changes into master transparent to all interested parties (maintainers, developers, users, lurkers, ...) and to avoid fragmenting the discussion or code review. This doesn't stop anyone from using Github or other Web 3.0 coolness to create pull requests, but it does ensure that everyone else is kept in the loop on any discussion while not being forced to use the same Web 3.0 coolness. > 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. Good stuff, thanks Pieter and Mikko for putting this together! -mato -- Martin Lucina <[email protected]> _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
