apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vlad Rozov <v.ro...@datatorrent.com>
Subject [DISCUSS] PR merge policies
Date Sun, 16 Jul 2017 19:18:02 GMT

As you may know Apex ASF git repos were moved to the new 
gitbox.apache.org server and as the result of the move committers are 
granted write access to mirror repos on Github. This allows us to 
slightly change guidelines for committers and straight line PR review 
and merge process. Below is my proposal, please review and comment on it:

1. All commits must be pushed to github repository, push to gitbox must 
be avoided.
2. PRs may be merged using gitbox UI. Usage of "Create merge commit" 
option must be avoided.
3. Before PR can be merged, all commits must be squashed, there should 
be only one commit associated with a single JIRA (no change from prior 
policy). It is responsibility of a contributor to squash commits (not a 
4. A rebase by a contributor was required to avoid creating an empty 
merge commit, it is not a requirement now (see below) as we can rely on 
github "Rebase and merge" option to avoid empty merge commits. The 
option provides an additional benefit as it properly records the committer.
5. A committer is fully responsible that the committed code improves 
quality of the product. Such things as broken builds (compile, license 
check, binary files, checkstyle, unit test) after PR is merged is not 
acceptable and may bring questions regarding committer rights. In cases 
where PR merge results in a broken build, the committer and the 
contributor should work together to fix it asap.
6. A committer may always request a contributor to rebase his/her 
changes against the latest upstream/master, but I would suggest that we 
do not abuse such requests. In many cases where changes are limited to 
files or methods that are not modified in the upstream, such request is 
not necessary. I'd delegate that to a committer to decide when he/she is 
comfortable not to require a rebase. Note that in most cases, a 
committer is a developer who is mostly familiar with the 
functionality/code being modified and should be aware of any changes in 
the upstream. It is also possible to request Apache Jenkins to retest 
the PR if in doubts (Jenkins PR builds are configured to merge PR branch 
with the master).

Thank you,


View raw message