Hello,
The past few months I've noticed that people (committers and contributors)
use the tracking system in various different ways. In most cases, this is
not really problem but if we could manage to do some things in a more
uniform manner maybe the release process and various other tasks could be
simpler and possibly more efficient.
Before creating new issues, please perform a search and verify if an
existing issue already exists.
If a new issue needs to be created, try to provide a concise description of
the problem/improvement/evolution/change that needs to be made.
Please avoid tagging specific people in the description of the JIRA asking
for feedback. This discourages other contributors to participate in the
discussion and provide valuable feedback. Feel free to tag somebody in the
discussion if there is a regression that seems to be related with a
particular commit. The best place to ask for feedback related to an issue
is the dev@calcite list.
The assignee of the issue should mark it as in progress, if he/she is
working actively on it. When the change is ready, the contributor should
submit a PR using the instructions on the site and add the label
"pull-request-available" if that is not done automatically.
Possible solutions for resolving the issue must be part of the discussion
in the JIRA and ideally not in the PR it self. Comments in the PR are
encouraged when the discussion concerns particular lines of code.
After merging a PR that corresponds to a JIRA case, the committer must:
- resolve the issue (not close it);
- select "Fixed" as resolution cause;
- mark the appropriate version (e.g., for now we use 1.20.0) in the "Fix
version" field;
- add a comment (e.g., "Fixed in ...") with a hyperlink pointing to the
commit which resolves the issue (in github or gitbox).
There are cases where the JIRA issue may be solved in the discussion (or
some other reason) without necessitating a change. In such cases, the
contributor or committer involved in the discussion should:
- resolve the issue (not close it);
- select the appropriate resolution cause ("Duplicate", "Invalid",
"Won't fix", etc.);
- add a comment with the reasoning if that's not obvious;
The release manager should close all issues mark as resolved when
publishing the release adding an appropriate comment (i.e., "Resolved in
release X.Y.Z (YYYY-MM-DD)").
The items above are guidelines that exist in the website or things that
appeared in other discussions in the past. If you see things that are
incorrect or that need to be done differently feel free to reply to this
email.
Best,
Stamatis
