Hi Garrett, Sorry for not responding in time.Given that I have almost no time to work on nanomsg :( , I would be happy to cease the control of the project to you.
Making a fork is unnecessarily confusing for the users IMO.I am not sure about the trademark though. Should we pass it to some kind of neutral entity?
Martin On 2015-03-19 19:41, Garrett D'Amore wrote:
All, Given the responses I’ve received so far (and also the lack of any response from Martin), I’ve decided that it is appropriate to create a fork. I’ve created a new fork, called mamomsg - located here: https://github.com/gdamore/mamomsg <https://github.com/gdamore/mamomsg> The idea is to stay close to the spirit of nanomsg, and, as much as possible, API compatible. But we’re going to fix some of the bugs. It may well be possible / practical to re-merge with nanomsg at some point in the future — if that happens, I’m supportive. My fork here cannot be called “nanomsg” as Martin owns the trademark, and frankly I want to avoid confusion. libmamomsg has the same ABI as libnanomsg, but is -lmamomsg. I’ve left (for now) the headers in place. I might change that it the future. I consider libmamomsg *extremely* rough at present — frankly as I’ve spent more time in libnanomsg there is a lot of roughness there too. I’m going to fix some of that — for example just use cmake everywhere and ditch autotools, and get CI automation of testing for all platforms, not just Windows. I may find that its better to move headers or change symbol names, but if I do that, I’ll leave some kind of compatibility layer in place. I’m not sure yet what that will look like, but I have some ideas. I’m happy to accept PRs or to involve other questions, concerns, etc. For now, I’m going to keep using the nanomsg lists. That may change in the future too. We shall see. - Garrett