Mailing-List: contact dev-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
MIME-Version: 1.0
From: Arina Ielchiieva <arina@apache.org>
Date: Fri, 25 Aug 2017 13:42:23 +0300
Message-ID: <CAC1ju53wE5CzG3Yod+R5gKR4x-=Y3_T=m+jLHZoQ68vp-ehEqg@mail.gmail.com>
Subject: Apache Drill Project: how to work on Jira tickets, create PRs and
 merge the changes
To: dev@drill.apache.org
Content-Type: multipart/alternative; boundary="94eb2c0763c6b328200557919995"
archived-at: Fri, 25 Aug 2017 10:42:35 -0000

--94eb2c0763c6b328200557919995
Content-Type: text/plain; charset="UTF-8"

Hi all,

since there are many new contributors in Apache Drill project, I'd like to
outline the main points on how to work on Jira tickets, create PRs and
merge the changes.

*When you start working on Apache Drill Jira ticket*

1. Please add yourself as the assignee and put Jira status `In progress`.

2. If you intend to include changes in the next release, add Fix Version/s
(ex: 1.12.0). If you are not sure in which release changes will be
included, just add `Future` version.

3. If your changes will have Drill documentation impact (new feature or
change of existing behavior), please add doc-impact label.

4. Please keep Jira description up-to-date so it reflects the actual
changes that have been done. It's good if it would include steps on how to
reproduce the bug and turn on / off / use new feature.

*When changes are implemented*

1. Create pull request to Apache Drill master branch. I won't outline here
the main prerequisites before making PR but all unit tests MUST pass. Also
it is important to include Jira number in PR title so PR would be linked to
Jira (ex: DRILL-XXX: ...). If you forgot to do this, it always can be done
manually.

2. Change your Jira status to `Reviewable`. If you already know who is
going to review the changes, please add this person as Reviewer in Jira. If
not, this can be done later.

*When review is completed*

1. If PR was done by the committer and has +1 from the another committer,
developer or reviewer is encouraged to merge the PR.

2. For all other cases, weekly batch commits process was introduced. Each
week one of the assigned committers merges all PRs that have passed code
review. To distinguish such PRs Jira should be in `Reviewable` state and
with ready-to-commit label. When PR is reviewed and does not require any
other amendments from the developer, reviewer can add this label. If the
reviewer has put +1 but asked for minor changes, then it's up to the
developer to add ready-to-commit label when ready.

*When changes are merged*

These steps are required to be done by the person who has merged the
changes but if not then the developer is encouraged to perform these steps.

1. Change Jira status to `Resolved` (add fix version and reviewer if it was
not done before).

2. Add comment indicating commit id in which changes were included in the
master branch.

Please let me know if there are any other questions.


Kind regards
Arina

--94eb2c0763c6b328200557919995--