date:20191126

Re: Closing GitHub PRs

2019-11-26 Thread Man with No Name

I have a PR without a jira ticket, I’ll update the title of the PR.

On Tue, Nov 26, 2019 at 3:02 PM Jan Høydahl  wrote:

> Hi
>
> I ran the tool dev-tools/scripts/githubPRs.py and JIRA and GitHub tend to
> diverge day by day. Need some help to connect orphan PRs with JIRA issues
> and close PRs that have a closed JIRA:
>
> PRs lacking JIRA reference in title
>   #1026: Buffer one record from each shard every 5000 reads to ensure
> connecti…
>   #1005: LUCENE 9042: Refactor TopGroups.merge tests
>   #1002: [docs]: fixed two small errors in JavaDoc
>   #1000: [MINOR] Fix typo
>   #993: maybe can simpler
>   #988: Update README.md
>   #934: Fix typo
>   #908: Change the file format of README files from README.txt to
> README.md a…
>   #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
>   #880: Tweak header format.
>   #873: Rename README.txt to README.md
>   #854: Shared PQ Based Early Termination for Concurrent Search
>   #807: Remove solr.jetty.https.port when SSL is not used
>   #772: Payload-stored position length intervals
>   #673: Replace instances of Math.random with Random.nextDouble
>   #669: Facet2d
>   #639: Solve the problem of highlighting Chinese inaccurately.
>   #615: Intervals Query Parser
>   #602: docu change: use class TopDocs instead of Hits
>   #601: Adding reader settings for moving fst offheap
>   #596: Under this branch, the dataDimensionCount is definitely not zero.
>   #564: prorated early termination
>   #542: LuceneLevenshteinDistance computes distance values outside of
> interval [0, 1]
>   #508: Simplified JAVA_VER_NUM to utilize single expr execution
>   #492: Answer to TODO: Replace Manual Encoding with JSON Module
>   #491: Update for multiple term's suggestion scoring
>   #484: solr 7.5 suggest The recommended result is empty
>   #478: Query Source Tracker custom component
>   #450: Add rule exception for "imento" and "mento" suffix
>   #442: Fixing an edge case bug when overriding a default
> PostingsSolrHighligher
>   #405: don't die when java prints tool options
>   #404: Comment to explain how to use URLClassifyProcessorFactory
>   #399: fix explicit type declaration
>   #383: In ContextQuery, use a more comprehensive check for an empty
> prefix automaton.
>   #379: add ë, ö and ï to norm()
>   #350: SOLR match mode change for the rouding off instead of taking floor
>   #340: Add SolrConfig to SolrRequestParsers constructor in
> EmbeddedSolrServer
>   #309: Update ZkConfigManager.java
>   #308: Add a suggester that operates on tokenized values from a field
>   #293: spellcheck prefix already contains a trailing dot
>   #292: Removed extra whitespace
>   #272: Correct inconsistency on plugin support
>   #241: SpanishLightStemmer fix for plural words like casas
>   #234: Made minor changes to docstring to fix wording errors
>   #231: WordDelimiterGraphFilter: Better support for camel case splitting.
>   #218: feat: Separate SuggestModes for WordBreak and WordJoin
>   #217: added initial .travis.yml
>   #201: Allocate ArrayList with exact size
>   #175: Skipping merger
>   #153: Fix issues reported by findbugs
>   #152: Added log prior calculations in CachingNaiveBayesClassifier.
>   #133: Prevent memory leaks in PerFieldAnalyzerWrapper
>   #131: Fix peer sync replcation test check
>   #124: fix small issue in solr shell script
>   #116: fixed NPEs
>   #110: Update SearchFiles.java
>   #108: Minor - Fix error message
>   #85: Allow updating configs like port # on forced upgrade
>   #48: moved common string to constant file
>   #22: Update files.js
>   #8: Do not log error messages, if client has been interrupted
>
> Open PRs with a resolved JIRA
>   #365: SOLR-12243 status=Closed, resolution=Fixed,
> resolutiondate=2018-11-05T17:20:27.000+ ([SOLR-12243] span query
> generalization + query parser tests)
>   #330: SOLR-12045 status=Closed, resolution=Won't Fix,
> resolutiondate=2019-11-02T15:24:54.000+ (SOLR-12045: Moving the
> Analytics Component from contrib to core.)
>   #861: SOLR-10665 status=Resolved, resolution=Abandoned,
> resolutiondate=2019-11-12T03:25:46.000+ (SOLR-10665 POC for a PF4J
> based plugin system)
>   #161: SOLR-9399 status=Closed, resolution=Fixed,
> resolutiondate=2018-04-02T16:31:06.000+ (Fix SOLR-9399, pass basic auth
> to update request)
>   #93: SOLR-8754 status=Closed, resolution=Fixed,
> resolutiondate=2019-06-13T10:59:41.000+ (SOLR-8754: Adding test cases
> and additional error checking)
>   #1032: LUCENE-9058 status=Resolved, resolution=Won't Fix,
> resolutiondate=2019-11-25T18:58:49.000+ (LUCENE-9058: highlighting over
> underneath field despite IQ field)
>   #631: LUCENE-8750 status=Resolved, resolution=Fixed,
> resolutiondate=2019-04-03T09:19:47.000+ (LUCENE-8750: implement
> setMissingValue for ValueSource sortFields)
>   #536: LUCENE-8643 status=Resolved, resolution=Fixed,
> resolutiondate=2019-01-17T09:12:09.000+ (LUCENE-8643: Decrease test
> complexity in the default case.

Re: 8.3.1 release

2019-11-26 Thread Jan Høydahl

Done merging (there were 4 related commits):

SOLR-13465  CoreContainer.auditloggerPlugin should be volatile (#672))
SOLR-13905  Make findRequestType in AuditEvent more robust (#1014))
SOLR-13741: Harden AuditLoggerIntegrationTest)
SOLR-13941: Configure JettySolrRunner same as in web.xml (#1018))

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 26. nov. 2019 kl. 17:35 skrev Ishan Chattopadhyaya 
> :
> 
> Sure, Jan. Please go ahead.
> I'll start the artifact building after, at least, a day from now (as
> there is one more bug that I'm planning to fix and include in this
> release).
> 
> On Tue, Nov 26, 2019 at 5:58 PM Jan Høydahl  wrote:
>> 
>> SOLR-13905 requires SOLR-13941 to be backported as well.
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>> 26. nov. 2019 kl. 16:53 skrev Jan Høydahl :
>> 
>> I'll back port SOLR-13905
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>> 26. nov. 2019 kl. 13:40 skrev Ishan Chattopadhyaya 
>> :
>> 
>> I'll start building the artifacts in 8-12 hours. If there are any issues 
>> someone wants to (or wants me to) backport, please feel free.
>> Regards,
>> Ishan
>> 
>> On Mon, 25 Nov, 2019, 6:33 PM Adrien Grand,  wrote:
>>> 
>>> It looks worth shipping a bugfix release indeed, +1.
>>> 
>>> On Mon, Nov 25, 2019 at 2:02 PM Jason Gerlowski  
>>> wrote:
 
 +1
 
 On Mon, Nov 25, 2019 at 4:19 AM Shalin Shekhar Mangar
  wrote:
> 
> +1
> 
> On Mon, Nov 25, 2019 at 11:20 AM Noble Paul  wrote:
>> 
>> +1
>> 
>> On Mon, Nov 25, 2019 at 4:49 PM Ishan Chattopadhyaya
>>  wrote:
>>> 
>>> Hi,
>>> Recently, Colvin has reported
>>> https://issues.apache.org/jira/browse/SOLR-13963. Effect of this is
>>> that Solr 8.3 must not be used out of the box due to the reported data
>>> loss. I propose we fix this as soon as possible and release 8.3.1. I
>>> am volunteering as RM for this.
>>> Any thoughts?
>>> Regards,
>>> Ishan
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
>> 
>> --
>> -
>> Noble Paul
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
> 
> 
> --
> Regards,
> Shalin Shekhar Mangar.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
>>> 
>>> 
>>> --
>>> 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
>

Closing GitHub PRs

2019-11-26 Thread Jan Høydahl

Hi

I ran the tool dev-tools/scripts/githubPRs.py and JIRA and GitHub tend to 
diverge day by day. Need some help to connect orphan PRs with JIRA issues and 
close PRs that have a closed JIRA:

PRs lacking JIRA reference in title
  #1026: Buffer one record from each shard every 5000 reads to ensure connecti…
  #1005: LUCENE 9042: Refactor TopGroups.merge tests
  #1002: [docs]: fixed two small errors in JavaDoc
  #1000: [MINOR] Fix typo
  #993: maybe can simpler
  #988: Update README.md
  #934: Fix typo
  #908: Change the file format of README files from README.txt to README.md a…
  #882: Add versions.lock entry for "org.apache.yetus:audience-annotations"
  #880: Tweak header format.
  #873: Rename README.txt to README.md
  #854: Shared PQ Based Early Termination for Concurrent Search
  #807: Remove solr.jetty.https.port when SSL is not used
  #772: Payload-stored position length intervals
  #673: Replace instances of Math.random with Random.nextDouble
  #669: Facet2d
  #639: Solve the problem of highlighting Chinese inaccurately.
  #615: Intervals Query Parser
  #602: docu change: use class TopDocs instead of Hits
  #601: Adding reader settings for moving fst offheap
  #596: Under this branch, the dataDimensionCount is definitely not zero.
  #564: prorated early termination
  #542: LuceneLevenshteinDistance computes distance values outside of interval 
[0, 1]
  #508: Simplified JAVA_VER_NUM to utilize single expr execution
  #492: Answer to TODO: Replace Manual Encoding with JSON Module
  #491: Update for multiple term's suggestion scoring
  #484: solr 7.5 suggest The recommended result is empty
  #478: Query Source Tracker custom component
  #450: Add rule exception for "imento" and "mento" suffix
  #442: Fixing an edge case bug when overriding a default PostingsSolrHighligher
  #405: don't die when java prints tool options
  #404: Comment to explain how to use URLClassifyProcessorFactory
  #399: fix explicit type declaration
  #383: In ContextQuery, use a more comprehensive check for an empty prefix 
automaton.
  #379: add ë, ö and ï to norm()
  #350: SOLR match mode change for the rouding off instead of taking floor
  #340: Add SolrConfig to SolrRequestParsers constructor in EmbeddedSolrServer
  #309: Update ZkConfigManager.java
  #308: Add a suggester that operates on tokenized values from a field
  #293: spellcheck prefix already contains a trailing dot
  #292: Removed extra whitespace
  #272: Correct inconsistency on plugin support
  #241: SpanishLightStemmer fix for plural words like casas
  #234: Made minor changes to docstring to fix wording errors
  #231: WordDelimiterGraphFilter: Better support for camel case splitting.
  #218: feat: Separate SuggestModes for WordBreak and WordJoin
  #217: added initial .travis.yml
  #201: Allocate ArrayList with exact size
  #175: Skipping merger
  #153: Fix issues reported by findbugs
  #152: Added log prior calculations in CachingNaiveBayesClassifier.
  #133: Prevent memory leaks in PerFieldAnalyzerWrapper
  #131: Fix peer sync replcation test check
  #124: fix small issue in solr shell script
  #116: fixed NPEs
  #110: Update SearchFiles.java
  #108: Minor - Fix error message
  #85: Allow updating configs like port # on forced upgrade
  #48: moved common string to constant file
  #22: Update files.js
  #8: Do not log error messages, if client has been interrupted

Open PRs with a resolved JIRA
  #365: SOLR-12243 status=Closed, resolution=Fixed, 
resolutiondate=2018-11-05T17:20:27.000+ ([SOLR-12243] span query 
generalization + query parser tests)
  #330: SOLR-12045 status=Closed, resolution=Won't Fix, 
resolutiondate=2019-11-02T15:24:54.000+ (SOLR-12045: Moving the Analytics 
Component from contrib to core.)
  #861: SOLR-10665 status=Resolved, resolution=Abandoned, 
resolutiondate=2019-11-12T03:25:46.000+ (SOLR-10665 POC for a PF4J based 
plugin system)
  #161: SOLR-9399 status=Closed, resolution=Fixed, 
resolutiondate=2018-04-02T16:31:06.000+ (Fix SOLR-9399, pass basic auth to 
update request)
  #93: SOLR-8754 status=Closed, resolution=Fixed, 
resolutiondate=2019-06-13T10:59:41.000+ (SOLR-8754: Adding test cases and 
additional error checking)
  #1032: LUCENE-9058 status=Resolved, resolution=Won't Fix, 
resolutiondate=2019-11-25T18:58:49.000+ (LUCENE-9058: highlighting over 
underneath field despite IQ field)
  #631: LUCENE-8750 status=Resolved, resolution=Fixed, 
resolutiondate=2019-04-03T09:19:47.000+ (LUCENE-8750: implement 
setMissingValue for ValueSource sortFields)
  #536: LUCENE-8643 status=Resolved, resolution=Fixed, 
resolutiondate=2019-01-17T09:12:09.000+ (LUCENE-8643: Decrease test 
complexity in the default case. Exclude simple text codec.)
  #533: LUCENE-8636 status=Resolved, resolution=Fixed, 
resolutiondate=2019-01-15T11:02:49.000+ (LUCENE-8636: TestPointQueries and 
long execution times)
  #543: LUCENE-8474 status=Resolved, resolution=Fixed, 
resolutiondate=2019-01-28T12:50:00.000+ (LUCENE-8474: final

Re: 8.3.1 release

2019-11-26 Thread Ishan Chattopadhyaya

Sure, Jan. Please go ahead.
I'll start the artifact building after, at least, a day from now (as
there is one more bug that I'm planning to fix and include in this
release).

On Tue, Nov 26, 2019 at 5:58 PM Jan Høydahl  wrote:
>
> SOLR-13905 requires SOLR-13941 to be backported as well.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 26. nov. 2019 kl. 16:53 skrev Jan Høydahl :
>
> I'll back port SOLR-13905
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 26. nov. 2019 kl. 13:40 skrev Ishan Chattopadhyaya 
> :
>
> I'll start building the artifacts in 8-12 hours. If there are any issues 
> someone wants to (or wants me to) backport, please feel free.
> Regards,
> Ishan
>
> On Mon, 25 Nov, 2019, 6:33 PM Adrien Grand,  wrote:
>>
>> It looks worth shipping a bugfix release indeed, +1.
>>
>> On Mon, Nov 25, 2019 at 2:02 PM Jason Gerlowski  
>> wrote:
>> >
>> > +1
>> >
>> > On Mon, Nov 25, 2019 at 4:19 AM Shalin Shekhar Mangar
>> >  wrote:
>> > >
>> > > +1
>> > >
>> > > On Mon, Nov 25, 2019 at 11:20 AM Noble Paul  wrote:
>> > >>
>> > >> +1
>> > >>
>> > >> On Mon, Nov 25, 2019 at 4:49 PM Ishan Chattopadhyaya
>> > >>  wrote:
>> > >> >
>> > >> > Hi,
>> > >> > Recently, Colvin has reported
>> > >> > https://issues.apache.org/jira/browse/SOLR-13963. Effect of this is
>> > >> > that Solr 8.3 must not be used out of the box due to the reported data
>> > >> > loss. I propose we fix this as soon as possible and release 8.3.1. I
>> > >> > am volunteering as RM for this.
>> > >> > Any thoughts?
>> > >> > Regards,
>> > >> > Ishan
>> > >> >
>> > >> > -
>> > >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > >> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> > >> >
>> > >>
>> > >>
>> > >> --
>> > >> -
>> > >> Noble Paul
>> > >>
>> > >> -
>> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> > >>
>> > >
>> > >
>> > > --
>> > > Regards,
>> > > Shalin Shekhar Mangar.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> --
>> 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: 8.3.1 release

2019-11-26 Thread Jan Høydahl

SOLR-13905 requires SOLR-13941 to be backported as well.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 26. nov. 2019 kl. 16:53 skrev Jan Høydahl :
> 
> I'll back port SOLR-13905
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
>> 26. nov. 2019 kl. 13:40 skrev Ishan Chattopadhyaya 
>> mailto:ichattopadhy...@gmail.com>>:
>> 
>> I'll start building the artifacts in 8-12 hours. If there are any issues 
>> someone wants to (or wants me to) backport, please feel free.
>> Regards,
>> Ishan
>> 
>> On Mon, 25 Nov, 2019, 6:33 PM Adrien Grand, > > wrote:
>> It looks worth shipping a bugfix release indeed, +1.
>> 
>> On Mon, Nov 25, 2019 at 2:02 PM Jason Gerlowski > > wrote:
>> >
>> > +1
>> >
>> > On Mon, Nov 25, 2019 at 4:19 AM Shalin Shekhar Mangar
>> > mailto:shalinman...@gmail.com>> wrote:
>> > >
>> > > +1
>> > >
>> > > On Mon, Nov 25, 2019 at 11:20 AM Noble Paul > > > > wrote:
>> > >>
>> > >> +1
>> > >>
>> > >> On Mon, Nov 25, 2019 at 4:49 PM Ishan Chattopadhyaya
>> > >> mailto:ichattopadhy...@gmail.com>> wrote:
>> > >> >
>> > >> > Hi,
>> > >> > Recently, Colvin has reported
>> > >> > https://issues.apache.org/jira/browse/SOLR-13963 
>> > >> > . Effect of this is
>> > >> > that Solr 8.3 must not be used out of the box due to the reported data
>> > >> > loss. I propose we fix this as soon as possible and release 8.3.1. I
>> > >> > am volunteering as RM for this.
>> > >> > Any thoughts?
>> > >> > Regards,
>> > >> > Ishan
>> > >> >
>> > >> > -
>> > >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> > >> > 
>> > >> > For additional commands, e-mail: dev-h...@lucene.apache.org 
>> > >> > 
>> > >> >
>> > >>
>> > >>
>> > >> --
>> > >> -
>> > >> Noble Paul
>> > >>
>> > >> -
>> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> > >> 
>> > >> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> > >> 
>> > >>
>> > >
>> > >
>> > > --
>> > > Regards,
>> > > Shalin Shekhar Mangar.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> > 
>> > For additional commands, e-mail: dev-h...@lucene.apache.org 
>> > 
>> >
>> 
>> 
>> -- 
>> Adrien
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> 
>> 
>

Re: 8.3.1 release

2019-11-26 Thread Jan Høydahl

I'll back port SOLR-13905

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 26. nov. 2019 kl. 13:40 skrev Ishan Chattopadhyaya 
> :
> 
> I'll start building the artifacts in 8-12 hours. If there are any issues 
> someone wants to (or wants me to) backport, please feel free.
> Regards,
> Ishan
> 
> On Mon, 25 Nov, 2019, 6:33 PM Adrien Grand,  > wrote:
> It looks worth shipping a bugfix release indeed, +1.
> 
> On Mon, Nov 25, 2019 at 2:02 PM Jason Gerlowski  > wrote:
> >
> > +1
> >
> > On Mon, Nov 25, 2019 at 4:19 AM Shalin Shekhar Mangar
> > mailto:shalinman...@gmail.com>> wrote:
> > >
> > > +1
> > >
> > > On Mon, Nov 25, 2019 at 11:20 AM Noble Paul  > > > wrote:
> > >>
> > >> +1
> > >>
> > >> On Mon, Nov 25, 2019 at 4:49 PM Ishan Chattopadhyaya
> > >> mailto:ichattopadhy...@gmail.com>> wrote:
> > >> >
> > >> > Hi,
> > >> > Recently, Colvin has reported
> > >> > https://issues.apache.org/jira/browse/SOLR-13963 
> > >> > . Effect of this is
> > >> > that Solr 8.3 must not be used out of the box due to the reported data
> > >> > loss. I propose we fix this as soon as possible and release 8.3.1. I
> > >> > am volunteering as RM for this.
> > >> > Any thoughts?
> > >> > Regards,
> > >> > Ishan
> > >> >
> > >> > -
> > >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > >> > 
> > >> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > >> > 
> > >> >
> > >>
> > >>
> > >> --
> > >> -
> > >> Noble Paul
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > >> 
> > >> For additional commands, e-mail: dev-h...@lucene.apache.org 
> > >> 
> > >>
> > >
> > >
> > > --
> > > Regards,
> > > Shalin Shekhar Mangar.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > 
> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > 
> >
> 
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
>

Re: 8.3.1 release

2019-11-26 Thread Alan Woodward

This is done, thanks Ishan

> On 26 Nov 2019, at 13:25, Ishan Chattopadhyaya  
> wrote:
> 
> Sure Alan, please go ahead.
> 
> On Tue, 26 Nov, 2019, 6:52 PM Alan Woodward,  > wrote:
> I’d like to backport LUCENE-9050
> 
>> On 26 Nov 2019, at 12:40, Ishan Chattopadhyaya > > wrote:
>> 
>> I'll start building the artifacts in 8-12 hours. If there are any issues 
>> someone wants to (or wants me to) backport, please feel free.
>> Regards,
>> Ishan
>> 
>> On Mon, 25 Nov, 2019, 6:33 PM Adrien Grand, > > wrote:
>> It looks worth shipping a bugfix release indeed, +1.
>> 
>> On Mon, Nov 25, 2019 at 2:02 PM Jason Gerlowski > > wrote:
>> >
>> > +1
>> >
>> > On Mon, Nov 25, 2019 at 4:19 AM Shalin Shekhar Mangar
>> > mailto:shalinman...@gmail.com>> wrote:
>> > >
>> > > +1
>> > >
>> > > On Mon, Nov 25, 2019 at 11:20 AM Noble Paul > > > > wrote:
>> > >>
>> > >> +1
>> > >>
>> > >> On Mon, Nov 25, 2019 at 4:49 PM Ishan Chattopadhyaya
>> > >> mailto:ichattopadhy...@gmail.com>> wrote:
>> > >> >
>> > >> > Hi,
>> > >> > Recently, Colvin has reported
>> > >> > https://issues.apache.org/jira/browse/SOLR-13963 
>> > >> > . Effect of this is
>> > >> > that Solr 8.3 must not be used out of the box due to the reported data
>> > >> > loss. I propose we fix this as soon as possible and release 8.3.1. I
>> > >> > am volunteering as RM for this.
>> > >> > Any thoughts?
>> > >> > Regards,
>> > >> > Ishan
>> > >> >
>> > >> > -
>> > >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> > >> > 
>> > >> > For additional commands, e-mail: dev-h...@lucene.apache.org 
>> > >> > 
>> > >> >
>> > >>
>> > >>
>> > >> --
>> > >> -
>> > >> Noble Paul
>> > >>
>> > >> -
>> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> > >> 
>> > >> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> > >> 
>> > >>
>> > >
>> > >
>> > > --
>> > > Regards,
>> > > Shalin Shekhar Mangar.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> > 
>> > For additional commands, e-mail: dev-h...@lucene.apache.org 
>> > 
>> >
>> 
>> 
>> -- 
>> Adrien
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> 
>> 
>

Re: Commit / Code Review Policy

2019-11-26 Thread Michael Sokolov

I think the recent replies seem to be in response to the existing
document (CommitPolicy), but what David is proposing is to completely
rewrite that document into something (his words) "unrecognizable"? So
I'll hold off on commenting until we've seen the actual proposal?

-Mike

On Tue, Nov 26, 2019 at 12:35 AM David Smiley  wrote:
>
> Last Wednesday at a Solr committers meeting, there was general agreement in 
> attendance to raise the bar for commit permission to require another's 
> consent, which might not have entailed a review of the code.  I volunteered 
> to draft a proposal.  Other things distracted me but I'm finally thinking of 
> this task now.  *This email is NOT the proposal*.
>
> I was about to write something from scratch when I discovered we already have 
> some internal documentation on a commit policy that is both reasonably well 
> written/composed and the actual policy/information is pretty good -- kudos to 
> the mystery author!
>
> https://cwiki.apache.org/confluence/display/SOLR/CommitPolicy
>
> I'd prefer we have one "Commit Policy" document for Lucene/Solr and only call 
> out Solr specifics when applicable.  This is easier to maintain and is in 
> line with the joint-ness of Lucene TLP.  So I think it should move to the 
> Lucene cwiki.  Granted there is a possibility this kind of content might move 
> into our source control somewhere but that possibility is a subject for 
> another day.
>
> I plan to copy this to Lucene, mark as PROPOSAL and then make some large 
> edits.  The diff will probably be kinda unrecognizable despite it being in 
> nice shape now.  A "Commit Policy" is more broad that a "Code Review Policy"; 
> it could cover a variety of things.  For example when to commit without even 
> filing a JIRA issue, which I think is worth mentioning.  It should probably 
> also cover Git considerations like merge vs rebase, and multiple commits vs 
> squashing.  Maybe we should also cover when to bother adding to CHANGES.txt 
> and "via"?  Probably commit message requirements.  Snowballing scope :-). 
> Probably not JIRA metadata as it's not part of the commit to be part of a 
> commit policy, but _somewhere_ that's needed.  I'm not sure I want to  sign 
> up for all that now but at least for the code review subject.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley

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

Re: Commit / Code Review Policy

2019-11-26 Thread Joel Bernstein

I think more is needed going forward.

What I would like to see is an explicit "risks" section of the jira that
shows the committer has thought about the different risks to the system
before committing code that effects the core. The committer should take
time to understand what part of the system might be effected. This will do
two things:

1) Force the committer to think more about how there change affects the
rest of the system.
2) Helps other committers understand the risks so that there is more
incentive to get involved and test.





