On Sun, Oct 30, 2011 at 6:00 PM, Martin Sustrik <[email protected]> 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 <[email protected]>" 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
