[zeromq-dev] Proposal for next stable release

Stephen Hemminger shemminger at vyatta.com
Fri Mar 16 20:03:29 CET 2012

There seems to be a high interest in having a stable version of zeromq.
The maintainers have done a good job of getting versions like 2.1 out in the
past, but the transition in development model has made some users uneasy.

I would like to propose a new model for stable release 
based on the successful model of the Linux kernel stable
tree maintained by Greg Kroah Hartmann. I am new at zeromq but would
be willing to get this started as maintainer.  But understand this is a
process which means any patch that follows the rules gets accepted, I am
not going to micro-manage the patches, if it meets the criteria it will get
in. The review has to come from the community.

(Proposed) rules based on edit of Linux rules.

Rules on what kind of patches are accepted, and which ones are not, into the
"-stable" branch:

 - It must be obviously correct and tested.
 - It cannot be bigger than 100 lines, with context.
 - It must fix only one thing.
 - It must fix a real bug that bothers people (not a, "This could be a
   problem..." type thing).
 - It must fix a problem that causes a build error, a crash, a hang, 
   data corruption, a real security issue, or some "oh, that's not good"
   issue. In short, something critical.
 - No API, ABI, or protocol incompatibility.
 - No "theoretical race condition" issues, unless an explanation of how the
   race can be exploited is also provided.
 - It cannot contain any "trivial" fixes in it (spelling changes,
   whitespace cleanups, etc).
 - It must follow the coding style.
 - It or an equivalent fix must already exist in zeromq repository (upstream).

Procedure for submitting patches to the -stable branch:

 - Send the patch, after verifying that it follows the above rules, to
   zeromq-stable at lists.zeromq.org. You must note the upstream commit ID in the
   changelog of your submission, as well as the version you wish
   it to be applied to.
 - To have the patch automatically included in the stable branch, send a
   pull request to zeromq-stable.
 - Please note if the patch requires other patches as prerequisites which 
   must be cherry-picked first.
 - The sender will receive an ACK when the patch has been accepted into the
   queue, or a NAK if the patch is rejected. This response might take a few
   days, according to the developer's schedules.
 - If accepted, the patch will be added to the -stable queue, for review by
   other developers and by the relevant subsystem maintainer.

Review cycle:

 - When the -stable maintainers decide for a review cycle, the patches will be
   sent to the review committee, and CC: to zeromq-dev at lists.zeromq.org list.
 - The review committee has 48 hours in which to ACK or NAK the patch.
 - If the patch is rejected by a member of the committee, or zeromq-dev
   members object to the patch, bringing up issues that the maintainers and
   members did not realize, the patch will be dropped from the queue.
 - At the end of the review cycle, the ACKed patches will be added to the
   latest -stable release, and a new -stable release will happen.
 - Security patches will be accepted into the -stable branch directly
   and may bypass the review process (for CVE reasons).

Review committee:

 - This is made up of a number of zeromq developers who have volunteered for
   this task, and a few that haven't.

More information about the zeromq-dev mailing list