Re: [DISCUSS] Community Virtual Meetup, January 2024

[Jason Gerlowski]

Awesome, thanks for volunteering Raghavan!

Anyone have thoughts on scheduling?  Absent other strong opinions, maybe we
could aim for the week of Monday the 15th through Friday the 19th and pick
a day/time in that range?

Best,

Jason

On Sun, Jan 7, 2024 at 1:27 AM raghavan m  wrote:

> Happy New Year everyone. I can volunteer for January.
>
> Sent from iPhone
>
>
> On Tue, Jan 2, 2024 at 7:49 AM Jason Gerlowski 
> wrote:
>
> > Hey all,
> >
> > After missing December, It's time once again to start thinking ahead to
> our
> > first Virtual Meetup in the New Year!  As always, there's two main
> > questions to answer in terms of planning:
> >
> > 1. Any volunteers to organize?  Organizer duties are pretty light and are
> > summarized here:
> > https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes.
> > Volunteers
> > get some discretion in terms of picking a meeting time/day that works for
> > them.  If there are no volunteers by the end of the week, I'm more than
> > happy to set things up for this month.
> >
> > 2. When should we meet?  I've started the discussion early this month, so
> > we've got plenty of days to choose from.  If you have any opinions,
> please
> > discuss.
> >
> > Best,
> >
> > Jason
> >
>

Re: Nifi error after Solrj Upgrade

[Jan Høydahl]

Check the class path of your application, whether it already has a dependency 
on Jetty. If so, you need to pick one version so you don’t get multiple 
versions of jetty on the class path.

If you use maven you can run “mvn dependency:tree” or similar to see them all.

Jan Høydahl

> 8. jan. 2024 kl. 01:14 skrev Subhasis Patra 
> :
> 
> Hi Everyone,
> 
> Appreciate any help on following.
> 
> I am using nifi-1.23.2 and Solr version is 9.2.0.
> In my nifi processor I have logic to create Solr client. It was working as 
> expected till Solrj8.11.2. Last week I upgraded my Solrj to 9.4.0. After that 
> I started getting following error while creating Solr client in my nifi 
> processor.
> 
> java.lang.IncompatibleClassChangeError: class 
> org.eclipse.jetty.http.HttpFields$Mutable can not implement 
> org.eclipse.jetty.http.HttpFields, because it is not an interface 
> (org.eclipse.jetty.http.HttpFields is in unnamed module of loader 
> org.apache.nifi.nar.NarClassLoader @4a8df3e2)
>at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>at 
> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
>at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>at 
> java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524)
>at 
> java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427)
>at 
> java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421)
>at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
>at 
> java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420)
>at 
> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
>at 
> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
>at 
> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.(Http2SolrClient.java:1066)
>at 
> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient.(CloudHttp2SolrClient.java:61)
>at 
> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient$Builder.build(CloudHttp2SolrClient.java:429)
> 
> I am using following method to create solr Client.
> 
> CloudSolrClient.Builder(urlList, 
> Optional.empty()).withZkConnectTimeout(1, TimeUnit.MILLISECONDS)
> .withZkClientTimeout(6, 
> TimeUnit.MILLISECONDS).build()
> 
> Thanks
> Subhasis Patra
> 240-755-2601
> subhasis.pa...@e2open.com
> 

-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

RE: Nifi error after Solrj Upgrade

[Subhasis Patra]

Thank you for your response.
We don’t have any issue when Solrj is part of other services. The issue is 
specific to nifi. Is nifi using some different version of jetty that is 
conflicting with the jetty Solrj is using?
I don’t have any jetty in my pom, the jeety jars are getting pulled as part of 
Solrj or nifi.

Thanks
Subhasis Patra
240-755-2601
subhasis.pa...@e2open.com

From: Jan Høydahl 
Sent: Monday, January 8, 2024 8:41 AM
To: dev@solr.apache.org
Subject: Re: Nifi error after Solrj Upgrade

PHISH ALERT! CHECK VALIDITY IF CLICKING, SHARING, RESPONDING

Check the class path of your application, whether it already has a dependency 
on Jetty. If so, you need to pick one version so you don’t get multiple 
versions of jetty on the class path.