Joel Bernstein
http://joelsolr.blogspot.com/


On Tue, Nov 26, 2019 at 4:26 AM Atri Sharma  wrote:

> +1
>
> I am generally wary of such proposals since they tend to impose hard
> processes in the places where trust should be dominant instead.
>
> Apart from that, LGTM
>
> On Tue, 26 Nov 2019 at 14:46, Adrien Grand  wrote:
>
>> This document looks reasonable to me and a good description of the way
>> changes get merged today. Something it says between the lines and that
>> is the most important bit to me is that this isn't really a policy but
>> rather a set of guidelines, and that we trust each other to do the
>> right thing. Maybe we could better reflect this in the name, e.g.
>> "Commit/Merging guidelines".
>>
>> On Tue, Nov 26, 2019 at 6:34 AM David Smiley 
>> wrote:
>> >
>> > Last Wednesday at a Solr committers meeting, there was general
>> agreement in attendance to raise the bar for commit permission to require
>> another's consent, which might not have entailed a review of the code.  I
>> volunteered to draft a proposal.  Other things distracted me but I'm
>> finally thinking of this task now.  *This email is NOT the proposal*.
>> >
>> > I was about to write something from scratch when I discovered we
>> already have some internal documentation on a commit policy that is both
>> reasonably well written/composed and the actual policy/information is
>> pretty good -- kudos to the mystery author!
>> >
>> > https://cwiki.apache.org/confluence/display/SOLR/CommitPolicy
>> >
>> > I'd prefer we have one "Commit Policy" document for Lucene/Solr and
>> only call out Solr specifics when applicable.  This is easier to maintain
>> and is in line with the joint-ness of Lucene TLP.  So I think it should
>> move to the Lucene cwiki.  Granted there is a possibility this kind of
>> content might move into our source control somewhere but that possibility
>> is a subject for another day.
>> >
>> > I plan to copy this to Lucene, mark as PROPOSAL and then make some
>> large edits.  The diff will probably be kinda unrecognizable despite it
>> being in nice shape now.  A "Commit Policy" is more broad that a "Code
>> Review Policy"; it could cover a variety of things.  For example when to
>> commit without even filing a JIRA issue, which I think is worth
>> mentioning.  It should probably also cover Git considerations like merge vs
>> rebase, and multiple commits vs squashing.  Maybe we should also cover when
>> to bother adding to CHANGES.txt and "via"?  Probably commit message
>> requirements.  Snowballing scope :-). Probably not JIRA metadata as it's
>> not part of the commit to be part of a commit policy, but _somewhere_
>> that's needed.  I'm not sure I want to  sign up for all that now but at
>> least for the code review subject.
>> >
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley
>>
>>
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
> Regards,
>
> Atri
> Apache Concerted
>

