> > This is interesting. Given that most Spark JIRA tickets have no > discussion, I'm wondering what's the point to enforce that every PR (except > for minor ones) needs to link to a JIRA ticket. How do other Apache > projects deal with PRs? @Szehon-Ho How does Iceberg compose release notes > if most PRs do not link to issues/JIRAs?
As the Iceberg release is done via github ( https://iceberg.apache.org/how-to-release/#finishing-the-release), the release notes are generated automatically (and can be manually edited, for example to group by component). Attaching a screenshot, I just selected a release tag and 'Generate release notes' to give an idea. Thanks, Szehon [image: Screenshot 2026-01-30 at 12.04.10 PM.png] On Fri, Jan 30, 2026 at 11:58 AM Tian Gao via dev <[email protected]> wrote: > > At the time of writing, it contains only one issue, created about six > months ago (2025-08-22), even though there is no ASF JIRA requirement for > that repository. By contrast, the main Apache Spark repository—where JIRA > is required—consistently receives a large volume of contributions and issue > activity. This strongly suggests that there is no systemic barrier > preventing participation. > > I think this only strongly suggests that spark is much more active than > spark-connect-rust, a 28 star github project whose last commit was 4 months > ago. > > I'm definitely biased towards replacing JIRA with github issues - because > this is my proposal :) Of course also because everyone is subjective - > that's why we need discussion. > > Even though the requirement for a PR to link a JIRA ticket seems to have > no direct connection to this proposal, it's actually worth discussion > because if that requirement is lifted, we don't need to argue about > if/when/how to migrate. We can just open the github issue as an optional > discussion place. The new contributors can just make a PR without the > barrier to register JIRA. Actually, that would also be a very interesting > observation about whether github issues is favored to JIRA - when people > can do discussion on either. > > I believe a link to a JIRA ticket is helpful when there's detailed > information in it - especially a description of the problem. However it > seems like that's not the case anymore. I think the problem here is we > require both a JIRA ticket and a detailed PR description - and they serve > the same purpose. We want the commit history to be descriptive enough and > we want to keep a separate ticket to hold the same information. > > For CPython, an issue is required for a PR, but people don't need to write > a description in the PR. The commit message contains links to both issue > and PR, but not the very detailed information. I guess the downside is - if > github died in the future, the detailed description would be lost. > > I think the ideal way is to keep the detailed information in the ticket > (JIRA or issue), because there could be multiple PRs targeting the same > issue. (also revert/followup stuff). The conflict here is that we want to > have a platform-free description in our git commit history. For this > specific matter, I don't think migrating to github issues will solve it. > > However, I do think it's much more user friendly to write the description > in github PRs than JIRA. Maybe I just like MD. > > In the meantime, I'm glad that we at least can reach a common ground to > open github issues - that will improve the feedback experience. I think > there will be pros and cons for all the options of if/when/how we build > infra to support github and migrate from JIRA, but github issues itself > should be beneficial. > > If we decide to only open the github issues for discussion, I don't think > it worth a SPIP - we can just do that. However, I'm still strongly > supporting the idea to migrate entirely from JIRA to github issues, sooner > or later. > > Tian Gao > > On Fri, Jan 30, 2026 at 10:30 AM Holden Karau <[email protected]> > wrote: > >> I will say helping a two new non-ASF people onboard to contributing to >> Spark the JIRA account creation did slow them down a bit which is probably >> ~fine since it was related to their jobs, but for folks who are trying to >> “scratch an itch” rather than doing it as part of their job it might be >> more of a barrier. >> >> Twitter: https://twitter.com/holdenkarau >> Fight Health Insurance: https://www.fighthealthinsurance.com/ >> <https://www.fighthealthinsurance.com/?q=hk_email> >> Books (Learning Spark, High Performance Spark, etc.): >> https://amzn.to/2MaRAG9 <https://amzn.to/2MaRAG9> >> YouTube Live Streams: https://www.youtube.com/user/holdenkarau >> Pronouns: she/her >> >> >> On Fri, Jan 30, 2026 at 7:27 PM Nicholas Chammas < >> [email protected]> wrote: >> >>> >>> > On Jan 30, 2026, at 9:27 AM, Szehon Ho <[email protected]> >>> wrote: >>> > >>> > In my experience, because I see few committers discussing anything >>> technical on Spark JIRA for years as you mentioned (and other Hadoop >>> project JIRAs too), I feel like nobody will reply if I do, so I will make a >>> Github PR directly and ping for feedback there. So in addition to the UX >>> problem Tian mentioned, it's worsened by cause and effect. So it's become >>> a procedure, and we still don't have a good place to discuss without >>> jumping to code. >>> >>> This has often been my experience as well. The eyes are mainly on GitHub >>> and not Jira. >>> >>> > On Jan 30, 2026, at 12:12 AM, Jungtaek Lim < >>> [email protected]> wrote: >>> > >>> > Why can't we do this in two phases instead of trying to build Rome in >>> a day? >>> >>> Speaking as an occasional contributor, I would expect this to be more >>> effort than it’s worth. A phased migration is appealing because it feels >>> safer and more gradual, but I think everyone will be better off in the long >>> run with a speedy and clear cutover from Jira to GitHub. The longer the >>> transitional phase lasts, the more confusing it will be to new and >>> occasional contributors who are not following the dev process’s evolution >>> closely. >>> >>> Nick >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe e-mail: [email protected] >>> >>>
