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