Re: 8.3.1 release

2019-11-26 Thread Ishan Chattopadhyaya

Sure Alan, please go ahead.

On Tue, 26 Nov, 2019, 6:52 PM Alan Woodward,  wrote:

> I’d like to backport LUCENE-9050
>
> On 26 Nov 2019, at 12:40, Ishan Chattopadhyaya 
> wrote:
>
> I'll start building the artifacts in 8-12 hours. If there are any issues
> someone wants to (or wants me to) backport, please feel free.
> Regards,
> Ishan
>
> On Mon, 25 Nov, 2019, 6:33 PM Adrien Grand,  wrote:
>
>> It looks worth shipping a bugfix release indeed, +1.
>>
>> On Mon, Nov 25, 2019 at 2:02 PM Jason Gerlowski 
>> wrote:
>> >
>> > +1
>> >
>> > On Mon, Nov 25, 2019 at 4:19 AM Shalin Shekhar Mangar
>> >  wrote:
>> > >
>> > > +1
>> > >
>> > > On Mon, Nov 25, 2019 at 11:20 AM Noble Paul 
>> wrote:
>> > >>
>> > >> +1
>> > >>
>> > >> On Mon, Nov 25, 2019 at 4:49 PM Ishan Chattopadhyaya
>> > >>  wrote:
>> > >> >
>> > >> > Hi,
>> > >> > Recently, Colvin has reported
>> > >> > https://issues.apache.org/jira/browse/SOLR-13963. Effect of this
>> is
>> > >> > that Solr 8.3 must not be used out of the box due to the reported
>> data
>> > >> > loss. I propose we fix this as soon as possible and release 8.3.1.
>> I
>> > >> > am volunteering as RM for this.
>> > >> > Any thoughts?
>> > >> > Regards,
>> > >> > Ishan
>> > >> >
>> > >> >
>> -
>> > >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > >> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> > >> >
>> > >>
>> > >>
>> > >> --
>> > >> -
>> > >> Noble Paul
>> > >>
>> > >> -
>> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> > >>
>> > >
>> > >
>> > > --
>> > > Regards,
>> > > Shalin Shekhar Mangar.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> --
>> Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

