Thanks Jack.
Technically, I don’t see much changing in libnanomsg apart from bug
fixing. Yes, I’d love to gut tcpmux because I strongly feel its difficult
or impossible to support, with almost no real use cases; the better use
cases are better solved via websockets IMO, using a device if necessary.
I don’t intend to support older releases of Windows; my past statements to
that effect stand. The problem is that older releases lack certain APIs,
and I can’t easily support them. Nor am I going to expend any effort on
supporting cygwin. (If someone else wants to work on supporting it, and
its non-intrusive, I’m ok with continuing it; however I believe there are
some serious problems in Cygwin failing to expose some of the APIs that we
need. I am not interested in #ifdef hell for such platforms; frankly I
don’t want to deal with end-user complaints when they don’t work because I
won’t be able to support them. My resources here are limited.
C89 yes. I could see adopting C99 in the future, but only if we ascertain
that nobody is stuck with a C89-only compiler. (I don’t think we have
anything that isn’t C89 compliant in the code base now.)
The POSIX compatibility layer, as much as I despise it, has to stay. I’ve
been thinking of ways to bypass that — enabling an alternate API, but those
ideas are not fully formed yet, and frankly we need to make what we have
work. We’re not sufficiently bug free that I want to invest in that. I
could see removing nn_poll() from the Windows port, because I think it
doesn’t do much good there, but I’m not sufficiently convinced at this
point that doing so won’t cause more problems than it solves.
I’d probably help finish the work to adopt cmake, and torch the autoconf
based system.
IETF RFCs are irrelevant.
Note that *none* of this precludes a future project that is wire compatible
with libnanomsg, but utterly API incompatible. I’d consider that a
separate effort, and I’ve even started some work on it. If I do that work,
it won’t be a public design discussion, because I don’t want to debate e.g.
libmill, libuv, or whatever other goofy ideas are floating around. Such an
effort could one day replace libnanomsg, but only if people (application
developers) decide that they want it to (presumably because that will mean
changing their code). And such a future effort might have some very
different design considerations. (E.g. require a reasonable threading
library, elimination of POSIX-style APIs or poll()able file descriptors,
I’d probably even remove the various DNS client support. But again, that
effort would *not* be libnanomsg — it would be something quite different,
just as mangos is quite different (and yet wire-compatible with libnanomsg).
At the end of the day, I don’t see a lot changing from the road we were
headed down back in December; its just that going forward I won’t be asking
for permission to take libnanomsg in that direction, if I’m BDFL; I’ll just
*do* it.
I may adopt a CoC; then again I might not. If I do, it won’t substantially
change anything. More likely at this point, as BDFL, I’d basically tell
people that if I think they’re misbehaving (or whatever), that I’ll give
‘em the boot (after at least one clear warning). Nobody has done that here
yet, that I can remember. I might wind up adding a document but at this
point its likely to be minimalistic — perhaps something like this:
https://github.com/rosarior/Code-of-Merit/blob/master/CODE_OF_MERIT.md —
although even this is a bit more long-winded than I’d like. The first
paragraph is particularly salient though.
On Fri, Apr 8, 2016 at 1:52 PM, Jack Dunaway <jack@xxxxxxxxxxxxxxxx> wrote:
I support Garrett's leadership here, especially based on his long-time
record of supporting newcomers to nanomsg (engaging on GH and gitter)
and care given to design considerations. And the ability to say 'no'.
Not to mention being a solid contributor.
Yet, Step One would be agreeing on which of the existing core tenets
you would propose moving forward as BDFL. Technical considerations,
such as POSIX compliance? IETF RFC's? Windows support? C89? nn_poll()?
tcpmux? (The more important considerations are what goes away, rather
than what is added)
-JRD
Sent from a mobile device
-JRD
Sent from a mobile device
On Apr 8, 2016, at 1:00 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:in early January.
The nanomsg project has been fairly leaderless since I stepped down back
maintainership role, but that has not occurred. Nobody is merging or even
I’d hoped that there would be signs of someone else stepping up into the
reviewing contributions that I can tell.
reluctantly — willing to step back into the leadership. To be clear, if I
I’ve therefore stated (as of a day or two ago) that I would be — albeit
were to do this, it would be as a benevolent (hopefully) dictator for
life. That is, I am not interested in trying to lead or govern this
project by consensus. I will listen to opinions, and I may ask for them,
but at the end of the day if I’m lead, then my decisions would be final,
within legal limitations. (Notably legally I cannot relicense the project
— nor do I have any interest in doing so. So the freedom to fork if you
can’t stand my leadership would remain.)
nanomsg whither and die. And yet, that seems to be where its headed. I’ve
The reason I’m wiling to do this is *solely* because I don’t want to see
gotten some indications in support of me doing this in other fora, and at
least one formerly active contributor has indicated that he might begin
contributing again under my leadership.
Dirkjan Ochtman needs to make a decision as he is the last person with
However, I will not take control of the project by fiat. In particular,
commit privileges to the github repo. Technically I still have admin
privileges, but I’d rather not act without his consent.
to my taking this step, then I’ll decline to take the reins. I don’t want
I’ll also state this — if there is a clear majority of opinions opposed
to be an unwelcome leader — I don’t love this project *that* much. So if
you are violently opposed (or in favor) please speak up. Once I *do* take
the reins, I won’t be very likely to give them up again.
future for nanomsg is to whither and die.
That said, if I do *not* take the reins, then I suspect the most likely
be sure that a dictator is really what you want. You’ve been warned.
To be clear, if you support my action, you *are* supporting a BDFL, so
- Garrett
