>I know people/companies who have built tools/plugins >around JIRA for getting useful information such as which internal forks >have this particular fix, etc
That is true. However, I do not know what should we do about it. Of course, any change brings hidden costs, so if the benefits are unclear, there's not much point in making changes. On the other hand, the more I discover, the more I am sure GitHub Issues would be great for Calcite. I started the discussion like "it looks we are fine, but we can try GitHub", and now I am quite enthusiastic that moving to GitHub would bring multiple improvements in various aspects. >I turn to JIRA >or GitHub and it turns out that I am able to find the information easier >with JIRA. GitHub issues are searchable, including comments. We currently "enforce" JIRA tickets, so PRs lack descriptions and explanations, so it is expected you can't find them. Try using JIRA to figure out when we bumped Guava to 31. There's no JIRA for that. On the other hand, GitHub search returns PRs, code files, and commits that match the search. https://github.com/apache/calcite/search?q=guava+31 Then, if you know Git SHA (e.g. from "git blame"), you can find PRs related to that SHA. For example https://github.com/apache/calcite/search?q=890eb61efcccc486e2192110cefe4cac5aa6f150&type=issues Frankly speaking, I never thought of trying to search via commit SHA, but it is a definitely cool trick I learned when reading https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests When it comes to versions, GitHub PRs and issues would have "milestones" (~ "fix version"), and when you browse commits, GitHub shows the list of tags that include this commit. For instance, if you open https://github.com/apache/calcite/commit/2326cf8dc97f473d0efa2b0e4883fef87a40746b , you know Guava was updated to 31 since Calcite 1.28.0 >One unpleasant situation which comes up from time to time is when >discussions develop in both places. However, migrating to GitHub issues >will not completely solve this since we will still need to navigate back >and forth between issue and PR If we allow PR-first (no issue, no JIRA, just PR with the proper description) contributions, then: 1) It will be in a single place, no need to switch 2) Navigation between issues and comments would still be easier in GitHub than commenting like "please continue in JIRA" GitHub allows responding to issues/PRs via mail, and I find it a nice feature. I don't use it often, however, I use it from time to time, and I see others using it. >Moreover, many Apache projects are using >JIRA already which makes it easy to perform cross project search GitHub has an out-of-the-box way to scope search for organizations. Here's a search for Calcite in the Apache organization: https://github.com/search?q=org%3Aapache+calcite At any point in time, you can remove org:apache, and you get GitHub-wide search. GitHub hosts more projects than ASF JIRA, so being able to search and link across them (all, not just ASF projects) would be useful. >I find JIRA search superior to GitHub both when it comes to approximate >text search and exact filters I might be wrong here, however, I think we do not really use JIRA metadata. In most cases, we use only the ticket title, description, and the fix version. There's "affects version" in JIRA, and I do not know if GitHub has a one-to-one replacement for that. However, I would be fine if the affected version was in the issue/PR description. "component" (~core, linq4j, cassandra, ...) could become a label in GitHub. AFAIK the limitation is that labels can only be changed by committers or collaborators. We can mitigate that by: a) Adding collaborators (via asf.yaml) b) Adding committers c) Adding GitHub Actions that label Issues based on descriptions or even PRs based on the set of touched files. GitHub's search features are more than enough for us. We have no fancy metadata for complicated searches :) Vladimir