Re: 8.3.1 release

2019-11-26 Thread Alan Woodward

I’d like to backport LUCENE-9050

> On 26 Nov 2019, at 12:40, Ishan Chattopadhyaya  > wrote:
> 
> I'll start building the artifacts in 8-12 hours. If there are any issues 
> someone wants to (or wants me to) backport, please feel free.
> Regards,
> Ishan
> 
> On Mon, 25 Nov, 2019, 6:33 PM Adrien Grand,  > wrote:
> It looks worth shipping a bugfix release indeed, +1.
> 
> On Mon, Nov 25, 2019 at 2:02 PM Jason Gerlowski  > wrote:
> >
> > +1
> >
> > On Mon, Nov 25, 2019 at 4:19 AM Shalin Shekhar Mangar
> > mailto:shalinman...@gmail.com>> wrote:
> > >
> > > +1
> > >
> > > On Mon, Nov 25, 2019 at 11:20 AM Noble Paul  > > > wrote:
> > >>
> > >> +1
> > >>
> > >> On Mon, Nov 25, 2019 at 4:49 PM Ishan Chattopadhyaya
> > >> mailto:ichattopadhy...@gmail.com>> wrote:
> > >> >
> > >> > Hi,
> > >> > Recently, Colvin has reported
> > >> > https://issues.apache.org/jira/browse/SOLR-13963 
> > >> > . Effect of this is
> > >> > that Solr 8.3 must not be used out of the box due to the reported data
> > >> > loss. I propose we fix this as soon as possible and release 8.3.1. I
> > >> > am volunteering as RM for this.
> > >> > Any thoughts?
> > >> > Regards,
> > >> > Ishan
> > >> >
> > >> > -
> > >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > >> > 
> > >> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > >> > 
> > >> >
> > >>
> > >>
> > >> --
> > >> -
> > >> Noble Paul
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > >> 
> > >> For additional commands, e-mail: dev-h...@lucene.apache.org 
> > >> 
> > >>
> > >
> > >
> > > --
> > > Regards,
> > > Shalin Shekhar Mangar.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > 
> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > 
> >
> 
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
>

