Pieter, [email protected] said: > Hi All, > > After some time playing with multiple gits for 0MQ releases, I'd like > to reopen the discussion on best practices for our community on > contribution workflow.
Nice to see a formal discussion, after the changes which were made in February. I'm still somewhat surprised that I wasn't so much as politely consulted by yourself or Martin in at least a private email at the time that the release/git/contribution process was re-engineered, especially since I put quite a lot of time and energy into picking a process that would work in the first place! Had you cared to ask at the time, I would have pointed out that the original process can work with the concept of multiple maintenance branches, in a single Git repository. So, no problem with having 2.0.x. or 2.1.x. maintenance branches. > My goals here is consistency, simplicity, and freedom. Also if it > doesn't make sense on a grey Monday morning before coffee, it's too > complex. > > Some observations: > > * The neatest organization seems to be "one ego per git". We've been > using this rule to divide the original core 0MQ git into separate > projects, and it feels right. > * We end up with many gits, each with a clear owner, and with flow of > changes going between them N-to-N. 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? 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? The original process we used *ensured* that: a) all changes that were considered for backporting to a stable release did in fact make it there (this was enforced by the "changes graduate from 'maint' to 'master' bit) b) all changes that applied to *both* 'maint' and 'master' made it there (enforced by verifying 'master' is always a superset of 'maint' before release) I see no such safeguards now, and I see changes such as ROUTER/XREP going into 2.1 at the last minute. 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. > * github pull requests don't work except between an original git and > its forks. Thus they are useless for general distributed work. > * Sending signed-off patches to this list is frankly a lot of work for > both parties. The advantage is that people can review patches but that > rarely happens. 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. Is it really *that much work* to send the output of git-format-patch? > > Now to conclusions: > > * The 0MQ community should be more explicit about the egos behind each > project, since if you want to contribute to project X, you're > essentially convincing that ego to accept your work. Indeed. See above. > * A simpler git workflow would be fetching and cherry-picking from a > source git into a target git. We've been using this to push patches > from (the git still known as) 0MQ/2.2 into 2.1. > > What I'd like to do is further simplify > http://www.zeromq.org/docs:contributing, eliminating the signed-off > patches business. > A commit to a properly licensed git project by a named author counts as > "signed off" afaik. If and only if that commit makes it unmodified into the git repository in question. AFAIK the reason Signed-off-by: was introduced by the Linux kernel was to ensure clear tracking of a patch-and-all-it's-derivative-possibly-munged-versions. It's just "git commit -s". I still don't see the huge complexity in that. And yes, I'm repeating myself now. > So the workflow would be: > > * Contributor: send the commit URI to this list with a proper [PATCH] subject. > * Project owner: click to review change, fetch that git, cherry-pick > the commit, discuss on mailing list thread. > > Comments welcome, though "other projects don't work like this" is > pretty unhelpful: our processes work, I'd like to improve them > further. 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. -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
