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.
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. * 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. 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. * 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. 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. Cheers Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