If you use maven you can run “mvn dependency:tree” or similar to see them all.

Jan Høydahl

> 8. jan. 2024 kl. 01:14 skrev Subhasis Patra 
> mailto:subhasis.pa...@e2open.com.invalid>>:
>
> Hi Everyone,
>
> Appreciate any help on following.
>
> I am using nifi-1.23.2 and Solr version is 9.2.0.
> In my nifi processor I have logic to create Solr client. It was working as 
> expected till Solrj8.11.2. Last week I upgraded my Solrj to 9.4.0. After that 
> I started getting following error while creating Solr client in my nifi 
> processor.
>
> java.lang.IncompatibleClassChangeError: class 
> org.eclipse.jetty.http.HttpFields$Mutable can not implement 
> org.eclipse.jetty.http.HttpFields, because it is not an interface 
> (org.eclipse.jetty.http.HttpFields is in unnamed module of loader 
> org.apache.nifi.nar.NarClassLoader @4a8df3e2)
> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
> at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
> at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524)
> at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427)
> at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421)
> at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
> at 
> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.(http://Http2SolrClient.java:1066)
> at 
> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient.(http://CloudHttp2SolrClient.java:61)
> at 
> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient$Builder.build(CloudHttp2SolrClient.java:429)
>
> I am using following method to create solr Client.
>
> CloudSolrClient.Builder(urlList, 
> Optional.empty()).withZkConnectTimeout(1, TimeUnit.MILLISECONDS)
> .withZkClientTimeout(6, TimeUnit.MILLISECONDS).build()
>
> Thanks
> Subhasis Patra
> 240-755-2601
> subhasis.pa...@e2open.com>
>

-
To unsubscribe, e-mail: 
dev-unsubscr...@solr.apache.org
For additional commands, e-mail: 
dev-h...@solr.apache.org

Re: updateLog tlog directory config silently ignored (SOLR-16962)

[Michael Gibney]

Any further thoughts on this?

I'd like to proceed with the PR for SOLR-16962 [1], which I've updated
with a fix to address now-once-again-relevant SOLR-6537 [2] (at
whatever point SOLR-16962 made it impossible to configure an external
tlog, SOLR-6537 (cleanup/deletion of external tlog) became practically
not relevant).

[1] https://issues.apache.org/jira/browse/SOLR-16962
[2] https://issues.apache.org/jira/browse/SOLR-6537

On Mon, Sep 11, 2023 at 12:36 PM Michael Gibney
 wrote:
>
> > useful to separate the location to use some fast local SSDs vs slower but 
> > larger storage for the main index
>
> Exactly.
>
> And yes, the duplicity of nomenclature is a large part of what I'm
> suggesting to deal with here ... it's very confusing. But having
> recently been pretty deep in this part of the current code, it looks
> very much like "ulogDir" refers to the _parent_ directory of the tlog
> dir -- i.e., `[instanceDir]/data/`, which is just weird IMO ... so I
> guess I was also thinking of consistency, but hoping to break more in
> the direction of using "tlogDir", since "ulogDir" currently
> (confusingly) seems to mean `[instanceDir]/data/`.
>
> My current understanding of the situation: as far as the filesystem is
> concerned, updateLog/ulog/solr.ulog.dir/etc. has no significance other
> than as the parent of the tlogDir -- and as the parent, it also
> happens to be the same dir as the default dataDir -- i.e., the parent
> of the `index` dir, etc... so in fact there's nothing at all uniquely
> "ulog" about the "ulogDir".
>
> Michael
>
> On Mon, Sep 11, 2023 at 12:24 PM David Smiley  
> wrote:
> >
> > FWIW I've never heard of anyone customizing that.  I suppose it might be
> > useful to separate the location to use some fast local SSDs vs slower but
> > larger storage for the main index?
> >
> > I've noticed an annoying duplicity in nomenclature here -- is it the Update
> > Log or the Transaction Log?  And furthermore, we have a TLOG replica type.
> > In our configuration, the nomenclature is "update log" or "ulog".  If we
> > add a new setting, let's at least be consistent and call the new proposed
> > dir "ulogDir".
> >
> > ~ David
> >
> >
> > On Mon, Sep 11, 2023 at 9:45 AM Michael Gibney 
> > wrote:
> >
> > > Thanks Ilan, this seems good. In addition to addressing practical
> > > concerns, this could also be an opportunity to clarify the semantics
> > > around updateLog/tlog configuration:
> > >
> > > In looking closely at this code, my understanding is that the
> > > `${solr.ulog.dir:}`
> > > setting in solrconfig.xml currently defines the _parent_ directory
> > > that contains the tlog dir. Except that afaict, the tlog dir is the
> > > _only_ path that's actually relevant. In fact, the portion of the
> > > refguide that mentions this is called "Transaction Log Configuration"
> > > [1].
> > >
> > > This muddles the intent of this setting; it would be much clearer if,
> > > rather than a "dir" property (defaulting to `[instanceDir]/data/`)
> > > defining the _parent_ directory of the tlog dir, we simply had a
> > > "tlogDir" property (defaulting to `[instanceDir]/data/tlog/`) that
> > > directly defines the tlog dir. The semantics of this could then be
> > > clarified to indicate that:
> > > 1. if tlogDir is relative, it is resolved relative to core
> > > instanceDir, and must resolve to a descendent dir of instanceDir
> > > (i.e., cannot "escape" via ../../../).
> > > 2. if tlogDir (whether absolute or relative) resolves to a descendant
> > > of instanceDir, it is already implicitly namespaced by core, and the
> > > property defines the tlog dir directly.
> > > 3. if tlogDir is absolute and resolves to a directory _outside_ of the
> > > core instanceDir, it is _not_ implicitly namespaced by core, and the
> > > property therefore defines a parent directory, within which a
> > > core-namespaced tlog dir will be created (for a final tlog file path
> > > of, e.g., `[tlogDir]/[core_name]/tlog.0001`)
> > >
> > > As it stands currently, the above three cases are already ambiguous;
> > > the proposed bugfix PR [2] necessarily resolves this ambiguity, but
> > > even so, the semantics of the "dir" property map poorly onto what
> > > actually needs to be configured.
> > >
> > > Does this make sense, and/or am I missing something?
> > >
> > > Michael
> > >
> > > [1]
> > > https://solr.apache.org/guide/solr/latest/configuration-guide/commits-transaction-logs.html#transaction-log-configuration
> > > [2] https://github.com/apache/solr/pull/1895
> > >
> > > On Fri, Sep 8, 2023 at 4:59 PM Ilan Ginzburg  wrote:
> > > >
> > > > Re backcompat issue: might be an option to fix that config but use a
> > > > different name for it then, so that any currently existing (and ignored)
> > > > config continues to be ignored.
> > > >
> > > > Ilan
> > > >
> > > > On Thu, Sep 7, 2023, 6:14 PM Michael Gibney 
> > > > wrote:
> > > >
> > > > > I'd like to call some extra attention to SOLR-16962 [1]. I'm fairly
> > > > > certain 

Re: Nifi error after Solrj Upgrade

[Jan Høydahl]

This is really a discussion for the users@ list, but you have to check all your 
transivite dependencies for conflicts.
Here is a helpful article: 
https://www.javaadvent.com/2020/12/how-to-debug-dependency-conflicts-in-maven-and-gradle.html

Jan

> 8. jan. 2024 kl. 18:08 skrev Subhasis Patra 
> :
> 
> Thank you for your response.
> We don’t have any issue when Solrj is part of other services. The issue is 
> specific to nifi. Is nifi using some different version of jetty that is 
> conflicting with the jetty Solrj is using?
> I don’t have any jetty in my pom, the jeety jars are getting pulled as part 
> of Solrj or nifi.
> 
> Thanks
> Subhasis Patra
> 240-755-2601
> subhasis.pa...@e2open.com
> 
> From: Jan Høydahl 
> Sent: Monday, January 8, 2024 8:41 AM
> To: dev@solr.apache.org
> Subject: Re: Nifi error after Solrj Upgrade
> 
> PHISH ALERT! CHECK VALIDITY IF CLICKING, SHARING, RESPONDING
> 
> Check the class path of your application, whether it already has a dependency 
> on Jetty. If so, you need to pick one version so you don’t get multiple 
> versions of jetty on the class path.
> 
> If you use maven you can run “mvn dependency:tree” or similar to see them all.
> 
> Jan Høydahl
> 
>> 8. jan. 2024 kl. 01:14 skrev Subhasis Patra 
>> mailto:subhasis.pa...@e2open.com.invalid>>:
>> 
>> Hi Everyone,
>> 
>> Appreciate any help on following.
>> 
>> I am using nifi-1.23.2 and Solr version is 9.2.0.
>> In my nifi processor I have logic to create Solr client. It was working as 
>> expected till Solrj8.11.2. Last week I upgraded my Solrj to 9.4.0. After 
>> that I started getting following error while creating Solr client in my nifi 
>> processor.
>> 
>> java.lang.IncompatibleClassChangeError: class 
>> org.eclipse.jetty.http.HttpFields$Mutable can not implement 
>> org.eclipse.jetty.http.HttpFields, because it is not an interface 
>> (org.eclipse.jetty.http.HttpFields is in unnamed module of loader 
>> org.apache.nifi.nar.NarClassLoader @4a8df3e2)
>> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
>> at 
>> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>> at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524)
>> at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427)
>> at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421)
>> at 
>> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
>> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
>> at 
>> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.(http://Http2SolrClient.java:1066)
>> at 
>> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient.(http://CloudHttp2SolrClient.java:61)
>> at 
>> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient$Builder.build(CloudHttp2SolrClient.java:429)
>> 
>> I am using following method to create solr Client.
>> 
>> CloudSolrClient.Builder(urlList, 
>> Optional.empty()).withZkConnectTimeout(1, TimeUnit.MILLISECONDS)
>> .withZkClientTimeout(6, TimeUnit.MILLISECONDS).build()
>> 
>> Thanks
>> Subhasis Patra
>> 240-755-2601
>> subhasis.pa...@e2open.com>
>> 
> 
> -
> To unsubscribe, e-mail: 
> dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: 
> dev-h...@solr.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: PR labeling

[Jan Høydahl]

Hi,

Got some initial (positive) feedback on the auto-categorization PR and plan to 
merge on Thursday, giving you some more time to review. I feel I have not 100% 
nailed perfect labels. Obviously we can't auto label things like feature/bug, 
or versions, so this is only a "category". Ideally there would be a a 1:1 
between these "category" labels and the "Components" defined in JIRA. But here 
are 96 different "Components" there, most of them are old/irrelevant and not 
always very good IMO. So I'd rather attempt to align JIRA components with 
whatever we come up with here...

Lucene has just put their StaleBot to work, and I created 
https://github.com/apache/solr/pull/2184 to do the same for Solr. Have a look.

Jan

> 6. jan. 2024 kl. 01:21 skrev Jan Høydahl :
> 
> Hi,
> 
> We tend to not use the GitHub's PR labels we have defined.
> So I whipped up https://github.com/apache/solr/pull/2180 which is configured 
> to auto-label PRs based on what files are changed. Feedback welcome.
> 
> Also, I hope we can implement StaleBot for labeling PRs as stale. Lucene is 
> going to test it, see https://github.com/apache/lucene/pull/12813. If that 
> goes well, let's copy their config :)
> 
> - Jan
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

RE: Nifi error after Solrj Upgrade

[Subhasis Patra]

Hi, I got the issue in Solrj upgrade.
Nifi 1.23.2 or 1.24.0 uses jetty-http 9.4.51 jar where as Solrj 9.4 needs 
jetty-http 10.17. It means Solrj 9.x is not compatible with nifi 1.24.0.
Nifi 2.0.0-M has 10,x version of jetty. But this uses java 21 and lot of 
methods are deprecated. So its not a straight forward change and problematic.

Thanks
Subhasis Patra
240-755-2601
subhasis.pa...@e2open.com

From: Jan Høydahl 
Sent: Monday, January 8, 2024 4:20 PM
To: dev@solr.apache.org
Subject: Re: Nifi error after Solrj Upgrade

PHISH ALERT! CHECK VALIDITY IF CLICKING, SHARING, RESPONDING

This is really a discussion for the users@ list, but you have to check all your 
transivite dependencies for conflicts.
Here is a helpful article: 
https://www.javaadvent.com/2020/12/how-to-debug-dependency-conflicts-in-maven-and-gradle.html

Jan

> 8. jan. 2024 kl. 18:08 skrev Subhasis Patra 
> mailto:subhasis.pa...@e2open.com.INVALID>>:
>
> Thank you for your response.
> We don’t have any issue when Solrj is part of other services. The issue is 
> specific to nifi. Is nifi using some different version of jetty that is 
> conflicting with the jetty Solrj is using?
> I don’t have any jetty in my pom, the jeety jars are getting pulled as part 
> of Solrj or nifi.
>
> Thanks
> Subhasis Patra
> 240-755-2601
> subhasis.pa...@e2open.com>
>
> From: Jan Høydahl mailto:jan@cominvent.com>>
> Sent: Monday, January 8, 2024 8:41 AM
> To: dev@solr.apache.org
> Subject: Re: Nifi error after Solrj Upgrade
>
> PHISH ALERT! CHECK VALIDITY IF CLICKING, SHARING, RESPONDING
>
> Check the class path of your application, whether it already has a dependency 
> on Jetty. If so, you need to pick one version so you don’t get multiple 
> versions of jetty on the class path.
>
> If you use maven you can run “mvn dependency:tree” or similar to see them all.
>
> Jan Høydahl
>
>> 8. jan. 2024 kl. 01:14 skrev Subhasis Patra 
>> mailto:subhasis.pa...@e2open.com.invalid>>:
>>
>> Hi Everyone,
>>
>> Appreciate any help on following.
>>
>> I am using nifi-1.23.2 and Solr version is 9.2.0.
>> In my nifi processor I have logic to create Solr client. It was working as 
>> expected till Solrj8.11.2. Last week I upgraded my Solrj to 9.4.0. After 
>> that I started getting following error while creating Solr client in my nifi 
>> processor.
>>
>> java.lang.IncompatibleClassChangeError: class 
>> org.eclipse.jetty.http.HttpFields$Mutable can not implement 
>> org.eclipse.jetty.http.HttpFields, because it is not an interface 
>> (org.eclipse.jetty.http.HttpFields is in unnamed module of loader 
>> org.apache.nifi.nar.NarClassLoader @4a8df3e2)
>> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
>> at 
>> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>> at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524)
>> at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427)
>> at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421)
>> at 
>> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
>> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
>> at 
>> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.(http://Http2SolrClient.java:1066>)
>> at 
>> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient.(http://CloudHttp2SolrClient.java:61>)
>> at 
>> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient$Builder.build(CloudHttp2SolrClient.java:429)
>>
>> I am using following method to create solr Client.
>>
>> CloudSolrClient.Builder(urlList, 
>> Optional.empty()).withZkConnectTimeout(1, TimeUnit.MILLISECONDS)
>> .withZkClientTimeout(6, TimeUnit.MILLISECONDS).build()
>>
>> Thanks
>> Subhasis Patra
>> 240-755-2601
>> subhasis.pa...@e2open.com>>
>>
>
> -
> To unsubscribe, e-mail: 
> dev-unsubscr...@solr.apache.org

Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions

[Jan Høydahl]

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 -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 :)


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 , impossible to 
browse manually. Most labels are trying to record legacy JIRA fields. I checked 
e.g. the "affects-version" 
, 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.


Let the discussion continue...

Jan


> 3. nov. 2023 kl. 12:33 skrev Jan Høydahl :
> 
> 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 :
>> 
>> +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 :
>>> 
>>> +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  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  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  wrote:
> 
>> Sharing for visibility.
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>> 
>> 
>> -- Forwarded message -
>> From: Jeb Nix (Jira) 
>> 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: 
>> 
>> 
>> Jeb Nix created SOLR-16455:
>> --
>> 
>>   Summa