[core-workflow] I love OpenStack workflow

[Victor Stinner]

Hi,

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 :-)

Victor