-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
