-1 I think JIRA works well.
Best, Chunwei On Sat, Dec 4, 2021 at 1:39 PM Julian Hyde <[email protected]> wrote: > -1 > > I’m happy with the status quo. > > > On Dec 3, 2021, at 9:34 AM, Vladimir Sitnikov < > [email protected]> wrote: > > > > 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 > >
