I have a few questions... 1) Can we know how many non-committers have PRs merged in the past few months? If it's a very small number, option D might still be practical since the committers don't get affected by the change (due to ASF SSO login) and very few new contributors will be required to create new accounts. 2) What is the kind of effort we are looking at with option "A"? What is the pitfall/additional effort to running the migration script for this option?
Both options (A or D) help us stay in a single world for issue-tracking, which would be my personal preference. As for barrier to entry, I agree that migrating to Github Issues helps new contributors to work with Solr through a single platform, but in my experience, when I started, I don't remember JIRA as being what held me back. It's the other aspects of preparing a PR and going through the checklist that generally takes more work. Once I had a JIRA account created, I never thought about the issue aspect of contribution. This is just *my* personal experience though. -Rahul On Fri, Jun 5, 2026 at 9:39 PM Jason Gerlowski <[email protected]> wrote: > +1 for "A". > > Hopefully this'd let us use Lucene's scripting with minimal changes. > (Though I could be wrong about that.) > > I agree that Github would help make us more approachable to new > potential contributors. But I don't love the split-world that "C" > would leave us in, where someone looking for tickets related to a > particular feature would need to look in both Github and JIRA. > > > I think this is ripe for a VOTE, but [...] > > Yeah, I do think it's going to be hard for us to hit a natural > consensus here. Maybe we just have a binding vote between A/B/C/D, > where the majority "wins"? Maybe I'm wrong, but I imagine most folks > would agree that picking *something* here is better than remaining > deadlocked. > > Best, > > Jason > > On Fri, May 29, 2026 at 2:38 PM David Smiley <[email protected]> wrote: > > > > +1 to C. It's low-effort / simple. And it lowers the bar for > > contributors: "meet new contributors where they are at" (not having a > JIRA > > account). > > > > I further recommend that we only lock new issue creation in JIRA, not > > comments or watching. > > > > The down-side to B or C is that Solr's issue legacy becomes split: some > in > > JIRA, some in GitHub. But neither system goes away, and both remain > > searchable. Perhaps the "issues" mail list archive could become the > single > > search source for issues originating from both platforms? Over time, the > > JIRA side will be less relevant, and eventually a GitHub-only search may > > suffice for some purposes. > > > > On Fri, May 29, 2026 at 9:57 AM Jan Høydahl <[email protected]> > wrote: > > > > > Hi all, > > > > > > This thread has been running since October 2022 (bumped in 2023 and > 2024 — > > > see below). A new development makes this urgent: Apache INFRA is > migrating > > > ASF JIRA to Atlassian Cloud, expected to complete around end of June. > > > > > > Key implications: > > > > > > JIRA URL redirects to the-asf.atlassian.net > > > Committers keep their ASF SSO login; external users will need a new > > > Atlassian account + ToS acceptance > > > Lucene's migration script targets the on-prem JIRA APIs — once the > cloud > > > migration is done, that script likely won't work. We need to decide > and act > > > before end of June. > > > The four options i proposed in my January 2024 mail (below) remains: > > > > > > A) Migrate all ~18,000 issues to GitHub, like Lucene did > > > B) Migrate only open/active issues; leave closed ones as a read-only > JIRA > > > archive > > > C) Fresh start on GitHub; drive remaining open JIRAs to closure within > ~3 > > > months, no migration needed > > > D) Stay on JIRA, now on Atlassian Cloud > > > I lean toward B or C. Option C is cleanest but requires aggressive > triage > > > to avoid prolonged dual issue tracker situation. Option B is feasible > if we > > > first reduce the 4,104 open issues to a manageable number (see separate > > > "JIRA housekeeping" thread). > > > > > > I think this is ripe for a VOTE, but not sure how to phrase a VOTE > thread > > > since there are strong opinions and folks arguing for all four > options. So > > > let this be an informal "Multiple-choice" poll to see if sentiment has > > > changed last few years. > > > > > > If I had to choose one right now I'd say C) > > > > > > Jan > > > > > > > > > > Fra: Jan Høydahl <[email protected]> > > > > Emne: Sv: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues > > > and Github Projects, and migrate mailing lists to Github Discussions > > > > Dato: 9. januar 2024 kl. 00:57:23 CET > > > > Til: [email protected] > > > > > > > Bringing attention to this thread again. > > > > > > > > Now that Lucene has some experience after the migration and with > using > > > Issues, labels etc, I'd like to discuss whether we'd want to copy the > > > Lucene approach or do something different. > > > > > > > > I'm not frequenting the Lucene issue tracker much, and am not either > > > aware of a formal evaluation of their issue migration. So appreciate > > > feedback from committers who have more exposure from Lucene. > > > > > > > > In my mind, we, Solr, have four options > > > > A) Migrate everything, like Lucene did > > > > B) Migrate only OPEN JIRA issues, refer to JIRA for ancient history > > > > C) Fresh-start empty GH issues, use JIRA as archive before yyyy-mm-dd > > > > D) Continue with g'old JIRA > > > > > > > > I was getting used to the thought of copying Lucene's approach, but > > > re-thinking now, I have once again shifted my preference towards C), a > > > fresh start. I'll summarize my reasons below with some numbers and > > > experience from Lucene's GH issues. Forgive my last rant on this > subject :) > > > > > > > > <rant> > > > > I'm a fan of NOT migrating the entire JIRA history to GH. Instead let > > > the R/O SOLR-JIRA be the system of record for historic issues forever. > I.e. > > > start a fresh, empty GH issue tracker for all NEW issues. The main > con, two > > > systems of record, can imo be mitigated with SearchEngineTechnoloty™. > > > Nothing is lost and the duplication of 16k issues in two systems is > more > > > confusing imo. We could time-box the overlap period where both systems > are > > > writable to, say 3 months, and at the end of that period, CLOSE all > > > still-open JIRA issues with a label and a suitable message. > > > > > > > > My arguments for this approach: 1) Solr has 16993 JIRA issues! 2) > There > > > are 4030 OPEN issues, of which 3681 has not been touched for a year! > Why > > > would we want 3681 OPEN & stale GitHub issues? Instead I'd like to use > > > StaleBot to tag stale issues+PRs and auto close+tag if still stale for > N > > > days. This is a much-used, proven approach. 3) The Lucene migration > caused > > > a whopping 642 issue/PR labels < > > > https://github.com/apache/lucene/issues/labels>, impossible to browse > > > manually. Most labels are trying to record legacy JIRA fields. I > checked > > > e.g. the "affects-version" < > > > https://github.com/apache/lucene/labels?q=affects-version:9>, label in > > > Lucene. New labels have not been maintained for recent releases > (8.11.2, > > > 9.4..9), and those labels are ~NEVER even used when people create new > GH > > > issues, so why even bother? Same for Priority etc. > > > > </rant> > > > > > > > > Let the discussion continue... > > > > > > > > Jan > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
