All, [email protected] said: > The question is whether to start with zeromq3-0 repo or libzmq repo. Are > there any technical considerations? The log seems go back to initial > version of 2.0 (summer 2009) in both repos. > > From social perspective libzmq has more watchers than 3-0, which may > make it preferable.
Martin Sustrik and I had a personal discussion (sitting in a room together) about the technical side of things which I'll try to summarize here for the benefit of everyone. Please note that this is not any kind of endorsement from my side on what should be done, Martin merely asked for technical advice. My views on this topic are well known so I'll stay out of the process/politics, watch the flames, and help Martin implement whatever is decided upon. Martin would like to get the zeromq/libzmq repository (since this is considered canonical by most people) into a clean state where: 1) zeromq/libzmq/master is the currently released version (3.x) 2) experimental work (most of "4.0") which has broad community support and which is actually expected to land in a future release can be shared with the wider community on topic branches off master in the zeromq/libzmq repository 3) experimental work which is raw or of a more one-off nature should live in individual developers forks of libzmq, *not* in zeromq.org/libzmq. That includes Martin's own experiments. 4) ideally, though maybe not at the same time, and maybe not technically feasible, 2.x should also live as a branch off libzmq. 5) Martin would like to continue using signed-patch-to-ML as the preferred way of accepting contributions, but would also like to explore the use of pull requests, *however* this must be done in a way that is transparent to the entire developer community which AFAICT rules out the Github interface (see below). How can we achieve the above technically with least pain for people? libzmq master has the most "correct" history and continuity so one option would be to *delete* every commit post 3.0, and then apply any 3.x backports. However, this cannot be done without rewriting history which results in pain for every fork and would probably also mean the repo must be deleted and recreated on Github. A less painful solution would be to revert all 4.0 experimental work (i.e. the full commits, using git-revert), thus getting libzmq back to 3.0, and then put the relevant 4.x work which fits under point 2) above on topic branches and anything leftover falls under point 3). This still leaves open the question of what to do about 2.x, if anything. Suggestions welcome; if libzmq still has the original 2.x "stable" branch present in it then it's possible that could be updated by hand to match zeromq/zeromq2-1. A couple more points: Regarding pull requests vs. patches. Martin's main problem with the Github interface to pull requests is that it is not transparent to the entire community. One way to make that work is to go back to Linus Torvalds' original idea of what a pull request is: - A pull request is simply an email to the project mailing list, asking the maintainer to please pull all commits from branch X of repository Y. It is assumed that such a branch is effectively a topic branch, and has been rebased to merge cleanly against the current master. Martin, I think that's all, please expand/correct/denounce whatever I got wrong... Any Git experts in the audience please comment. -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
