[zeromq-dev] CZMQ community & red cards

Goswin von Brederlow goswin-v-b at web.de
Thu Oct 16 18:30:50 CEST 2014

On Thu, Oct 16, 2014 at 05:37:54PM +0200, Benjamin wrote:
> For me, "misleading" and "hiding" are quite strong words, and griwes
> rant did not help.

They are just words. Strong, weak? I'm not a walking theasurus or
whatever that thing is called that lists lots of words meaning the
same thing. I write mails like I talk, not like writing an essay for
university admission that you rewrite 20 times until it is perfect.
English is not my native language and I've always been bad a languages
so I have even less words to choose from than other people.

So I didn't pick those exact words because I wanted to put any
emphasis on them. And I hope you do see a difference between "the
title is misleading" and "you are misleading".

Maybe a better wording would have been:

   I noticed that XXXXXX has code changes while the pull request says
   documentation changes. Did that get included there by accident?

But that's too late now.

> Linus has some strong views about Github which are related to your
> points, especially how pull requests work [1]. But that's more of a
> Github issue in general. In the end you need many people actively
> engaged in checking code, right? So in that case checking the source
> code changes (on the level commits or PR's?)
> https://github.com/torvalds/linux/pull/17#issuecomment-5654674

Linus is also verry good (as in efficient and no nonsense) in
rejecting commits that are bad or questionable. Because of that people
get angry. But also all commits are sane and uniformly documented.
Something that makes maintaining and fixing the code so much easier.

That is something the czmq maintainers are exceedingly bad at. The sad
thing is the "we merge everything and then fix it if its broken"
behaviour is in direct opposition to the C4.1 rules. The C4.1 has some
good rules but they only work if everybody follows them. That includes
me but that also include him. One problem, one patch, one pull
request. Not two unrelated problems in a single pull request.

The smaller and more specific you make each pull request the easier it
gets to read them even with githubs interface.


More information about the zeromq-dev mailing list