Re: Understanding lucene unique fields

2019-11-26 Thread Thomas Matthijs

The doc id not global:

new SimpleCollector() {
private LeafReaderContext context;
@Override
public void collect(final int doc) throws IOException {
// 
ids.add(indexSearcher.doc(doc).getField(ID_FIELD_NAME).stringValue());


ids.add(context.reader().document(doc).getField(ID_FIELD_NAME).stringValue());
// OR
ids.add(indexSearcher.doc(context.docBase +
doc).getField(ID_FIELD_NAME).stringValue());
}
@Override
protected void doSetNextReader(LeafReaderContext context) throws
IOException {
this.context = context;
}
@Override
public ScoreMode scoreMode() {
return ScoreMode.TOP_SCORES;
}
}

On Tue, 26 Nov 2019 at 14:00, Joan LLuís Planas Papió
 wrote:
>
> Hello,
>
> I'm trying to understand why i'm getting duplicated results in the attached 
> java code.
> Debugging the code it seems that they come from differents segments. 
> Increasing the RAMBufferSizeMB to a level that all the docs are in the same 
> segment seems to return only unique numbers.
>
> There is any way to get unique documents in a bulk query without having to 
> cache then in a memory structure?
>
> Thanks in advance!!
>
> -
> 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

Understanding lucene unique fields

