date:20210920

Re: New branch and feature freeze for Lucene/Solr 8.10.0

2021-09-20 Thread Mike Drob

That was a bad backport from main, and I was mainly paying attention to the
main jenkins tests. Apologies about that oversight. Please see PR
https://github.com/apache/lucene-solr/pull/2578

On Mon, Sep 20, 2021 at 2:21 PM Uwe Schindler  wrote:

> Hi,
>
> This test also fails on Jenkins all the time. In all branches and on all
> platforms. All the time, it's definitely a regression.
>
> Uwe
>
> Am 20. September 2021 19:13:56 UTC schrieb Timothy Potter <
> thelabd...@gmail.com>:
>>
>> Started building the RC1 again today and the smoke tester failed. The
>> culprit was: org.apache.solr.search.TestFiltering.testRandomFiltering
>>
>> Re-ran that test from the RC checkout and it failed again:
>>
>>[junit4]   2> 5490 ERROR
>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
>> ] o.a.s.SolrTestCaseJ4 REQUEST FAILED:
>> facet.query=*:*={!key%3DmultiSelect+ex%3Dt}*:*={!key%3DfacetQuery+cache%3Dfalse}+val_i:2+val_i:4={!+cost%3D7+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D2+u%3D5}"=true=xml
>>[junit4]   2> 5491 INFO
>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
>> ] o.a.s.SolrTestCaseJ4 ###Ending testRandomFiltering
>>[junit4]   2> NOTE: reproduce with: ant test
>> -Dtestcase=TestFiltering -Dtests.method=testRandomFiltering
>> -Dtests.seed=9A85A1D74D8AACF9 -Dtests.slow=true -Dtests.badapples=true
>> -Dtests.locale=mgh -Dtests.timezone=Iceland -Dtests.asserts=true
>> -Dtests.file.encoding=US-ASCII
>>[junit4] FAILURE 0.82s | TestFiltering.testRandomFiltering <<<
>>[junit4]> Throwable #1: java.lang.AssertionError: should have 
>> unwrapped
>>[junit4]> at
>> __randomizedtesting.SeedInfo.seed([9A85A1D74D8AACF9:85E60212A8ADECF0]:0)
>>[junit4]> at
>> org.apache.solr.search.SolrIndexSearcher.getAndCacheDocSet(SolrIndexSearcher.java:862)
>>[junit4]> at
>> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:824)
>>[junit4]> at
>> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1367)
>>[junit4]> at
>> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
>>[junit4]> at
>> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1511)
>>[junit4]> at
>> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:390)
>>[junit4]> at
>> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:368)
>>[junit4]> at
>> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:216)
>>[junit4]> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2637)
>>
>> Looking at the stats for this test, it seems like it started failing
>> more consistently over the past week or so:
>> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.TestFiltering.testRandomFiltering
>>
>> I beasted it and 3/10 failed:
>>
>>   [beaster] Tests with failures [seed: A5F8AAEF7994FE2B] (first 3 out of 10):
>>   [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>>   [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>>   [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>>
>> I could just mark it as a BadApple and move on, but wanted to see if
>> anyone had any ideas about this test flakiness?
>>
>> Cheers,
>> Tim
>>
>> On Fri, Sep 17, 2021 at 4:06 PM Mike Drob  wrote:
>>
>>>
>>>  Can we move discussion about the implementation to the JIRA issue or the 
>>> PR?
>>>
>>>  I'm not a lawyer, so not playing with the GPL fire is the easiest way for 
>>> me to avoid getting burned. The regex I have is pretty straightforward, I 
>>> do not feel like it is a great cause for alarm.
>>>
>>>  On Fri, Sep 17, 2021 at 4:18 PM Ishan Chattopadhyaya 
>>>  wrote:
>>>

  Given that we don't ship the code or binaries that involve that python 
 library, do we need to care about the license? I'm skeptical of hand 
 rolled regex and would rather favour either of the libraries Jan 
 mentioned. Just my two cents.

  On Sat, 18 Sep, 2021, 12:02 am Mike Drob,  wrote:

>
>  The second library you linked, Jan, is AGPL. Thank you for continuing to 
> look for alternatives.
>
>  I have some regular expressions cooked up locally that I think will let 
> us read the split lines going forward, and will put up the patch shortly.
>
>  On Fri, Sep 17, 2021 at 7:45 AM Yuval Paz  
> wrote:
>
>>
>>  Not sure if this is something can be changed easily, but if the problem 
>> is caused by some parsers don't know how to parse line wrapping in the 
>> middle of the Hash why not moving the hash completely to the new line 
>> (the specification allow new line at any point in the value)?
>>
>>  The commit hash + date comes out to be exactly 71 bytes (including the 
>> space at the

Re: New branch and feature freeze for Lucene/Solr 8.10.0

2021-09-20 Thread Uwe Schindler

Hi,

This test also fails on Jenkins all the time. In all branches and on all 
platforms. All the time, it's definitely a regression.

Uwe

Am 20. September 2021 19:13:56 UTC schrieb Timothy Potter 
:
>Started building the RC1 again today and the smoke tester failed. The
>culprit was: org.apache.solr.search.TestFiltering.testRandomFiltering
>
>Re-ran that test from the RC checkout and it failed again:
>
>   [junit4]   2> 5490 ERROR
>(TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
>] o.a.s.SolrTestCaseJ4 REQUEST FAILED:
>facet.query=*:*={!key%3DmultiSelect+ex%3Dt}*:*={!key%3DfacetQuery+cache%3Dfalse}+val_i:2+val_i:4={!+cost%3D7+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D2+u%3D5}"=true=xml
>   [junit4]   2> 5491 INFO
>(TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
>] o.a.s.SolrTestCaseJ4 ###Ending testRandomFiltering
>   [junit4]   2> NOTE: reproduce with: ant test
>-Dtestcase=TestFiltering -Dtests.method=testRandomFiltering
>-Dtests.seed=9A85A1D74D8AACF9 -Dtests.slow=true -Dtests.badapples=true
>-Dtests.locale=mgh -Dtests.timezone=Iceland -Dtests.asserts=true
>-Dtests.file.encoding=US-ASCII
>   [junit4] FAILURE 0.82s | TestFiltering.testRandomFiltering <<<
>   [junit4]> Throwable #1: java.lang.AssertionError: should have unwrapped
>   [junit4]> at
>__randomizedtesting.SeedInfo.seed([9A85A1D74D8AACF9:85E60212A8ADECF0]:0)
>   [junit4]> at
>org.apache.solr.search.SolrIndexSearcher.getAndCacheDocSet(SolrIndexSearcher.java:862)
>   [junit4]> at
>org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:824)
>   [junit4]> at
>org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1367)
>   [junit4]> at
>org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
>   [junit4]> at
>org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1511)
>   [junit4]> at
>org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:390)
>   [junit4]> at
>org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:368)
>   [junit4]> at
>org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:216)
>   [junit4]> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2637)
>
>Looking at the stats for this test, it seems like it started failing
>more consistently over the past week or so:
>http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.TestFiltering.testRandomFiltering
>
>I beasted it and 3/10 failed:
>
>  [beaster] Tests with failures [seed: A5F8AAEF7994FE2B] (first 3 out of 10):
>  [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>  [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>  [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
>
>I could just mark it as a BadApple and move on, but wanted to see if
>anyone had any ideas about this test flakiness?
>
>Cheers,
>Tim
>
>On Fri, Sep 17, 2021 at 4:06 PM Mike Drob  wrote:
>>
>> Can we move discussion about the implementation to the JIRA issue or the PR?
>>
>> I'm not a lawyer, so not playing with the GPL fire is the easiest way for me 
>> to avoid getting burned. The regex I have is pretty straightforward, I do 
>> not feel like it is a great cause for alarm.
>>
>> On Fri, Sep 17, 2021 at 4:18 PM Ishan Chattopadhyaya 
>>  wrote:
>>>
>>> Given that we don't ship the code or binaries that involve that python 
>>> library, do we need to care about the license? I'm skeptical of hand rolled 
>>> regex and would rather favour either of the libraries Jan mentioned. Just 
>>> my two cents.
>>>
>>> On Sat, 18 Sep, 2021, 12:02 am Mike Drob,  wrote:

 The second library you linked, Jan, is AGPL. Thank you for continuing to 
 look for alternatives.

 I have some regular expressions cooked up locally that I think will let us 
 read the split lines going forward, and will put up the patch shortly.

 On Fri, Sep 17, 2021 at 7:45 AM Yuval Paz  
 wrote:
>
> Not sure if this is something can be changed easily, but if the problem 
> is caused by some parsers don't know how to parse line wrapping in the 
> middle of the Hash why not moving the hash completely to the new line 
> (the specification allow new line at any point in the value)?
>
> The commit hash + date comes out to be exactly 71 bytes (including the 
> space at the start), and it should be a constant size, and by the time 
> the version will reach 48 bytes we all be probably dead
>
> On Fri, Sep 17, 2021, 2:47 PM Robert Muir  wrote:
>>
>> Sure, but that package is archived/read-only, GPLv3. with 3 watchers and 
>> 1 star.
>>
>> On Fri, Sep 17, 2021 at 4:27 AM Jan Høydahl  
>> wrote:
>> >
>> > Let's just follow the spec and move on.
>> >
>> > Just tested this python

Re: New branch and feature freeze for Lucene/Solr 8.10.0

2021-09-20 Thread Timothy Potter

Started building the RC1 again today and the smoke tester failed. The
culprit was: org.apache.solr.search.TestFiltering.testRandomFiltering

Re-ran that test from the RC checkout and it failed again:

   [junit4]   2> 5490 ERROR
(TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
] o.a.s.SolrTestCaseJ4 REQUEST FAILED:
facet.query=*:*={!key%3DmultiSelect+ex%3Dt}*:*={!key%3DfacetQuery+cache%3Dfalse}+val_i:2+val_i:4={!+cost%3D7+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D2+u%3D5}"=true=xml
   [junit4]   2> 5491 INFO
(TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
] o.a.s.SolrTestCaseJ4 ###Ending testRandomFiltering
   [junit4]   2> NOTE: reproduce with: ant test
-Dtestcase=TestFiltering -Dtests.method=testRandomFiltering
-Dtests.seed=9A85A1D74D8AACF9 -Dtests.slow=true -Dtests.badapples=true
-Dtests.locale=mgh -Dtests.timezone=Iceland -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 0.82s | TestFiltering.testRandomFiltering <<<
   [junit4]> Throwable #1: java.lang.AssertionError: should have unwrapped
   [junit4]> at
__randomizedtesting.SeedInfo.seed([9A85A1D74D8AACF9:85E60212A8ADECF0]:0)
   [junit4]> at
org.apache.solr.search.SolrIndexSearcher.getAndCacheDocSet(SolrIndexSearcher.java:862)
   [junit4]> at
org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:824)
   [junit4]> at
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1367)
   [junit4]> at
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
   [junit4]> at
org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1511)
   [junit4]> at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:390)
   [junit4]> at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:368)
   [junit4]> at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:216)
   [junit4]> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2637)

