+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]
