[zeromq-dev] NetMQ/JeroMQ following ZeroMQ changes

[Pieter Hintjens]

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 <pieterh at gmail.com> 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" <somdoron at gmail.com> 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
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>