Hi all, I'd like to get feedback on a thread we had on IRC yesterday. I'll start by noting a number of problems we face today using/packaging 0MQ, and then propose some solutions.
Problems: 1. It is rather hard to know what version of 0MQ to use: - The stable release is too out of date, has numerous flaws that have been properly fixed in later versions - The development release, which fixes the major flaws, has no bug fixes since it was released - The master HEAD has no formality, and can't be used except by small teams 2. New code (like the new xsub/xpub sockets) is not tested in a timely fashion - They are on topic branches that few people know about or work with - We have an unresolved conflict between stability and progress on the master 3. It is not possible to make a sane stable release from the 2.1.x codebase - New, untested code goes into this codebase almost daily - Old, stable code is not separated from new code in any way 4. There is no workflow for patches - If a committer doesn't process a [PATCH] email immediately, it can & does get lost - There is no way to manage one patch applied to more than one branch Proposals: 1. Stop using topic branches for new development, use the master for this 2. Rename the maintenance branch to match the actual version it covers (2.0.x) 3. Start a new maintenance branch for 2.1.x so that patches can be applied to 2.1.x releases 4. Use github pull requests instead of email patches Justification: 1. Putting new code onto the master ensures it gets into daily builds and is tested by those of us who work on master 2. The current 'maint' branch concept is both too abstract (you need to investigate to see what version it refers to) and insufficient (excludes multiple maintenance branches) 3. Adding a maint branch for 2.1.x (and for each minor version in future) allows contributors to make patches on _any_ released version 4. Using github pull requests ensures that patches do not get lost, can be commented on, etc. Of course any maintenance branch needs a maintainer; if the process for maintaining and testing a branch is easy (which it must become IMO) then that is not a burden. Cheers -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
