You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Jan Høydahl <ja...@cominvent.com> on 2023/11/03 11:33:59 UTC
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
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 <ja...@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 <ds...@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 <ho...@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 <no...@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 <ds...@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) <ji...@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: <is...@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-unsubscribe@solr.apache.org
>>>>> For additional commands, e-mail: issues-help@solr.apache.org
>>>>>
>>>>
>>>>
>>>> --
>>>> -----------------------------------------------------
>>>> Noble Paul
>>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
Posted by Jason Gerlowski <ge...@gmail.com>.
Still thinking through Jan's question; haven't made up my mind on a
preference (A, B, C, D, etc.) yet. But had a few questions/reactions,
inline.
> 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.
To ask what might be a naive question: what's the problem with having many
"open but stale" issues, and what does auto-closing things get us? I know
it's commonly done, but I've never quite understood why. Folks looking to
filter by "active" issues can use the "updated" field that both JIRA and
Github provide, so presumably there must be some other benefit?
> 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?).
I think this was implicit in Alessandro's message, but to add my 2c more
explicitly: I think this can be true regardless of the system for recording
PRs or Issues. The duplication is a bit more obvious when both are in
Github, but it's going to be there in any setup (including our current one)
where issue-reports and code-contributions are separate things.
Best,
Jason
On Wed, Jan 10, 2024 at 5:44 AM Alessandro Benedetti <a....@sease.io>
wrote:
> 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.benedetti@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....@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.benedetti@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 <ja...@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 <ja...@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 <ja...@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 <ds...@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 <houston@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 <no...@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 <ds...@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) <ji...@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: <is...@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-unsubscribe@solr.apache.org
> >> >>>>>> For additional commands, e-mail: issues-help@solr.apache.org
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> -----------------------------------------------------
> >> >>>>> Noble Paul
> >> >>>>>
> >> >>>>
> >> >>
> >> >
> >>
> >>
>
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
Posted by Alessandro Benedetti <a....@sease.io>.
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.benedetti@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....@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.benedetti@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 <ja...@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 <ja...@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 <ja...@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 <ds...@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 <ho...@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 <no...@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 <ds...@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) <ji...@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: <is...@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-unsubscribe@solr.apache.org
>> >>>>>> For additional commands, e-mail: issues-help@solr.apache.org
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> -----------------------------------------------------
>> >>>>> Noble Paul
>> >>>>>
>> >>>>
>> >>
>> >
>>
>>
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
Posted by Alessandro Benedetti <a....@sease.io>.
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.benedetti@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 <ja...@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 <ja...@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 <ja...@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 <ds...@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 <ho...@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 <no...@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 <ds...@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) <ji...@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: <is...@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-unsubscribe@solr.apache.org
> >>>>>> For additional commands, e-mail: issues-help@solr.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> -----------------------------------------------------
> >>>>> Noble Paul
> >>>>>
> >>>>
> >>
> >
>
>
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
Posted by David Smiley <ds...@apache.org>.
I found the correct thread, let's discuss there not here.
"Do we require Jira's for bug fixes?" March 2nd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
Posted by David Smiley <ds...@apache.org>.
I can't seem to find the conversation I was thinking of but this one
is close enough.
Can we have more clarity on when a JIRA issue is mandatory? Or the
reverse -- give clarity that small bugs don't need a JIRA issue. My
goal is to remove/reduce barriers for contributors as much as
possible.
I'd like to give a specific example of a simple & obscure NPE in
QueryComponent related to exception handling:
https://issues.apache.org/jira/browse/SOLR-17209
https://github.com/apache/solr/pull/2354
Yes I was the one who asked for a JIRA to be created but I felt bad
doing so (for something so trivial) and was only doing it because I
recall one of us recently saying/suggesting all bugs need a JIRA.
~ David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
Posted by Rahul Goswami <ra...@gmail.com>.
I have a few questions...
1) Can we know how many non-committers have PRs merged in the past few
months? If it's a very small number, option D might still be practical
since the committers don't get affected by the change (due to ASF SSO
login) and very few new contributors will be required to create new
accounts.
2) What is the kind of effort we are looking at with option "A"? What is
the pitfall/additional effort to running the migration script for this
option?
Both options (A or D) help us stay in a single world for issue-tracking,
which would be my personal preference. As for barrier to entry, I agree
that migrating to Github Issues helps new contributors to work with Solr
through a single platform, but in my experience, when I started, I don't
remember JIRA as being what held me back. It's the other aspects of
preparing a PR and going through the checklist that generally takes more
work. Once I had a JIRA account created, I never thought about the issue
aspect of contribution. This is just *my* personal experience though.
-Rahul
On Fri, Jun 5, 2026 at 9:39 PM Jason Gerlowski <ge...@gmail.com>
wrote:
> +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 <ds...@apache.org> 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 <ja...@cominvent.com>
> 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 <ja...@cominvent.com>
> > > > 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: dev@solr.apache.org
> > >
> > > > 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: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
Posted by Jason Gerlowski <ge...@gmail.com>.
+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 <ds...@apache.org> 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 <ja...@cominvent.com> 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 <ja...@cominvent.com>
> > > 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: dev@solr.apache.org
> >
> > > 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: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
Posted by David Smiley <ds...@apache.org>.
+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 <ja...@cominvent.com> 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 <ja...@cominvent.com>
> > 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: dev@solr.apache.org
>
> > 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
>
>
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <ja...@cominvent.com>
> 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: dev@solr.apache.org
> 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
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
Posted by Chris Hostetter <ho...@fucit.org>.
: In my mind, we, Solr, have four options
: D) Continue with g'old JIRA
My vote is (still) for D ... I don't see that changing unless/until Apache
starts self-hosting GitHub Enterprise, and elimiantes the need for people
to accept the github.com ToS (and Country restrictions).
Even then... in my experience the feature set of github issues I use
(advanced search, detailed history, linking, subtasks, attachments,
etc...) are vastly inferior to Jira.
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <ja...@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 <ja...@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 <ds...@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 <ho...@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 <no...@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 <ds...@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) <ji...@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: <is...@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-unsubscribe@solr.apache.org
>>>>>> For additional commands, e-mail: issues-help@solr.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -----------------------------------------------------
>>>>> Noble Paul
>>>>>
>>>>
>>
>