2019-11-26 Thread Joan LLuís Planas Papió

Hello,

I'm trying to understand why i'm getting duplicated results in the attached
java code.
Debugging the code it seems that they come from differents segments.
Increasing the RAMBufferSizeMB to a level that all the docs are in the same
segment seems to return only unique numbers.

There is any way to get unique documents in a bulk query without having to
cache then in a memory structure?

Thanks in advance!!
package com.king.lucifer.lucene;

import java.io.IOException;
import java.nio.file.Paths;
import java.util.HashSet;
import java.util.Set;

import org.apache.lucene.analysis.standard.StandardAnalyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.document.StringField;
import org.apache.lucene.index.IndexWriter;
import org.apache.lucene.index.IndexWriterConfig;
import org.apache.lucene.index.Term;
import org.apache.lucene.search.IndexSearcher;
import org.apache.lucene.search.MatchAllDocsQuery;
import org.apache.lucene.search.Query;
import org.apache.lucene.search.ScoreMode;
import org.apache.lucene.search.SearcherManager;
import org.apache.lucene.search.SimpleCollector;
import org.apache.lucene.store.FSDirectory;
import org.apache.lucene.store.MMapDirectory;

public class NumbersExample {

public static void main(String[] args) throws IOException {
new NumbersExample().run();
}

private void run() throws IOException {
FSDirectory dir = MMapDirectory.open(Paths.get("luceneTest"));
IndexWriterConfig config = new IndexWriterConfig(new StandardAnalyzer());
config.setOpenMode(IndexWriterConfig.OpenMode.CREATE_OR_APPEND);
IndexWriter indexWriter = new IndexWriter(dir, config);
SearcherManager searcherManager = new SearcherManager(indexWriter, null);

long baseId = 9906843115L;
int numberOfUniqueIds = 1_000_000;
String ID_FIELD_NAME = "id";

for (long id = 0; id < numberOfUniqueIds; id++) {
String finalId = String.valueOf(baseId + id);
Term term = new Term(ID_FIELD_NAME, finalId);
Document document = new Document();
document.add(new StringField(ID_FIELD_NAME, finalId, Field.Store.YES));
indexWriter.updateDocument(term, document);
}
searcherManager.maybeRefreshBlocking();

IndexSearcher indexSearcher = searcherManager.acquire();
Query luceneQuery = new MatchAllDocsQuery();
Set ids = new HashSet<>();
indexSearcher.search(luceneQuery, new SimpleCollector() {

@Override
public void collect(final int doc) throws IOException {
ids.add(indexSearcher.doc(doc).getField(ID_FIELD_NAME).stringValue());
}

@Override
public ScoreMode scoreMode() {
return ScoreMode.TOP_SCORES;
}
});

System.out.println(ids.size());
}
}

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

