-0 on migrating to GH issues. I'd strongly warn against making a change
without a clear and documented plan for issue tagging into a release and
how the release process would change. I do think that we need to have a
single place to manage issues and that Github could have less friction
associated with it; however, I'd want to see that demonstrated before
changing all of Calcite over.
Anecdote: I was involved with another project a long time ago which
moved from Jira issues to Github issues. Despite concerns of others, the
migration moved ahead without stepping through the common use cases
(e.g. developer finds a bug they want to fix, contributor wants to fix a
bug, developer/PMC wants to make a release) and how issues should be
created/tagged/modified in each scenario.
IMO, GH issues created a black hole where anyone could create issues and
they could just get "lost" if not assigned to a milestone and properly
moved between them. Should PRs always have issues or is a PR sufficient
for inclusion in a release?
All that said, this was a number of years ago and perhaps the
project/release management on the Github side is more structured than
before. A little bit of documentation will go a very long way in making
sure that such a fundamental change in process does not cause a
significant burden.
I'm a little confused in your original message, you have two questions.
Are you suggesting that Calcite would use both Jira and Github issues?
On 11/28/21 11:43 AM, Vladimir Sitnikov wrote:
Hi,
What do you think of moving to GitHub Issues for Calcite?
Currently, my (Calcite) development workflow focuses on pull requests.
That is all contributions I see come via pull requests.
At the same time, issues are hosted in JIRA, which creates friction: PR
merging requires changes to both GitHub and JIRA.
I guess it would be easier if issue management was in GitHub as well.
Then, I believe, co-locating issues and PRs would make external
contributions easier.
The links between Issues and PRs would be easier to navigate.
There's a possibility to enable GitHub discussions as well (see
https://github.com/apache/airflow/discussions ).
Co-locating Issues, and Discussions look promising.
I think it is not that painful, however, GitHub has a limitation of 20
collaborators (non-committers who want to assign, edit, close issues, and
pull requests):
https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-AssigningexternalcollaboratorswiththetriageroleonGitHub
I have no strong opinion, however, I just realized having issues in GitHub
would ease friction.
Any thoughts?
Just to gather opinion:
-1..+1 keep using ASF JIRA for issue management
-1..+1 migrate to GitHub Issues
Here's my vote:
+0.5 keep using ASF JIRA for issue management. It more-or-less works,
however, merging PRs and navigating from PR to issue is far from perfect.
+1 migrate to GitHub Issues. It would simplify navigation between issues
and PRs, and I believe it would reduce friction for external contributors.
In theory, GitHub Issues can be automated with Actions (e.g. labels). I'm
not sure if we need that, however, it might be useful.
Vladimir
