Hi, Let us have a vote for PR-centric workflow for Calcite.
[ ] +1, let's move to GitHub PRs/Issues for change management. [ ] -1, keep using JIRA because, .... Here's my vote: +1 (binding), let's move to GitHub PRs/Issues for change management. Note: dev@calcite keeps as is. I do not suggest replacing it. I suggest the adjustment of development workflow would reduce maintenance costs, make contributions easier, and make reviews easier. Note: please don't consider this as "replacing JIRA with GitHub issues". I understand that a mere replacement of system X with system Y often brings nothing. See the relevant discussion thread: https://lists.apache.org/thread/m2h13v2p7kowglj73qr4sqn1c3pm8tlq Current state ==== We already allow committing changes to Git without PR, and without JIRA ticket. We already allow submitting PRs without JIRA. I do not mean we encourage that, however, there's no strict rule like "every commit must have JIRA". The pattern I see is: * contributors spend time figuring out if there's a bug in their system or if there's a bug in Calcite * then they create JIRA with all the details * they submit a PR with the relevant change right away * they copy the same-looking information multiple times: git commit, JIRA description, PR description (it is often left blank though) The discussion often separates between JIRA and PR. PR is super-convenient for line-based comments, on the other hand, "bigger comments" are put in JIRA (for unknown to me reasons). It is extremely sad when JIRA comments refer to specific bits of the code. We even have a label "discussion-in-jira" that means "there's a discussion JIRA, deal with it somehow". Suggestion ==== Make PR-first a common approach for most of the changes. Small changes like adding tests, fixing documentation could come as pull requests without creating the corresponding JIRA ticket. https://github.com/apache/calcite/pull/2628 (Add test for 'a IS NOT NULL...) All the comments from https://issues.apache.org/jira/browse/CALCITE-4917 could be put to the PR2628 itself. There's no need for a separate "ticket" or "issue" since PR itself could explain the reason for the change quite well. I suggest we put "high level" comments into the PR itself. The same works for bigger features. A bigger feature can appear as a draft PR, then we shape it in comments, and merge it. A complex feature can appear as a GitHub issue that references other issues or PRs. Sometimes we do not have a solution, so we might create GitHub Issue or send dev@calcite mail for that. In practice, the suggestion does not change much, however, I suggest removing the duplication of work (no need to copy the information across PRs and JIRAs), it makes merge simpler (no need to update JIRA), it makes searching issues easier (there would be a single field to search for issues). Release management ==== Both GitHub PR and GitHub Issue can be associated with a milestone (~version), so we could use it to track which release includes what. Issue history ==== We could keep old tickets in JIRA and use GitHub for new issues only. That is the most trivial approach, Airflow team did that, and we might be ok with that. An alternative option is to copy issues (including resolved ones). I guess attachments would be hard to clone, however, copying issues and comments should not be a problem. Other ==== I might miss certain bits, however, I suggest figuring out the solutions later. I am sure GitHub covers all the cases we need, and we have dev@calcite as a fallback. Vladimir
