On Tue, Mar 22, 2011 at 9:38 PM, Martin Lucina <[email protected]> wrote:
> Nice to see a formal discussion, after the changes which were made in > February. This was discussed quite heavily, on IRC and on this list. You were absent. That's your right, but no-one is obliged to wait for you to come back online. > So, no problem with having 2.0.x. or 2.1.x. maintenance branches. For various reasons both Martin and I prefer to work in separate gits, rather than on branches in one git. You, a third person, are free to create your own processes but it's not really your job to try to force your view of process onto other people. > Am I to take the former point (one ego per git) to mean that you are now > putting up a big "hands off, I am boss here" sign on 0MQ 2.1.x stable > releases? At the moment, yes, to the extent that I'm taking responsibility for these releases. The release process was too slow before, forcing people to choose between unmaintained old code and unstable new code. That was the trigger for the changes in the release process. We agreed last summer that I'd eventually handle the release process, so it's not useful to express surprise now. However, the stable releases are the result of patches provided by many people, not of work done by me. My role is mainly cleaning up and packaging. If there's anything wrong with the release packages, please do let me know so I can fix them. Splitting the roles of package maintainer from contributors was a large part of my desire to take over this process. Depending on a single person to both know the code, and make packages, was clearly not working well. > And the latter point (changes flowing N-to-N) that you have no problem with > your 0MQ 2.1.x stable release diverging in any way that *you* deem > neccessary from master? Shrug. You are free to fork any 0MQ repository and make your own versions and releases. It is LGPL licensed. The packages distributed from the zeromq.org site, which iMatix owns, and labelled ZeroMQ, a name that iMatix also owns, ultimately fall under iMatix's purvey. If you feel iMatix has been a bad host to the 0MQ community, feel free to fork. This is an essential freedom, don't hesitate if you think it's necessary. > I see no such safeguards now, and I see changes such as ROUTER/XREP going > into 2.1 at the last minute. This, again, was discussed extensively here on the list and there was consensus. You may feel there was not sufficient discussion but I've been asking for fixed socket type names since June 2010. The changes in 2.1 are aimed at cleaning up the nomenclature now, rather than later, so there is less pain all around. The ROUTER/DEALER names have been proposed and discussed over and over, you are the only voice that has voted against the changes, and your reasoning seems to be "don't change stuff", which is unhelpful. We're making software, and change is necessary. > When I discuss these with Martin Sustik personally, he tells me that XREP > will not be going away in 3.0, which is completely contrary to your making > it as deprecated in 2.1. Again, shrug. My recollection is agreement with Martin to rename XREP to ROUTER, XREQ to DEALER, and to keep those X- names for internal plumbing. > Actually, I've seen review happen fairly often, most recently yesterday > with the HTTP proxy patches. And the reviewes we see are only those where > people speak out publicly. Indeed, the HTTP transport layer patches were reviewed. However you make my point - the review was of commits on github, not of code published to the list. My proposal is to do exactly this, send people to commits on github, and discuss on this list. > Is it really *that much work* to send the output of git-format-patch? As a manual process it's more error prone and slower than copying/pasting one URI. Martin has been sending me commit tags for 2.1 maintenance, and I'm fairly sure it would be annoying for him to switch to git format-patch output. Applying patches is also more work than reviewing commits online. Finally, it's harder to apply workflow to patches, whereas we do this for cherry-picking. E.g. https://github.com/zeromq/zeromq2-1/issues#issue/10. (With a patch would require creating a gist, then referring to that gist in the issue.) > Indeed. See above. I'll just point out that your own ego is dominant and not always pleasantly for others. I vaguely recall an original proposal for multiple release branches that was quashed without sympathy (though now you are arguing for exactly that). However without egos, and the desire to dominate the work we do, this community would not exist, so let's embrace that rather than deny it. > I will make one last comment for the record. I think that the introduction > of multiple git repositories for a single project is unfortunate, > encourages fragmentation, and removes a chance to obtain the entire > project's history in a single git. From a quick glance at the thread in > February there was at least one other person who expressed the same > opinion. I am totally in agreement, and have discussed this "no single history" with Martin on several occasions, however his view was (Martin, correct me if I'm wrong) that it was more important to give each person freedom in their space. And after the experience of working in separate gits, this seems accurate. We're much more productive like this. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
