Hi all, thanks for raising this! I am in favour of: B) Migrate only OPEN JIRA issues, refer to JIRA for ancient history
But rather than just OPEN, I would probably migrate only the active ones? I agree it doesn't make sense to duplicate thousands of Jiras. I would also be ok with C, mine is just a preference not a veto at all. Cheers -------------------------- *Alessandro Benedetti* Director @ Sease Ltd. *Apache Lucene/Solr Committer* *Apache Solr PMC Member* e-mail: a.benede...@sease.io *Sease* - Information Retrieval Applied Consulting | Training | Open Source Website: Sease.io <http://sease.io/> LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter <https://twitter.com/seaseltd> | Youtube <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github <https://github.com/seaseltd> On Mon, 8 Jan 2024 at 23:57, Jan Høydahl <jan....@cominvent.com> wrote: > 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 > >>>>> > >>>> > >> > > > >
