More detail now... :) We do not distinguish features from bugs except in one specific way, which is when backporting changes to stable versions.
The change process is (a) identify problem, (b) make improvement. In a true sense, _every_ change can be viewed as fixing a bug, with before/after tests. Please keep this in mind and refrain from adding back notions of "bug fix", "feature", etc. to the issue tracker... Your real goal is interoperability, not feature completeness. You want a NetMQ app to talk to a libzmq app without concern. You may also want to implement the "official" API semantics just so NetMQ users can use the same reference manual. And then a higher level API that makes sense for .NET. For interop, my advice is to work by test cases and then cherry pick changes from libzmq only where they make sense. I suspect you will diverge and in time have a totally different code base. Which would be sensible. At all costs, avoid cargo cult patches, where you take code because you believe it will bring the gods back. Either a patch fixes a provable (testable) problem, it it is itself a problem. Lastly, final thing, any workflow or process you adopt for NetMQ should be invisible to libzmq. It has to be a pure "hostile" fork in that sense. This is to avoid global mutable state. You can figure out what I mean. Good luck. NetMQ is an awesome, fabulous project (as is JeroMQ). Pieter On Fri, Dec 13, 2013 at 4:39 PM, Pieter Hintjens <[email protected]> wrote: > I'll respond in more detail later, when I can. We don't really do features. > All patches should be solving a clear issue. What I'd do is aim for protocol > interop and pull in changes which go that way. It is the only real criteria. > Also, use test cases written in native libzmq to check netmq. > > On Dec 12, 2013 7:24 PM, "Doron Somech" <[email protected]> wrote: >> >> Hi All, >> >> As a maintainer of NetMQ is pretty hard to follow the ZeroMQ changes. I'm >> trying to create a plan to catch up with the ZeroMQ features but it's hard >> to know which features belong to which version and which pull requests >> belong to each feature. >> >> Now that the ZeroMQ issue tracker is on github I want to suggest few ideas >> to make it easier to follow ZeroMQ changes: >> * Differentiate between feature and a bug (maybe using convention or >> label) >> * Relate each pull request to an issue (using a comment with # followed by >> the issue number and a convention in the Pull Request name). multiple pull >> requests can be related to an issue. (IMO if a pull request is fixing a bug >> of a feature that was not yet released the pull request need to be relate to >> the feature and not to open a bug) >> * Attach a feature to a version, maybe using milestone or labels. >> >> With the suggested changes it will be easier to follow ZeroMQ changes. I >> would be able to easily open issues in NetMQ tracker and link the original >> issue and pull requests to create a catch up plan for future releases. >> >> Let me know what you think about the suggested changes or your other ideas >> on how to catch with ZeroMQ changes. >> >> Regards, >> >> Doron >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