Re: 8.3.1 release

2019-11-26 Thread Ishan Chattopadhyaya

I'll start building the artifacts in 8-12 hours. If there are any issues
someone wants to (or wants me to) backport, please feel free.
Regards,
Ishan

On Mon, 25 Nov, 2019, 6:33 PM Adrien Grand,  wrote:

> It looks worth shipping a bugfix release indeed, +1.
>
> On Mon, Nov 25, 2019 at 2:02 PM Jason Gerlowski 
> wrote:
> >
> > +1
> >
> > On Mon, Nov 25, 2019 at 4:19 AM Shalin Shekhar Mangar
> >  wrote:
> > >
> > > +1
> > >
> > > On Mon, Nov 25, 2019 at 11:20 AM Noble Paul 
> wrote:
> > >>
> > >> +1
> > >>
> > >> On Mon, Nov 25, 2019 at 4:49 PM Ishan Chattopadhyaya
> > >>  wrote:
> > >> >
> > >> > Hi,
> > >> > Recently, Colvin has reported
> > >> > https://issues.apache.org/jira/browse/SOLR-13963. Effect of this is
> > >> > that Solr 8.3 must not be used out of the box due to the reported
> data
> > >> > loss. I propose we fix this as soon as possible and release 8.3.1. I
> > >> > am volunteering as RM for this.
> > >> > Any thoughts?
> > >> > Regards,
> > >> > Ishan
> > >> >
> > >> >
> -
> > >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > >> > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >> >
> > >>
> > >>
> > >> --
> > >> -
> > >> Noble Paul
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > >> For additional commands, e-mail: dev-h...@lucene.apache.org
> > >>
> > >
> > >
> > > --
> > > Regards,
> > > Shalin Shekhar Mangar.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Commit / Code Review Policy

2019-11-26 Thread Atri Sharma

+1

I am generally wary of such proposals since they tend to impose hard
processes in the places where trust should be dominant instead.

Apart from that, LGTM

On Tue, 26 Nov 2019 at 14:46, Adrien Grand  wrote:

> This document looks reasonable to me and a good description of the way
> changes get merged today. Something it says between the lines and that
> is the most important bit to me is that this isn't really a policy but
> rather a set of guidelines, and that we trust each other to do the
> right thing. Maybe we could better reflect this in the name, e.g.
> "Commit/Merging guidelines".
>
> On Tue, Nov 26, 2019 at 6:34 AM David Smiley 
> wrote:
> >
> > Last Wednesday at a Solr committers meeting, there was general agreement
> in attendance to raise the bar for commit permission to require another's
> consent, which might not have entailed a review of the code.  I volunteered
> to draft a proposal.  Other things distracted me but I'm finally thinking
> of this task now.  *This email is NOT the proposal*.
> >
> > I was about to write something from scratch when I discovered we already
> have some internal documentation on a commit policy that is both reasonably
> well written/composed and the actual policy/information is pretty good --
> kudos to the mystery author!
> >
> > https://cwiki.apache.org/confluence/display/SOLR/CommitPolicy
> >
> > I'd prefer we have one "Commit Policy" document for Lucene/Solr and only
> call out Solr specifics when applicable.  This is easier to maintain and is
> in line with the joint-ness of Lucene TLP.  So I think it should move to
> the Lucene cwiki.  Granted there is a possibility this kind of content
> might move into our source control somewhere but that possibility is a
> subject for another day.
> >
> > I plan to copy this to Lucene, mark as PROPOSAL and then make some large
> edits.  The diff will probably be kinda unrecognizable despite it being in
> nice shape now.  A "Commit Policy" is more broad that a "Code Review
> Policy"; it could cover a variety of things.  For example when to commit
> without even filing a JIRA issue, which I think is worth mentioning.  It
> should probably also cover Git considerations like merge vs rebase, and
> multiple commits vs squashing.  Maybe we should also cover when to bother
> adding to CHANGES.txt and "via"?  Probably commit message requirements.
> Snowballing scope :-). Probably not JIRA metadata as it's not part of the
> commit to be part of a commit policy, but _somewhere_ that's needed.  I'm
> not sure I want to  sign up for all that now but at least for the code
> review subject.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
>
>
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Regards,

