Another thing that always bugged me with the Lucene approach is the dualism issue/PR.
If I don't have a solution for an issue, it makes complete sense to write the Github Issue and later on a Pull Request may or may not happen. But if I have a PR (or at least a draft) ready, to me creating the Github issue is a redundant (and annoying) copy and paste. Also, I am then confused about where to discuss and comments (the issue or the PR?). Effectively nowadays Github PRs have plenty of description, discussion and review capabilities so in case it's a bug-fix or a well-established code direction, does it make sense to have the associated issue? I understand that ideally, you would like to have an issue first, discuss it with other committers and then start the implementation, but being honest I realised over the years that this makes contributing a full-time job and most of us(who are not lucky enough to be paid to contribute) can't (and shouldn't) commit to that. So to me, it happens all the time I go deep with a bug fix or new feature, open the PR and then open the Jira issue. Could we possibly go with Solr in a direction where there's always at least one PR for an issue, but not necessarily an issue for a PR? Just food for thought based on my experience, 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 Wed, 10 Jan 2024 at 10:26, Alessandro Benedetti <a.benede...@sease.io> wrote: > 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 >> >>>>> >> >>>> >> >> >> > >> >>
