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
