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

[Martin Lucina]

All,

sustrik at 250bpm.com 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