Looking at the stats for this test, it seems like it started failing
more consistently over the past week or so:
http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.TestFiltering.testRandomFiltering

I beasted it and 3/10 failed:

  [beaster] Tests with failures [seed: A5F8AAEF7994FE2B] (first 3 out of 10):
  [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
  [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering
  [beaster]   - org.apache.solr.search.TestFiltering.testRandomFiltering

I could just mark it as a BadApple and move on, but wanted to see if
anyone had any ideas about this test flakiness?

Cheers,
Tim

On Fri, Sep 17, 2021 at 4:06 PM Mike Drob  wrote:
>
> Can we move discussion about the implementation to the JIRA issue or the PR?
>
> I'm not a lawyer, so not playing with the GPL fire is the easiest way for me 
> to avoid getting burned. The regex I have is pretty straightforward, I do not 
> feel like it is a great cause for alarm.
>
> On Fri, Sep 17, 2021 at 4:18 PM Ishan Chattopadhyaya 
>  wrote:
>>
>> Given that we don't ship the code or binaries that involve that python 
>> library, do we need to care about the license? I'm skeptical of hand rolled 
>> regex and would rather favour either of the libraries Jan mentioned. Just my 
>> two cents.
>>
>> On Sat, 18 Sep, 2021, 12:02 am Mike Drob,  wrote:
>>>
>>> The second library you linked, Jan, is AGPL. Thank you for continuing to 
>>> look for alternatives.
>>>
>>> I have some regular expressions cooked up locally that I think will let us 
>>> read the split lines going forward, and will put up the patch shortly.
>>>
>>> On Fri, Sep 17, 2021 at 7:45 AM Yuval Paz  
>>> wrote:

 Not sure if this is something can be changed easily, but if the problem is 
 caused by some parsers don't know how to parse line wrapping in the middle 
 of the Hash why not moving the hash completely to the new line (the 
 specification allow new line at any point in the value)?

 The commit hash + date comes out to be exactly 71 bytes (including the 
 space at the start), and it should be a constant size, and by the time the 
 version will reach 48 bytes we all be probably dead

 On Fri, Sep 17, 2021, 2:47 PM Robert Muir  wrote:
>
> Sure, but that package is archived/read-only, GPLv3. with 3 watchers and 
> 1 star.
>
> On Fri, Sep 17, 2021 at 4:27 AM Jan Høydahl  wrote:
> >
> > Let's just follow the spec and move on.
> >
> > Just tested this python package, which has no problem parsing the 
> > problematic manifest https://pypi.org/project/jarmanifest/
> >
> > >>> manifest.getAttributes("/tmp/lucene-manifest.mf")
> > [{'implementationversion': '9.0.0-SNAPSHOT 
> > de45b68c909815ce5ea7b6b9e1a2ce3375b6334d [snapshot build, details

Re: Accessibility of QueryParserBase::handleBareFuzzy

2021-09-20 Thread Alan Woodward

Hi Chris,

The difference between the elasticsearch query parser and the built-in lucene 
one appears to be based around how they parse fuzziness, so I think the best 
solution here is to add another protected method, something like this:

protected float parseFuzzyDistance(String input, float default) {
try {
return Float.parseFloat(fuzzySlop.image.substring(1));
} catch (@SuppressWarnings("unused”) Exception ignored) {
return default;
}
}

Then handleBareFuzzy() can call out to this, and the ES version can overload it 
and do its own parsing.

- A

> On 20 Sep 2021, at 15:39, Chris Hegarty 
>  wrote:
> 
> Hi, 
> 
> In an effort to prepare Elasticsearch for modularization, we are
> investigating and eliminating split packages. The situation has improved
> through recent refactoring in Lucene 9.0 [1], but a number of split
> packages still remain. This message identifies one such so that it can
> be discussed in isolation, with a view to a potential solution either in
> Lucene or possibly within Elasticsearch itself.
> 
> Elasticsearch has a query parser, `QueryStringQueryParser`[2], that
> builds queries based on mapping information. This parser has a need to
> override its superclass's 
> `org.apache.lucene.queryparser.classic.QueryParserBase::handleBareFuzzy` [3]
> method, in order to provide custom handling of fuzzy queries. This is
> clearly not "best practice", since to do so requires the use of
> effectively (but not literally) injecting into a lucene package, which
> is done through `XQueryParser` [4]. We want to eliminate the need for
> `XQueryParser`, and hence the split package at run time.
> 
> Clearly, but likely not right, we could simply make `handleBareFuzzy` a
> a protected method in Lucene's `QueryParser` or `QueryParserBase` - this
> would satisfy the need of the Elasticsearch `QueryStringQueryParser`. If
> not this, I don't see an alternative that could be coded in
> Elasticsearch's `QueryStringQueryParser`, but maybe there is a different
> API extension point that could be used, or a new one provided?
> 
> -Chris.
> 
> [1] https://issues.apache.org/jira/browse/LUCENE-9319
> [2] 
> https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/index/search/QueryStringQueryParser.java#L436
> [3] 
> https://github.com/apache/lucene/blob/8ac26737913d0c1555019e93bc6bf7db1ab9047e/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L813
> [4] 
> https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/apache/lucene/queryparser/classic/XQueryParser.java
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Accessibility of QueryParserBase::handleBareFuzzy

2021-09-20 Thread Chris Hegarty

Hi, 

In an effort to prepare Elasticsearch for modularization, we are
investigating and eliminating split packages. The situation has improved
through recent refactoring in Lucene 9.0 [1], but a number of split
packages still remain. This message identifies one such so that it can
be discussed in isolation, with a view to a potential solution either in
Lucene or possibly within Elasticsearch itself.

Elasticsearch has a query parser, `QueryStringQueryParser`[2], that
builds queries based on mapping information. This parser has a need to
override its superclass's 
`org.apache.lucene.queryparser.classic.QueryParserBase::handleBareFuzzy` [3]
method, in order to provide custom handling of fuzzy queries. This is
clearly not "best practice", since to do so requires the use of
effectively (but not literally) injecting into a lucene package, which
is done through `XQueryParser` [4]. We want to eliminate the need for
`XQueryParser`, and hence the split package at run time.

Clearly, but likely not right, we could simply make `handleBareFuzzy` a
a protected method in Lucene's `QueryParser` or `QueryParserBase` - this
would satisfy the need of the Elasticsearch `QueryStringQueryParser`. If
not this, I don't see an alternative that could be coded in
Elasticsearch's `QueryStringQueryParser`, but maybe there is a different
API extension point that could be used, or a new one provided?

-Chris.

[1] https://issues.apache.org/jira/browse/LUCENE-9319
[2] 
https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/index/search/QueryStringQueryParser.java#L436
[3] 
https://github.com/apache/lucene/blob/8ac26737913d0c1555019e93bc6bf7db1ab9047e/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L813
[4] 
https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/apache/lucene/queryparser/classic/XQueryParser.java


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

Re: Soften Jira's note when opening new issues?

2021-09-20 Thread Nhat Nguyen

+1

On Mon, Sep 20, 2021 at 8:41 AM Michael Sokolov  wrote:

> I agree, it's friendlier with the same basic message.
>
> On Mon, Sep 20, 2021 at 8:25 AM Jan Høydahl  wrote:
> >
> > +1
> >
> > Jan
> >
> > > 20. sep. 2021 kl. 10:32 skrev Adrien Grand :
> > >
> > > Hello,
> > >
> > > Jira gives the following note when opening an issue:
> > >
> > > ```
> > > This project has a user mailing list and an IRC channel for support.
> Please ensure that you have discussed your problem using one of those
> resources BEFORE creating this ticket.
> > > ```
> > >
> > > This can be quite intimidating for someone who has never worked with
> us before, and we don't apply this logic for ourselves, for instance I feel
> free to open JIRAs without discussing them first on IRC or dev@l.a.o.
> Given that we are not seeing much irrelevant traffic on JIRA, I'd like to
> soften the message to something like below:
> > >
> > > ```
> > > If you are looking for support, or if you are not sure whether the
> behavior that you are observing is expected or not, please discuss your
> problem on the user mailing-list instead before creating a ticket.
> > > ```
> > >
> > > What do you think?
> > >
> > > --
> > > Adrien
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Soften Jira's note when opening new issues?

2021-09-20 Thread Michael Sokolov

I agree, it's friendlier with the same basic message.

On Mon, Sep 20, 2021 at 8:25 AM Jan Høydahl  wrote:
>
> +1
>
> Jan
>
> > 20. sep. 2021 kl. 10:32 skrev Adrien Grand :
> >
> > Hello,
> >
> > Jira gives the following note when opening an issue:
> >
> > ```
> > This project has a user mailing list and an IRC channel for support. Please 
> > ensure that you have discussed your problem using one of those resources 
> > BEFORE creating this ticket.
> > ```
> >
> > This can be quite intimidating for someone who has never worked with us 
> > before, and we don't apply this logic for ourselves, for instance I feel 
> > free to open JIRAs without discussing them first on IRC or dev@l.a.o. Given 
> > that we are not seeing much irrelevant traffic on JIRA, I'd like to soften 
> > the message to something like below:
> >
> > ```
> > If you are looking for support, or if you are not sure whether the behavior 
> > that you are observing is expected or not, please discuss your problem on 
> > the user mailing-list instead before creating a ticket.
> > ```
> >
> > What do you think?
> >
> > --
> > Adrien
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: Soften Jira's note when opening new issues?

2021-09-20 Thread Jan Høydahl

+1

Jan

> 20. sep. 2021 kl. 10:32 skrev Adrien Grand :
> 
> Hello,
> 
> Jira gives the following note when opening an issue:
> 
> ```
> This project has a user mailing list and an IRC channel for support. Please 
> ensure that you have discussed your problem using one of those resources 
> BEFORE creating this ticket.
> ```
> 
> This can be quite intimidating for someone who has never worked with us 
> before, and we don't apply this logic for ourselves, for instance I feel free 
> to open JIRAs without discussing them first on IRC or dev@l.a.o. Given that 
> we are not seeing much irrelevant traffic on JIRA, I'd like to soften the 
> message to something like below:
> 
> ```
> If you are looking for support, or if you are not sure whether the behavior 
> that you are observing is expected or not, please discuss your problem on the 
> user mailing-list instead before creating a ticket.
> ```
> 
> What do you think?
> 
> -- 
> Adrien


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

Re: Soften Jira's note when opening new issues?

2021-09-20 Thread Alexandre Rafalovitch

+1.
Ideally, the final version could still be several shorter sentences. To
avoid needing to be a programmer to parse the deeply nested, if totally
logical, structure.

On Mon., Sep. 20, 2021, 4:33 a.m. Adrien Grand,  wrote:

> Hello,
>
> Jira gives the following note when opening an issue:
>
> ```
> This project has a user mailing list and an IRC channel for support.
> Please ensure that you have discussed your problem using one of those
> resources BEFORE creating this ticket.
> ```
>
> This can be quite intimidating for someone who has never worked with us
> before, and we don't apply this logic for ourselves, for instance I feel
> free to open JIRAs without discussing them first on IRC or dev@l.a.o.
> Given that we are not seeing much irrelevant traffic on JIRA, I'd like to
> soften the message to something like below:
>
> ```
> If you are looking for support, or if you are not sure whether the
> behavior that you are observing is expected or not, please discuss your
> problem on the user mailing-list instead before creating a ticket.
> ```
>
> What do you think?
>
> --
> Adrien
>

Re: Soften Jira's note when opening new issues?

2021-09-20 Thread Michael McCandless

+1

Mike

On Mon, Sep 20, 2021 at 4:59 AM Uwe Schindler  wrote:

> This is a good idea!
>
> Uwe
>
>
> Am 20. September 2021 08:51:16 UTC schrieb Ignacio Vera  >:
>>
>> +1
>>
>> On Mon, Sep 20, 2021 at 10:47 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> +1
>>>
>>> On Mon, 20 Sep, 2021, 12:33 pm Adrien Grand,  wrote:
>>>
 Hello,

 Jira gives the following note when opening an issue:

 ```
 This project has a user mailing list and an IRC channel for support.
 Please ensure that you have discussed your problem using one of those
 resources BEFORE creating this ticket.
 ```

 This can be quite intimidating for someone who has never worked with us
 before, and we don't apply this logic for ourselves, for instance I feel
 free to open JIRAs without discussing them first on IRC or dev@l.a.o.
 Given that we are not seeing much irrelevant traffic on JIRA, I'd like to
 soften the message to something like below:

 ```
 If you are looking for support, or if you are not sure whether the
 behavior that you are observing is expected or not, please discuss your
 problem on the user mailing-list instead before creating a ticket.
 ```

 What do you think?

 --
 Adrien

>>> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> 
> https://www.thetaphi.de
>
-- 
Mike McCandless

http://blog.mikemccandless.com

Re: Soften Jira's note when opening new issues?

2021-09-20 Thread Uwe Schindler

This is a good idea! 

Uwe

Am 20. September 2021 08:51:16 UTC schrieb Ignacio Vera :
>+1
>
>On Mon, Sep 20, 2021 at 10:47 AM Ishan Chattopadhyaya <
>ichattopadhy...@gmail.com> wrote:
>
>> +1
>>
>> On Mon, 20 Sep, 2021, 12:33 pm Adrien Grand,  wrote:
>>
>>> Hello,
>>>
>>> Jira gives the following note when opening an issue:
>>>
>>> ```
>>> This project has a user mailing list and an IRC channel for support.
>>> Please ensure that you have discussed your problem using one of those
>>> resources BEFORE creating this ticket.
>>> ```
>>>
>>> This can be quite intimidating for someone who has never worked with us
>>> before, and we don't apply this logic for ourselves, for instance I feel
>>> free to open JIRAs without discussing them first on IRC or dev@l.a.o.
>>> Given that we are not seeing much irrelevant traffic on JIRA, I'd like to
>>> soften the message to something like below:
>>>
>>> ```
>>> If you are looking for support, or if you are not sure whether the
>>> behavior that you are observing is expected or not, please discuss your
>>> problem on the user mailing-list instead before creating a ticket.
>>> ```
>>>
>>> What do you think?
>>>
>>> --
>>> Adrien
>>>
>>

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Re: Soften Jira's note when opening new issues?

2021-09-20 Thread Ignacio Vera

+1

On Mon, Sep 20, 2021 at 10:47 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> +1
>
> On Mon, 20 Sep, 2021, 12:33 pm Adrien Grand,  wrote:
>
>> Hello,
>>
>> Jira gives the following note when opening an issue:
>>
>> ```
>> This project has a user mailing list and an IRC channel for support.
>> Please ensure that you have discussed your problem using one of those
>> resources BEFORE creating this ticket.
>> ```
>>
>> This can be quite intimidating for someone who has never worked with us
>> before, and we don't apply this logic for ourselves, for instance I feel
>> free to open JIRAs without discussing them first on IRC or dev@l.a.o.
>> Given that we are not seeing much irrelevant traffic on JIRA, I'd like to
>> soften the message to something like below:
>>
>> ```
>> If you are looking for support, or if you are not sure whether the
>> behavior that you are observing is expected or not, please discuss your
>> problem on the user mailing-list instead before creating a ticket.
>> ```
>>
>> What do you think?
>>
>> --
>> Adrien
>>
>

Re: Soften Jira's note when opening new issues?

2021-09-20 Thread Ishan Chattopadhyaya

+1

On Mon, 20 Sep, 2021, 12:33 pm Adrien Grand,  wrote:

> Hello,
>
> Jira gives the following note when opening an issue:
>
> ```
> This project has a user mailing list and an IRC channel for support.
> Please ensure that you have discussed your problem using one of those
> resources BEFORE creating this ticket.
> ```
>
> This can be quite intimidating for someone who has never worked with us
> before, and we don't apply this logic for ourselves, for instance I feel
> free to open JIRAs without discussing them first on IRC or dev@l.a.o.
> Given that we are not seeing much irrelevant traffic on JIRA, I'd like to
> soften the message to something like below:
>
> ```
> If you are looking for support, or if you are not sure whether the
> behavior that you are observing is expected or not, please discuss your
> problem on the user mailing-list instead before creating a ticket.
> ```
>
> What do you think?
>
> --
> Adrien
>

Soften Jira's note when opening new issues?

2021-09-20 Thread Adrien Grand

Hello,

Jira gives the following note when opening an issue:

```
This project has a user mailing list and an IRC channel for support. Please
ensure that you have discussed your problem using one of those resources
BEFORE creating this ticket.
```

This can be quite intimidating for someone who has never worked with us
before, and we don't apply this logic for ourselves, for instance I feel
free to open JIRAs without discussing them first on IRC or dev@l.a.o. Given
that we are not seeing much irrelevant traffic on JIRA, I'd like to soften
the message to something like below:

```
If you are looking for support, or if you are not sure whether the behavior
that you are observing is expected or not, please discuss your problem on
the user mailing-list instead before creating a ticket.
```

What do you think?

-- 
Adrien

Re: New branch and feature freeze for Lucene/Solr 8.10.0

Re: New branch and feature freeze for Lucene/Solr 8.10.0

Re: New branch and feature freeze for Lucene/Solr 8.10.0

Re: Accessibility of QueryParserBase::handleBareFuzzy

Accessibility of QueryParserBase::handleBareFuzzy

Re: Soften Jira's note when opening new issues?

Re: Soften Jira's note when opening new issues?

Re: Soften Jira's note when opening new issues?

Re: Soften Jira's note when opening new issues?

Re: Soften Jira's note when opening new issues?

Re: Soften Jira's note when opening new issues?

Re: Soften Jira's note when opening new issues?

Re: Soften Jira's note when opening new issues?

Soften Jira's note when opening new issues?

14 matches

Site Navigation

Mail list logo

Footer information