I had the good fortune of being in the #couchdb-meeting channel
yesterday when the meeting kicked off, and subsequently got tasked with
proposing a review process based on Github Pull Requests based on the
recent "we need more reviews" thread.
To that end, here's the proposal for mixing Github Pull Requests (Github
PRs heretofore) into the Jira, Git, Mailing List mix.
First, Github PRs are already in use by non-committer contributors (like
myself) and frequently used by the Fauxton devs (Garren & Sue mostly)
for reviewing each others more "volatile" patches.
Second, this "process" can be added along side how things are done now,
used as found useful, and (in time) potentially become part of the daily
process of getting code into master. This proposal is to encourage the
use of Github PRs for anything non-trivial to get at least two sets of
eyes on all the code that hits master. Unlike a tool like Gerritt (which
I've used in the past), this is not a blocking process and can sit
alongside (as it does now) the current "a patchy" process of committing
straight to master.
The key thing missing from Github PRs is communication with the other
tools already in use: Jira and the Mailing Lists.
I've done some research to bridge that gap, and come up with the
following options.
Option 1:
Adding an @apache.org "bot" email address and Github account with
notification levels and "watch" status to relay PR comments to the
Mailing List. There is an Email Service Hook for Github repos, but it's
limited to commit activity (from what I could tell). Having a full
account that handles this can increase control on what's received, set a
proper sender on the emails to the list, etc.
https://help.github.com/articles/notifications
Option 2 (likely too bothersome):
Github does offer a Jira service hook. It seems to only handle commit
activity and require specific commit message content to actually function:
https://github.com/github/github-services/blob/master/docs/jira
Option 3 (much more overhead):
Zapier.com (would require $$ or a donation from them of an account to
Apache as well as "buy in" by Apache Infra, etc) can relay activity
within a Github project to many other tools including Email and Jira.
The advantage with this approach would be turning PRs and subsequent
comments into Jira ticket comments. The setup overhead is much greater,
the ongoing expense (possibly), and someone(s) to keep it
fed/happy/working properly may obviate it's value and use.
Option 1 is by far the more doable, easier to ship sooner and would get
an existing "process" in place with the existing tools. The same process
done for the Mailing List notifications could potentially be done (with
a bit more setup work) to get notifications sent to Jira.
Objectives met by Option 1:
- add code review to Apache CouchDB process
- keep it an "additive" process (rather than a blocking one)
- increase cross-tool communication
Hope that helps! :)
Thanks,
Benjamin
