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