I'm working on the huge OpenStack project since 2 years. I really like its development workflow, even if it can be seen as complex at the beginning.
The core of the workflow are reviews using Gerrit at review.openstack.org. In fact, I probably spend 80% of my time on review.openstack.org when I work on OpenStack. I probably spend the remaining 20% on IRC, the mailing and meetings to discuss.
OpenStack uses Git and has a cool "git review" tool. It's very easy to send a review: commit something locally, type "git review", that's all!
Your change will not be modified by others, you are reponsible to fix all issues, including all annoying coding style issues. But it's easy to modify a change. You can use local Git branches. But it's also very easy to retrieve a change into a new local branch: git review -d <review_identifier>.
Since a change is a branch, retrieving a change does conflict. To rebase a change, use the common "git rebase master" command. Rebase is a common command in the OpenStack workflow.
It's very easy to work on a patch serie: commit multiple changes locally, then type "git review". This common will create N reviews linked all together. For me, it's a real enhancement compared to the Python workflow. For example, it's common to start with a "cleanup/refactor" change and then a second change which does the "real" work (fix bug, add new feature, etc.). It's *much* easier to review a serie of small changes.
On Gerrit, *anyone* can vote on a change. It's not used to ask for a bugfix. A vote means that the reviewer read the change and understand it. Votes:
* +2: a core reviewer consider that the patch is good enough to be merged * +1: "looks good to me". A core reviewer may vote +1 to say "ok, but ..." with a comment * no vote: used to ask questions * -1: the patch must be updated to fix reported issues * -2: major design issue, you must rewrite your change differently, or the whole proposed change is rejected
It's convenient to see a quick summary of votes. On Round Up, its requires to read individual comments, and almost nobody explicitly write "+1" or "-1" in comments on bugs.python.org.
It's also possible to make a change depends on another. For example patch B depends on patch A. Even if the patch B is accepted, it will not be merged until the patch A is merged.
Tests are run in pre-commit. There are 3 major kinds of tests:
* coding style: basically, the flake8 command. Some projects use other tests (ex: pylint) * unit tests * functional tests
It's very rare that coding style and unit tests produce "false positive". The functional tests are different. It's *common* to get random failures, it's almost "part of the process", even if it's very annoying. But it ensures that when a change is merged, it doesn't break anything.
If it's no obvious: I would love to use the same workflow on CPython :-)