I'm not sure if I understand the logic of using both at the same time (unless they are completely synchronized bidirectionally, which would require work too). It'd be super confusing to people that are not using these day to day to see both. Where should they be reporting bugs? Where should they search? If there are duplications, there's not even a structured way to link them.
Updating scripts etc seems relatively trivial in the age of LLM coding. On Thu, Jan 29, 2026 at 11:10 AM Tian Gao via dev <[email protected]> wrote: > First of all, I believe the merge script is another issue that is worth > discussing but not strictly involved in this proposal. I was talking about > potential future benefits for the merge script by migrating our work to > github. On this specific matter, like I said, a github bot would probably > be better than a manual script - we should be able to do whatever we do > with that. The good thing is we can just label the PR (auto-merge) (or a > specific comment like bot merge) and run the bot, instead of setting up a > local environment. > > Back to the real topic. I don't think we should keep two systems stamping > on each other in the long term. But we have a puzzle that we'll never solve > if we bind all PRs to JIRA - how many more contributors we will have if > it's easier for them to contribute code? I don't have a definitive answer > for that and that's what I want to find out. I think the existing > committers will benefit some from a successful migration, but the real > motivation is for people who are not familiar with JIRA or who can't/don't > want to use JIRA. If we can get a significant boost of our community > contribution, I'd say that's worth the trouble. I think many of us are > thinking about this from a committer's perspective (which is natural > obviously), but I was a new contributor 6 months ago and the first thing > that stopped me from contributing was the allowed-user-only JIRA. > > People may argue that almost all recent contributions are from committers > or regular contributors and they are already familiar with JIRA - that's > true, but isn't that also evidence that we should embrace the community a > bit more? > > I think if we support a dual-rail system - it should be an intermediate > phase where we observe if it's worth it for us to migrate to github issues. > If so, it gives us some time to build infra around github issues while > keeping the workflow going. > > Of course, it's possible that this is just some fantasy I have and we > don't get observably more new contributions from the community with github > issues, then we can just use it as a discussion board and feedback channel. > > Tian Gao > > On Thu, Jan 29, 2026 at 5:07 AM Jungtaek Lim <[email protected]> > wrote: > >> The only downside I can think of is future release notes will contain >>> mixed items from Github Issues and JIRAs. >> >> I'm not sure I think this is trivial. IMHO if we want to maintain two >> systems altogether, each system should serve its purpose and not interleave. >> >> For example, allowing Github issues to be an easy entry point for >> questions, making Github issues to serve the major purpose of users@ >> instead of drop-in replacement of JIRA. And for code contributions we still >> require JIRA tickets. This strictly scopes the purpose of both systems. >> >> It doesn't mean I prefer maintaining two systems; I mean let's not leave >> both systems to be active for the same purpose which will bug us in future. >> I don't have a strong opinion to pick one system over another, but I have >> an opinion that we shouldn't end up with compromise and make the infra >> to be a weird state. >> >> Btw I'm not sure Github's squeeze commit in the UI page is a drop-in >> replacement of the merge script e.g. the merge script handles the tricky >> authorship issue via listing up lead-author and co-authors based on the >> author of commits before squeezing. I don't know whether it's supported. >> >> >> On Thu, Jan 29, 2026 at 4:07 PM Wenchen Fan <[email protected]> wrote: >> >>> +1 to maintain both. Why not give contributors a new option with Github >>> Issues? All we need to do is to allow people to create PRs with link to >>> Github Issues, in addition to JIRAs. The only downside I can think of is >>> future release notes will contain mixed items from Github Issues and JIRAs. >>> >>> On Thu, Jan 29, 2026 at 7:22 AM Lisa N. Cao <[email protected]> >>> wrote: >>> >>>> >>>> It would make it easier for the community to see the progress of >>>> features, but there is some work involved to maintain both. >>>> >>>> -- >>>> LNC >>>> >>>> >>>> On Wed, Jan 28, 2026 at 3:10 PM Tian Gao via dev <[email protected]> >>>> wrote: >>>> >>>>> I'm okay with not retiring JIRA, but if we only allow PRs with JIRA >>>>> tickets, we still have the same issue - the new contributors can't work on >>>>> any problems without access to JIRA. >>>>> >>>>> Yes, opening issue tabs will help with community feedback, but I don't >>>>> think we get full benefit from it if we restrict it to be a "discussion >>>>> only" place. The community of spark is not only users, but also occasional >>>>> contributors. >>>>> >>>>> If we worry about the dramatic migration from JIRA, we can open github >>>>> issues, and start building infra around it, while keeping the old system >>>>> working. If we see a trend of committers using github issues more often, >>>>> that's an indicator that people like github integration more than the >>>>> existing JIRA system. >>>>> >>>>> Yes, migrating to github issues means we probably need to throw away a >>>>> bunch of scripts for JIRA, but some of them are not necessary in the first >>>>> place if we use github issues. For example, linking issues to PRs is a >>>>> native supported feature in github. Github supports "squash-only" merge so >>>>> people won't accidentally merge PRs with all the commit history. Github >>>>> also supports "using PR description as commit message". >>>>> >>>>> Even if we do want extra flexibility, github bots have the advantages >>>>> of authentication. For example, if I understand correctly, committers need >>>>> their JIRA token to make the current merge script work - that won't be >>>>> necessary if we use github. Github issues can be closed automatically when >>>>> a linked PR is merged (with close #number) or a github bot can easily do >>>>> that. >>>>> >>>>> Therefore, if we don't want to close JIRA, I'm totally fine with a >>>>> dual-rail system which allows users to submit a PR based on a github >>>>> issue, >>>>> instead of a JIRA ticket. We can do that gradually and polish up all the >>>>> infra required for github issues. Then we can make a decision whether to >>>>> migrate completely. >>>>> >>>>> Tian Gao >>>>> >>>>> On Wed, Jan 28, 2026 at 2:47 PM Dongjoon Hyun <[email protected]> >>>>> wrote: >>>>> >>>>>> -1 because I don't think we should move from the existing one (ASF >>>>>> JIRA) to a new one (GitHub Issues) completely to meet the suggested >>>>>> ideas. >>>>>> It sounds like a little overkill for the goals. They can be used more >>>>>> harmoniously. >>>>>> >>>>>> Specifically, I want to counter-propose a simpler alternative which >>>>>> is used already in some ASF projects: GitHub Issue Tab can be used as an >>>>>> additional preliminary discussion place (receiving issue reports before >>>>>> creating actual JIRA issues). Since this is open to all GitHub users, it >>>>>> already meets the proposed goals. And, there is no reason to abandon ASF >>>>>> JIRA because only worthy ideas will get JIRA IDs after closing duplicated >>>>>> issues or naive Spark questions from GitHub Issue tabs. >>>>>> >>>>>> We can build a better layered issue reporting system by getting all >>>>>> the benefits of the existing ASF JIRA infra and GitHub Issue Tab instead >>>>>> of >>>>>> wasting lots of the community resources due to the drastic migration (or >>>>>> abandoning the established system, script, practices). >>>>>> >>>>>> > I think we should move from JIRA to github issues for >>>>>> > * more feedback from community >>>>>> > * lower barrier to entry for new contributors >>>>>> > * better integration with the whole github eco-system >>>>>> >>>>>> Dongjoon. >>>>>> >>>>>> >>>>>> On 2026/01/27 14:57:00 Bjørn Jørgensen wrote: >>>>>> > Github use mentioned instead of related to >>>>>> > >>>>>> > Like this >>>>>> > [image: image.png] >>>>>> > https://github.com/apache/arrow/issues/48961 >>>>>> > >>>>>> > >>>>>> > tir. 27. jan. 2026 kl. 14:58 skrev Nicholas Chammas < >>>>>> > [email protected]>: >>>>>> > >>>>>> > > One thing GitHub Issues doesn’t have a native equivalent to are >>>>>> issue >>>>>> > > links. GitHub will extract mentions of other tickets and >>>>>> highlight them in >>>>>> > > the side bar, but on Jira you can just link a ticket to another >>>>>> one >>>>>> > > directly. >>>>>> > > >>>>>> > > Example: https://issues.apache.org/jira/browse/SPARK-28024 >>>>>> > > >>>>>> > > [image: Screenshot 2026-01-27 at 8.55.28 AM.png] >>>>>> > > >>>>>> > > Not saying this is a blocker. Just calling this out so we can try >>>>>> to >>>>>> > > preserve this information after the migration. >>>>>> > > >>>>>> > > Nick >>>>>> > > >>>>>> > > >>>>>> > > On Jan 26, 2026, at 8:00 PM, DB Tsai <[email protected]> wrote: >>>>>> > > >>>>>> > > +1, the bar for using JIRA is too high—contributors need a >>>>>> PMC/committer >>>>>> > > to create an account. Using GitHub issues would make it much >>>>>> easier for >>>>>> > > people to participate. >>>>>> > > DB Tsai | https://www.dbtsai.com/ | PGP 42E5B25A8F7A82C1 >>>>>> > > >>>>>> > > On Jan 26, 2026, at 2:30 PM, Hyukjin Kwon <[email protected]> >>>>>> wrote: >>>>>> > > >>>>>> > > TBH, if we can manage to migrate all related repos in Apache >>>>>> Spark, I feel >>>>>> > > like it might be a great idea. >>>>>> > > lately I started to actively work on Apache Arrow, and realised >>>>>> that they >>>>>> > > also successfully migrate to GitHub Issues from JIRA for all ther >>>>>> repos. >>>>>> > > >>>>>> > > On Tue, 27 Jan 2026 at 05:49, Tian Gao via dev < >>>>>> [email protected]> >>>>>> > > wrote: >>>>>> > > >>>>>> > >> Hi all, I'd like to start a discussion on a draft SPIP: >>>>>> > >> >>>>>> https://docs.google.com/document/d/1WMaA49hKyu7gtU189fPq4k8TeI-Q73Q6bqSeWAgR3y8/edit?usp=sharing >>>>>> > >> >>>>>> > >> tl; dr >>>>>> > >> >>>>>> > >> I think we should move from JIRA to github issues for >>>>>> > >> * more feedback from community >>>>>> > >> * lower barrier to entry for new contributors >>>>>> > >> * better integration with the whole github eco-system >>>>>> > >> >>>>>> > >> Many apache projects have moved from JIRA to github issues >>>>>> successfully, >>>>>> > >> including Arrow, Airflow, Beam, Maven, Lucene ... Actually most >>>>>> of apache >>>>>> > >> projects are using github issues now, with a few exceptions >>>>>> including spark. >>>>>> > >> >>>>>> > >> I'd like to hear more about this proposal from the community. >>>>>> > >> >>>>>> > >> Thanks! >>>>>> > >> >>>>>> > >> Tian Gao >>>>>> > >> >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > >>>>>> > -- >>>>>> > Bjørn Jørgensen >>>>>> > Vestre Aspehaug 4, 6010 Ålesund >>>>>> > Norge >>>>>> > >>>>>> > +47 480 94 297 >>>>>> > >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe e-mail: [email protected] >>>>>> >>>>>>
