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

[Martin Sustrik]

On 10/30/2011 10:34 PM, Pieter Hintjens wrote:

> 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.

The problem with early design is that you get it wrong for the first 
time anyway. So, what's rather needed is a separate sandbox for 
experiments. That's what's I am trying to advocate for a long time: The 
'libzmq' project is a chaotic mix of experimental and stable features 
and we need to separate the two in some way.

>> 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.

Agreed. It was the only politically viable solution at the time.

> 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.

Yep. Still, multiple workflows is annoying and confusing my hope was 
that we can make a step -- however small -- towards unifying them.

> Other things that differ in our workflows:
>
> * How we use the issue tracker.
> * How we use test cases.

Ack. More process issues to solve.

>> 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.

If I'd followed that advice I would be working on my own experimental 
branch for past two years :)

Anyway, fair enough. The above means there's not going to be an unified 
process for 0MQ project either now or later. I have no clear opinion on 
that at the moment. I'm going to think about it a bit more.

>> 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

Right. AFAIU they are saying the same thing in other words.

> 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.

IANAL. I have no idea whether the fact that any licensing problem can be 
tracked to individual person's fraudulent "certification of origin" has 
any legal ramifications. However, I guess the matter was reviewed by 
layers when introduced to Linux kernel process and deemed worth of doing.

If the users of 0MQ feel that eventual legal protection resulting from 
signing patches off is not worth of the effort, I am happy to drop the 
policy.

>> 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.

Ok, if there's a way of doing it technically, no problem about that.

>> 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.

English is not my first language and if it felt offending, I apologise. 
My understanding was that code like "if (error) return OK;" is almost a 
definition of "hack" -- no value judgement was intended.

Martin