[zeromq-dev] 0MQ/3.0, 0MQ/4.0 and 0MQ process

[Pieter Hintjens]

On Sun, Oct 30, 2011 at 6:00 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> However, at the moment we are solving the migration problem caused by
> half-assed implementation of labels in current 3-0.

My advice is to document and discuss proposals on the wiki much more,
before writing code. You might avoid such pain later.

> Yes. It's label stuff. Also, there a split between XREQ/XREP and
> ROUTER/DEALER which can be removed if needed.

Also, not documented and discussed up-front. Martin, I hope you're
learning something here about the value of discovering the accuracy of
a design early, rather than late.

> Yes. However, to do that we have to solve the "ego" problem. It actually
> boils down to only couple of policies that Pieter and myself differ on.

Oh, that's the smallest part of it. Remember that we had literally a
year of arguments over the git workflow, which effectively prevented
us releasing stable versions regularly. The split was a simple, brutal
solution to this, and it worked. I totally agree that multiple
repositories are annoying but it works as a solution.

The difficulty is convincing everyone to adopt a single workflow, and
then keeping this agreement working over the long term. Multiple
repositories allow us to learn, while still producing packages.

I think the main win from splitting the repos was that we didn't have
to impose anything, on anyone. This is really significant. It lowers
the cost of entry, it gets rid of argument, it lets us learn while
also being productive. There is nothing to impose, and no "we" to
impose it.

I can't emphasize the importance of this enough. Git is inherently
decentralized, it's ironic that so many git users still want
centralized structures with all the friction those create.

"Egos" is just a short hand for this.

Other things that differ in our workflows:

* How we use the issue tracker.
* How we use test cases.

> We can for example do a community vote on these and impose the resulting
> policies on the maintainer(s) of the single common repo.

I won't take part in any community that needs voting mechanisms to
make decisions, let alone "imposing" these on others. The freedom to
work as we feel best, and to make *mistakes* is essential.

> The sign-off is a confirmation from the author that there's no such
> conflict. The actual text of the confirmation can be found here:

http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-git-for

My opinion is that there is zero legal value in adding "Signed-off-by:
Your Name <your at email.com>" to a commit. But that's just my view, and
it's really important that we can hold different views in the same
project.

> 2. Sending the patches to the mailing list vs. pull requests. I prefer
> the former as it is publicly visible and allows for developer feedback.

It would be easy (and I've suggested this) to allow pull requests but
require that these be discussed on the list. This can even be done
automatically afaik.

> 3. Merging in hacks, ie. patches that apparently solve a problem,
> however, they do it be ignoring the underlying cause of the problem.

Please don't use pejorative words like "hack" unless you want to annoy
people. There was one instance of a fix to 2.1 stable that stopped a
specific assertion failure from crashing applications. The issue was
left open so we could fix it properly, and we did downstream a better
fix to 2.1 later.

-Pieter