Atri
Apache Concerted

Re: Commit / Code Review Policy

2019-11-26 Thread Adrien Grand

This document looks reasonable to me and a good description of the way
changes get merged today. Something it says between the lines and that
is the most important bit to me is that this isn't really a policy but
rather a set of guidelines, and that we trust each other to do the
right thing. Maybe we could better reflect this in the name, e.g.
"Commit/Merging guidelines".

On Tue, Nov 26, 2019 at 6:34 AM David Smiley  wrote:
>
> Last Wednesday at a Solr committers meeting, there was general agreement in 
> attendance to raise the bar for commit permission to require another's 
> consent, which might not have entailed a review of the code.  I volunteered 
> to draft a proposal.  Other things distracted me but I'm finally thinking of 
> this task now.  *This email is NOT the proposal*.
>
> I was about to write something from scratch when I discovered we already have 
> some internal documentation on a commit policy that is both reasonably well 
> written/composed and the actual policy/information is pretty good -- kudos to 
> the mystery author!
>
> https://cwiki.apache.org/confluence/display/SOLR/CommitPolicy
>
> I'd prefer we have one "Commit Policy" document for Lucene/Solr and only call 
> out Solr specifics when applicable.  This is easier to maintain and is in 
> line with the joint-ness of Lucene TLP.  So I think it should move to the 
> Lucene cwiki.  Granted there is a possibility this kind of content might move 
> into our source control somewhere but that possibility is a subject for 
> another day.
>
> I plan to copy this to Lucene, mark as PROPOSAL and then make some large 
> edits.  The diff will probably be kinda unrecognizable despite it being in 
> nice shape now.  A "Commit Policy" is more broad that a "Code Review Policy"; 
> it could cover a variety of things.  For example when to commit without even 
> filing a JIRA issue, which I think is worth mentioning.  It should probably 
> also cover Git considerations like merge vs rebase, and multiple commits vs 
> squashing.  Maybe we should also cover when to bother adding to CHANGES.txt 
> and "via"?  Probably commit message requirements.  Snowballing scope :-). 
> Probably not JIRA metadata as it's not part of the commit to be part of a 
> commit policy, but _somewhere_ that's needed.  I'm not sure I want to  sign 
> up for all that now but at least for the code review subject.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley



-- 
Adrien

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

Re: Commit / Code Review Policy

2019-11-26 Thread Jan Høydahl

Mystery authors seem to be
- Hoss 
https://web.archive.org/web/20071011105632/http://wiki.apache.org/solr/CommitPolicy
 

- Grant 
https://web.archive.org/web/20090504015648/http://wiki.apache.org/solr/CommitPolicy
 

- Myself 
https://web.archive.org/web/2019003001/http://wiki.apache.org/solr/CommitPolicy
 

 :)

This should probably be part of the new Dev Guide? But go ahead draft in in 
Confluence first!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 26. nov. 2019 kl. 06:34 skrev David Smiley :
> 
> Last Wednesday at a Solr committers meeting, there was general agreement in 
> attendance to raise the bar for commit permission to require another's 
> consent, which might not have entailed a review of the code.  I volunteered 
> to draft a proposal.  Other things distracted me but I'm finally thinking of 
> this task now.  *This email is NOT the proposal*. 
> 
> I was about to write something from scratch when I discovered we already have 
> some internal documentation on a commit policy that is both reasonably well 
> written/composed and the actual policy/information is pretty good -- kudos to 
> the mystery author!
> 
> https://cwiki.apache.org/confluence/display/SOLR/CommitPolicy 
> 
> 
> I'd prefer we have one "Commit Policy" document for Lucene/Solr and only call 
> out Solr specifics when applicable.  This is easier to maintain and is in 
> line with the joint-ness of Lucene TLP.  So I think it should move to the 
> Lucene cwiki.  Granted there is a possibility this kind of content might move 
> into our source control somewhere but that possibility is a subject for 
> another day.
> 
> I plan to copy this to Lucene, mark as PROPOSAL and then make some large 
> edits.  The diff will probably be kinda unrecognizable despite it being in 
> nice shape now.  A "Commit Policy" is more broad that a "Code Review Policy"; 
> it could cover a variety of things.  For example when to commit without even 
> filing a JIRA issue, which I think is worth mentioning.  It should probably 
> also cover Git considerations like merge vs rebase, and multiple commits vs 
> squashing.  Maybe we should also cover when to bother adding to CHANGES.txt 
> and "via"?  Probably commit message requirements.  Snowballing scope :-). 
> Probably not JIRA metadata as it's not part of the commit to be part of a 
> commit policy, but _somewhere_ that's needed.  I'm not sure I want to  sign 
> up for all that now but at least for the code review subject.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
>

RV: Solr 8.2 with maven

2019-11-26 Thread Carmen Márquez Vázquez


Hi, I am running Solr 8.2 on a Maven project.
When opening my project in the browser, it shows the following console error:
java.lang.NoClassDefFoundError: Could not initialize class 
org.apache.solr.util.tracing.GlobalTracer

I have seen that class must be found in the dependency:

 org.apache.solr 
 solr-core 
 8.2.0 


I have it included in the pom.xml but still giving error.
I need help.
Thank you

Re: Closing GitHub PRs

Re: 8.3.1 release

Closing GitHub PRs

Re: 8.3.1 release

Re: 8.3.1 release

Re: 8.3.1 release

Re: 8.3.1 release

Re: Commit / Code Review Policy

Re: Commit / Code Review Policy

Re: 8.3.1 release

Re: 8.3.1 release

Re: Understanding lucene unique fields

Understanding lucene unique fields

Re: 8.3.1 release

Re: Commit / Code Review Policy

Re: Commit / Code Review Policy

Re: Commit / Code Review Policy

RV: Solr 8.2 with maven

18 matches

Site Navigation

Mail list logo

Footer information