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 > 3. nov. 2023 kl. 12:33 skrev Jan Høydahl <jan....@cominvent.com>: > > Bringing this to our attention again. Lucene seems to have survived well > after the migration to Github issues. They have established a way to work > with milestones (https://github.com/apache/lucene/milestones) and labels > (https://github.com/apache/lucene/labels?q=type), and they have updated > release-wizard with corresponding steps. > > So are we ready to follow their lead? > > Jan > >> 18. okt. 2022 kl. 12:58 skrev Jan Høydahl <jan....@cominvent.com>: >> >> +1 from me too. >> >> I'm still not sold on bringing all history from JIRA into GH but that's what >> Lucene did, so perhaps just doing the same (+ lessons learnt) is the >> smoothest path. >> Solr would in addition need to find a new process for security issues. But >> we could just fall back on plain security@solr mailing list until a new >> solution is ready. >> >> Jan >> >>> 17. okt. 2022 kl. 16:20 skrev David Smiley <dsmi...@apache.org>: >>> >>> +1 to migrate. >>> >>> Yeah. Maybe Tomoko could validate the steps required? (CC'ed) Jeb listed >>> them in JIRA; the steps/mechanics can be discussed there while we leave >>> this thread as voting on the major decision. >>> >>> ~ David Smiley >>> Apache Lucene/Solr Search Developer >>> http://www.linkedin.com/in/davidwsmiley >>> >>> >>> On Mon, Oct 17, 2022 at 10:12 AM Houston Putman <hous...@apache.org> wrote: >>> >>>> I'm a big +1 on this idea, just like I was for Lucene's migration. >>>> >>>> Also I think that we could very much mooch off of the monumental amounts of >>>> hard work that Tomoko and Mike did for Lucene. >>>> >>>> There would certainly still be manual work, and changes to their script >>>> needed, but I don't think it would be as back-breaking of a task. >>>> >>>> - Houston >>>> >>>> On Fri, Oct 14, 2022 at 1:07 AM Noble Paul <noble.p...@gmail.com> wrote: >>>> >>>>> I agree that JIRA is one extra step that is not adding a lot of value. >>>>> Github issues are definitely better >>>>> >>>>> On Fri, Oct 14, 2022 at 3:04 PM David Smiley <dsmi...@apache.org> wrote: >>>>> >>>>>> Sharing for visibility. >>>>>> >>>>>> ~ David Smiley >>>>>> Apache Lucene/Solr Search Developer >>>>>> http://www.linkedin.com/in/davidwsmiley >>>>>> >>>>>> >>>>>> ---------- Forwarded message --------- >>>>>> From: Jeb Nix (Jira) <j...@apache.org> >>>>>> Date: Mon, Oct 10, 2022 at 7:11 PM >>>>>> Subject: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues >>>> and >>>>>> Github Projects, and migrate mailing lists to Github Discussions >>>>>> To: <iss...@solr.apache.org> >>>>>> >>>>>> >>>>>> Jeb Nix created SOLR-16455: >>>>>> ------------------------------ >>>>>> >>>>>> Summary: Migrate Jira to Github Issues and Github >>>> Projects, >>>>>> and migrate mailing lists to Github Discussions >>>>>> Key: SOLR-16455 >>>>>> URL: https://issues.apache.org/jira/browse/SOLR-16455 >>>>>> Project: Solr >>>>>> Issue Type: Wish >>>>>> Security Level: Public (Default Security Level. Issues are >>>> Public) >>>>>> Components: github >>>>>> Reporter: Jeb Nix >>>>>> >>>>>> >>>>>> GitHub is where people are at when they lookup for Solr (or basically >>>> any >>>>>> project). Most of the modern projects that have been started with Jira >>>>> and >>>>>> mailing lists have migrated to Github in the last few years. Lucene did >>>>>> that just now for the Issues which has allowed me to explore much more >>>> of >>>>>> their issues. GitHub works great and many think that it works even >>>> better >>>>>> (I think that there is no doubt that it is working better for the >>>>>> Discussions vs. Mailing lists). >>>>>> >>>>>> I suggest here a pretty heavy move, that personally will allow me to >>>>> start >>>>>> anticipating within Solr's community (since I really don't like the >>>>> mailing >>>>>> lists nor Jira), and I think that there are much more like me out >>>> there. >>>>> In >>>>>> my opinion, when the issues are managed on Github, it is much simpler >>>> to >>>>>> collaborate and they will get wider exposure since developers are >>>>> spending >>>>>> time on Github anyway (whether if it's for their projects or for >>>> looking >>>>> at >>>>>> the actual source code). It is also important to mention that it is >>>>> pretty >>>>>> cumbersome for a new contributor that wants to add stuff to Solr, to >>>> talk >>>>>> about this via mail, then translate them to Jira of the issues, and >>>> just >>>>>> after that submit a PR on Github. e.g. 3 different systems for each >>>>>> process. >>>>>> >>>>>> Actually, I thought such a great move (for me at least) would never >>>>> happen >>>>>> in Solr in the next years since I didn't think that the community sees >>>> & >>>>>> understands the many advantages yet. But now that the Lucene guys did >>>>> this, >>>>>> I believe that it is possible for Solr too. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> This message was sent by Atlassian Jira >>>>>> (v8.20.10#820010) >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org >>>>>> For additional commands, e-mail: issues-h...@solr.apache.org >>>>>> >>>>> >>>>> >>>>> -- >>>>> ----------------------------------------------------- >>>>> Noble Paul >>>>> >>>> >> >
