Re: Old programmers do fade away

[Otis Gospodnetić]

Hi Erick,

Thank you for this email.  Wow, 40 years!  I was always intrigued by your
programming longevity!  Thank you for all your contributions.  Any sailing
still going on?  Enjoy part 2 :)

Otis
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticsearch Consulting Support Training - https://sematext.com/



On Wed, Dec 30, 2020 at 9:09 AM Erick Erickson 
wrote:

> 40 years is enough. OK, it's only been 39 1/2 years. Dear Lord, has it
> really been that long? Programming's been fun, I've gotten to solve puzzles
> every day. The art and science of programming has changed over that time.
> Let me tell you about the joys of debugging with a Z80 stack emulator that
> required that you to look on the stack for variables and trace function
> calls by knowing how to follow frame pointers. Oh the tedium! Oh the (lack
> of) speed! Not to mention that 64K of memory was all you had to work with.
> I had a co-worker who could predict the number of bytes by which the
> program would shrink based on extracting common code to functions. The
> "good old days"...weren't...
>
> I'd been thinking that I'd treat Lucene/Solr as a hobby, doing occasional
> work on it when I was bored over long winter nights. I've discovered,
> though, that I've been increasingly reluctant to crack open the code. I
> guess that after this much time, I'm ready to hang up my spurs. One major
> factor is the realization that there's so much going on with Lucene/Solr
> that simply being aware of the changes, much less trying to really
> understand them, isn't something I can do casually.
>
> I bought a welder and find myself more interested in playing with that
> than programming. Wait until you see the squirrel-proof garden enclosure
> I'm building with it. If my initial plan doesn't work, next up is an
> electric fence along the top. The laser-sighted automatic machine gun
> emplacement will take more planning...Ahhh, probably won't be able to get a
> permit from the township for that though. Do you think the police would
> notice? Perhaps I should add that the local police station is two blocks
> away and in the line of fire. But an infrared laser powerful enough to
> "pre-cook" them wouldn't be as obvious would it?
>
> Why am I so fixated on squirrels? One of the joys of gardening is fresh
> tomatoes rather than those red things they sell in the store. The squirrels
> ATE EVERY ONE OF MY TOMATOES WHILE THEY WERE STILL GREEN LAST YEAR! And the
> melons. In the words of B. Bunny: "Of course you realize this means war" (
> https://www.youtube.com/watch?v=4XNr-BQgpd0)...
>
> Then there's working in the garden and landscaping, the desk I want to
> build for my wife, travel as soon as I can, maybe seeing if some sailboats
> need crew...you get the idea.
>
> It's been a privilege to work with this group, you're some of the best and
> brightest. Many thanks to all who've generously given me their time and
> guidance. It's been a constant source of amazement to me how willing people
> are to take time out of their own life and work to help me when I've had
> questions. I owe a lot of people beers ;)
>
> I'll be stopping my list subscriptions, Slack channels (dm me if you need
> something), un-assigning any JIRAs and that kind of thing over the next
> while. If anyone's interested in taking over the BadApple report, let me
> know and I can put the code up somewhere. It takes about 10 minutes to do
> each week. I won't disappear entirely, things like the code-reformatting
> effort are nicely self-contained for instance and something I can to
> casually.
>
> My e-mail address if you need to get in touch with me is: "
> erick.erick...@gmail.com". There's a correlation between gmail addresses
> that are just a name with no numbers and a person's age... A co-worker came
> over to my desk in pre-historical times and said "there's this new mail
> service you might want to sign up for"... Like I said, 40 years is enough.
>
> Best to all,
> Erick
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: 8.8 Release

[Timothy Potter]

Thanks for following up on this Ishan ... I intend to get SOLR-15059 and
-15036 into 8.8 as well. I should have a proper PR up for SOLR-15036 by
Friday sometime, which seems to align with other's timeframes

Cheers,
Tim

On Wed, Jan 6, 2021 at 6:54 AM David Smiley  wrote:

> Happy New Year!
> I would much prefer that ensure 8.8 includes SOLR-14923 (a bad nested docs
> performance issue)
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Jan 6, 2021 at 6:59 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Happy New Year!
>>
>> I was supposed to start the process tomorrow, but I think we're not ready
>> yet? I see SOLR-15052 still under review with intention of inclusion into
>> 8.8.
>> Would it be reasonable to cut the release branch end of this week and
>> start the RC process around 13th January?
>> If there are any issues someone would want me to wait on, please let me
>> know.
>>
>> Thanks,
>> Ishan
>>
>> On Fri, Dec 18, 2020 at 6:10 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Sure, Houston. I'll wait another week. Have a good new year and merry
>>> Christmas!
>>>
>>> On Fri, 18 Dec, 2020, 5:58 am Timothy Potter, 
>>> wrote:
>>>
 Great point Houston! +1 on waiting until a week into January

 On Thu, Dec 17, 2020 at 4:46 PM Houston Putman 
 wrote:

> Thanks for volunteering Ishan.
>
> I think it might be a good idea to wait to cut and release 8.8 at
> least a week into January. Many people are going to be away during the
> holiday season, and particularly the last week of the year. Pushing into
> January just gives more people a chance to look at the release and be
> involved.
>
> - Houston
>
> On Fri, Dec 11, 2020 at 3:26 PM Noble Paul 
> wrote:
>
>> Thanks Ishan for volunteering
>>
>> On Fri, Dec 11, 2020 at 5:07 AM Christine Poerschke (BLOOMBERG/
>> LONDON)  wrote:
>> >
>> > With a view towards including it in the release, I'd appreciate
>> code review input on
>> >
>> > https://github.com/apache/lucene-solr/pull/1992 for
>> >
>> > https://issues.apache.org/jira/browse/SOLR-14939 (JSON facets:
>> range faceting to support cache=false parameter)
>> >
>> > if anyone has some time next week perhaps?
>> >
>> > Thanks in advance!
>> >
>> > Christine
>> >
>> > From: dev@lucene.apache.org At: 12/10/20 18:01:58
>> > To: dev@lucene.apache.org
>> > Subject: Re: 8.8 Release
>> >
>> > +1
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>> >
>> > On Thu, Dec 10, 2020 at 11:23 AM David Smiley 
>> wrote:
>> >>
>> >> Thanks for volunteering!
>> >>
>> >> On Thu, Dec 10, 2020 at 11:11 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >>>
>> >>> Hi Devs,
>> >>> There are lots of changes accumulated and some underway. I wish
>> to volunteer for a 8.8 release, if there are no objections. I'm planning 
>> to
>> build the RC in three weeks, i.e. 31 December (and cut the branch about 
>> 3-4
>> days before that). Please let me know if someone has any concerns.
>> >>> Thanks and regards,
>> >>> Ishan
>> >>>
>> >> --
>> >> Sent from Gmail Mobile
>> >
>> >
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: RFC: N-2 compatibility for file formats

[Yonik Seeley]

On Wed, Jan 6, 2021 at 4:40 AM Simon Willnauer 
wrote:

>  You can open a reader on an index created by
> version N-2, but you cannot open an IndexWriter on it
>

+1
There should definitely be more consideration given to back compat in
general... it's caused a ton of pain to users over time.

-Yonik

Re: RFC: N-2 compatibility for file formats

[Dawid Weiss]

I see a more difficult problem in the opposite - say, a new Query that
requires something from
the index that older indexes (codecs) don't have. Then running such a query
would result in, I assume,
an exception? Things get awkward when you have existing systems that wish
to gradually upgrade
so that some segments are in older codecs and newer segments are in newer
codecs.

But in general I'm quite ok with keeping N-2 compatibility if it's not too
much trouble.

D.

On Wed, Jan 6, 2021 at 4:21 PM Michael Sokolov  wrote:

> In practice what would this mean? We relax the restriction that David
> mentions, and we keep old codecs around in backwards-codecs for two
> major releases instead of one? Are there other implications? Suppose
> we had a Query that relied on a specific index format, which gets
> retired. We keep the index format code around - do we also need to
> remember to maintain the old Query?
>
> -Mike
>
> On Wed, Jan 6, 2021 at 4:41 AM Simon Willnauer
>  wrote:
> >
> > Hello all,
> >
> > Currently Lucene supports reading and writing indices that have been
> > created with the current or previous (N-1) version of Lucene. Lucene
> > refuses to open an index created by N-2 or earlier versions.
> > I would like to propose that Lucene adds support for opening indices
> > created by version N-2 in read-only mode. Here's what I have in mind:
> >
> > - Read-only support. You can open a reader on an index created by
> > version N-2, but you cannot open an IndexWriter on it, meaning that
> > you can neither delete, update, add documents or force-merge N-2
> > indices.
> >
> > - File-format compatibility only. File-format compatibility enables
> > reading the content of old indices, but not more. Everything that is
> > done on top of file formats like analysis or the encoding of length
> > normalization factors is not guaranteed and only supported on a
> > best-effort basis.
> >
> > The reason I came up with these limitations is because I wanted to
> > make the scope minimal in order to retain Lucene's ability to move
> > forward. If there is consensus to move forward with this, I would like
> > to target Lucene 9.0 with this change.
> >
> > Simon
> >
> > -
> > 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: additional term meta data

[John Wang]

Thank you, Martin!

You can apply the patch to the 8.7 build by just ignoring the changes to
Lucene90xxx. Appreciate the help and guidance!

-John


On Wed, Jan 6, 2021 at 10:36 AM Martin Gainty  wrote:

> appears you are targeting 9.0 for your code
>
> lucene/core/src/java/org/apache/lucene/codecs/lucene90/Lucene90FieldInfosFormat.java
> 
> (Lucene90FIeldInfosFormat.java is not contained in either 8.4 or 8.7
> distros)
>
> 
> someone had the bright idea to nuke ant 8.x build.xml without consulting
> anyone
> not a fan of ant but the execution model of gradle is woefully inflexible
> in comparison to maven
> 
>
> i will try with 90 distro to get the
> codecs/lucene90/Lucene90FieldInfosFormat and recompile and hopefully your
> TestLucene84PostingsFormat will run w/o fail or error
>
> Thx
> martin-
>
> --
> *From:* John Wang 
> *Sent:* Wednesday, January 6, 2021 10:15 AM
> *To:* dev@lucene.apache.org 
> *Subject:* Re: additional term meta data
>
> Hey Martin:
>
> There is a test case in the PR we created on our own fork:
> https://github.com/dashbase/lucene-solr/pull/1, which also contains some
> example code on how to access in the PR description.
>
> Here is the link to the beginning of the tests:
> https://github.com/dashbase/lucene-solr/blob/posting-last-docid/lucene/core/src/test/org/apache/lucene/codecs/lucene84/TestLucene84PostingsFormat.java#L142
>
> I am not sure which version this should be applied to, currently, it was
> based on master as of a few days ago. We intend to patch 8.7 for our own
> environment.
>
> Any advice or feedback is much appreciated.
>
> Thank you!
>
> -John
>
> On Wed, Jan 6, 2021 at 3:28 AM Martin Gainty  wrote:
>
> how to access first and last?
> which version will you be merging
>
> --
> *From:* John Wang 
> *Sent:* Tuesday, January 5, 2021 8:19 PM
> *To:* dev@lucene.apache.org 
> *Subject:* additional term meta data
>
> Hi folks:
>
> We like to propose a feature to add additional per-term metadata to the
> term diction.
>
> Currently, the TermsEnum API returns docFreq as its only meta-data. We
> needed a way to quickly get the first and last doc id in the postings
> without having to scan through the entire postings list.
>
> We have created a PR on our own fork and we would like to contribute this
> back to the community. Please let us know if this is something that's
> useful and/or fits Lucene's roadmap, we would be happy to submit a patch.
>
> https://github.com/dashbase/lucene-solr/pull/1
>
> Thank you
>
> -John
>
>

Re: additional term meta data

[Martin Gainty]

appears you are targeting 9.0 for your code
lucene/core/src/java/org/apache/lucene/codecs/lucene90/Lucene90FieldInfosFormat.java
(Lucene90FIeldInfosFormat.java is not contained in either 8.4 or 8.7 distros)


someone had the bright idea to nuke ant 8.x build.xml without consulting anyone
not a fan of ant but the execution model of gradle is woefully inflexible in 
comparison to maven


i will try with 90 distro to get the codecs/lucene90/Lucene90FieldInfosFormat 
and recompile and hopefully your TestLucene84PostingsFormat will run w/o fail 
or error

Thx
martin-


From: John Wang 
Sent: Wednesday, January 6, 2021 10:15 AM
To: dev@lucene.apache.org 
Subject: Re: additional term meta data

Hey Martin:

There is a test case in the PR we created on our own fork: 
https://github.com/dashbase/lucene-solr/pull/1, which also contains some 
example code on how to access in the PR description.

Here is the link to the beginning of the tests: 
https://github.com/dashbase/lucene-solr/blob/posting-last-docid/lucene/core/src/test/org/apache/lucene/codecs/lucene84/TestLucene84PostingsFormat.java#L142

I am not sure which version this should be applied to, currently, it was based 
on master as of a few days ago. We intend to patch 8.7 for our own environment.

Any advice or feedback is much appreciated.

Thank you!

-John

On Wed, Jan 6, 2021 at 3:28 AM Martin Gainty 
mailto:mgai...@hotmail.com>> wrote:
how to access first and last?
which version will you be merging


From: John Wang mailto:john.w...@gmail.com>>
Sent: Tuesday, January 5, 2021 8:19 PM
To: dev@lucene.apache.org 
mailto:dev@lucene.apache.org>>
Subject: additional term meta data

Hi folks:

We like to propose a feature to add additional per-term metadata to the term 
diction.

Currently, the TermsEnum API returns docFreq as its only meta-data. We needed a 
way to quickly get the first and last doc id in the postings without having to 
scan through the entire postings list.

We have created a PR on our own fork and we would like to contribute this back 
to the community. Please let us know if this is something that's useful and/or 
fits Lucene's roadmap, we would be happy to submit a patch.

https://github.com/dashbase/lucene-solr/pull/1

Thank you

-John

Re: RFC: N-2 compatibility for file formats

[Michael Sokolov]

In practice what would this mean? We relax the restriction that David
mentions, and we keep old codecs around in backwards-codecs for two
major releases instead of one? Are there other implications? Suppose
we had a Query that relied on a specific index format, which gets
retired. We keep the index format code around - do we also need to
remember to maintain the old Query?

-Mike

On Wed, Jan 6, 2021 at 4:41 AM Simon Willnauer
 wrote:
>
> Hello all,
>
> Currently Lucene supports reading and writing indices that have been
> created with the current or previous (N-1) version of Lucene. Lucene
> refuses to open an index created by N-2 or earlier versions.
> I would like to propose that Lucene adds support for opening indices
> created by version N-2 in read-only mode. Here's what I have in mind:
>
> - Read-only support. You can open a reader on an index created by
> version N-2, but you cannot open an IndexWriter on it, meaning that
> you can neither delete, update, add documents or force-merge N-2
> indices.
>
> - File-format compatibility only. File-format compatibility enables
> reading the content of old indices, but not more. Everything that is
> done on top of file formats like analysis or the encoding of length
> normalization factors is not guaranteed and only supported on a
> best-effort basis.
>
> The reason I came up with these limitations is because I wanted to
> make the scope minimal in order to retain Lucene's ability to move
> forward. If there is consensus to move forward with this, I would like
> to target Lucene 9.0 with this change.
>
> Simon
>
> -
> 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: additional term meta data

[John Wang]

Hey Martin:

There is a test case in the PR we created on our own fork:
https://github.com/dashbase/lucene-solr/pull/1, which also contains some
example code on how to access in the PR description.

Here is the link to the beginning of the tests:
https://github.com/dashbase/lucene-solr/blob/posting-last-docid/lucene/core/src/test/org/apache/lucene/codecs/lucene84/TestLucene84PostingsFormat.java#L142

I am not sure which version this should be applied to, currently, it was
based on master as of a few days ago. We intend to patch 8.7 for our own
environment.

Any advice or feedback is much appreciated.

Thank you!

-John

On Wed, Jan 6, 2021 at 3:28 AM Martin Gainty  wrote:

> how to access first and last?
> which version will you be merging
>
> --
> *From:* John Wang 
> *Sent:* Tuesday, January 5, 2021 8:19 PM
> *To:* dev@lucene.apache.org 
> *Subject:* additional term meta data
>
> Hi folks:
>
> We like to propose a feature to add additional per-term metadata to the
> term diction.
>
> Currently, the TermsEnum API returns docFreq as its only meta-data. We
> needed a way to quickly get the first and last doc id in the postings
> without having to scan through the entire postings list.
>
> We have created a PR on our own fork and we would like to contribute this
> back to the community. Please let us know if this is something that's
> useful and/or fits Lucene's roadmap, we would be happy to submit a patch.
>
> https://github.com/dashbase/lucene-solr/pull/1
>
> Thank you
>
> -John
>

Re: RFC: N-2 compatibility for file formats

[David Smiley]

+1 -- Lucene should not _prevent_ this.

I forget where things stood in the past conversations about this subject...
I think most recently raised by Erick Ericson.  I recall that we don't want
to maintain the code to read older indices... which I sympathize with...
but I recall there is code that actively *blocks* you (end user) from
reading N-2 which I think goes too far, _forcing_ you to fork Lucene to
work around that.  At least a user should be able to maintain however far
back if they have their own codecs that they maintain (as I do at work).

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Jan 6, 2021 at 8:48 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Sounds great, +1
>
> On Wed, Jan 6, 2021 at 3:10 PM Simon Willnauer 
> wrote:
>
>> Hello all,
>>
>> Currently Lucene supports reading and writing indices that have been
>> created with the current or previous (N-1) version of Lucene. Lucene
>> refuses to open an index created by N-2 or earlier versions.
>> I would like to propose that Lucene adds support for opening indices
>> created by version N-2 in read-only mode. Here's what I have in mind:
>>
>> - Read-only support. You can open a reader on an index created by
>> version N-2, but you cannot open an IndexWriter on it, meaning that
>> you can neither delete, update, add documents or force-merge N-2
>> indices.
>>
>> - File-format compatibility only. File-format compatibility enables
>> reading the content of old indices, but not more. Everything that is
>> done on top of file formats like analysis or the encoding of length
>> normalization factors is not guaranteed and only supported on a
>> best-effort basis.
>>
>> The reason I came up with these limitations is because I wanted to
>> make the scope minimal in order to retain Lucene's ability to move
>> forward. If there is consensus to move forward with this, I would like
>> to target Lucene 9.0 with this change.
>>
>> Simon
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: 8.8 Release

[David Smiley]

Happy New Year!
I would much prefer that ensure 8.8 includes SOLR-14923 (a bad nested docs
performance issue)

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Jan 6, 2021 at 6:59 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Happy New Year!
>
> I was supposed to start the process tomorrow, but I think we're not ready
> yet? I see SOLR-15052 still under review with intention of inclusion into
> 8.8.
> Would it be reasonable to cut the release branch end of this week and
> start the RC process around 13th January?
> If there are any issues someone would want me to wait on, please let me
> know.
>
> Thanks,
> Ishan
>
> On Fri, Dec 18, 2020 at 6:10 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Sure, Houston. I'll wait another week. Have a good new year and merry
>> Christmas!
>>
>> On Fri, 18 Dec, 2020, 5:58 am Timothy Potter, 
>> wrote:
>>
>>> Great point Houston! +1 on waiting until a week into January
>>>
>>> On Thu, Dec 17, 2020 at 4:46 PM Houston Putman 
>>> wrote:
>>>
 Thanks for volunteering Ishan.

 I think it might be a good idea to wait to cut and release 8.8 at least
 a week into January. Many people are going to be away during the holiday
 season, and particularly the last week of the year. Pushing into January
 just gives more people a chance to look at the release and be involved.

 - Houston

 On Fri, Dec 11, 2020 at 3:26 PM Noble Paul 
 wrote:

> Thanks Ishan for volunteering
>
> On Fri, Dec 11, 2020 at 5:07 AM Christine Poerschke (BLOOMBERG/
> LONDON)  wrote:
> >
> > With a view towards including it in the release, I'd appreciate code
> review input on
> >
> > https://github.com/apache/lucene-solr/pull/1992 for
> >
> > https://issues.apache.org/jira/browse/SOLR-14939 (JSON facets:
> range faceting to support cache=false parameter)
> >
> > if anyone has some time next week perhaps?
> >
> > Thanks in advance!
> >
> > Christine
> >
> > From: dev@lucene.apache.org At: 12/10/20 18:01:58
> > To: dev@lucene.apache.org
> > Subject: Re: 8.8 Release
> >
> > +1
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> >
> > On Thu, Dec 10, 2020 at 11:23 AM David Smiley 
> wrote:
> >>
> >> Thanks for volunteering!
> >>
> >> On Thu, Dec 10, 2020 at 11:11 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >>>
> >>> Hi Devs,
> >>> There are lots of changes accumulated and some underway. I wish to
> volunteer for a 8.8 release, if there are no objections. I'm planning to
> build the RC in three weeks, i.e. 31 December (and cut the branch about 
> 3-4
> days before that). Please let me know if someone has any concerns.
> >>> Thanks and regards,
> >>> Ishan
> >>>
> >> --
> >> Sent from Gmail Mobile
> >
> >
>
>
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: RFC: N-2 compatibility for file formats

[Ishan Chattopadhyaya]

Sounds great, +1

On Wed, Jan 6, 2021 at 3:10 PM Simon Willnauer 
wrote:

> Hello all,
>
> Currently Lucene supports reading and writing indices that have been
> created with the current or previous (N-1) version of Lucene. Lucene
> refuses to open an index created by N-2 or earlier versions.
> I would like to propose that Lucene adds support for opening indices
> created by version N-2 in read-only mode. Here's what I have in mind:
>
> - Read-only support. You can open a reader on an index created by
> version N-2, but you cannot open an IndexWriter on it, meaning that
> you can neither delete, update, add documents or force-merge N-2
> indices.
>
> - File-format compatibility only. File-format compatibility enables
> reading the content of old indices, but not more. Everything that is
> done on top of file formats like analysis or the encoding of length
> normalization factors is not guaranteed and only supported on a
> best-effort basis.
>
> The reason I came up with these limitations is because I wanted to
> make the scope minimal in order to retain Lucene's ability to move
> forward. If there is consensus to move forward with this, I would like
> to target Lucene 9.0 with this change.
>
> Simon
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: 8.8 Release

[Ishan Chattopadhyaya]

Happy New Year!

I was supposed to start the process tomorrow, but I think we're not ready
yet? I see SOLR-15052 still under review with intention of inclusion into
8.8.
Would it be reasonable to cut the release branch end of this week and start
the RC process around 13th January?
If there are any issues someone would want me to wait on, please let me
know.

Thanks,
Ishan

On Fri, Dec 18, 2020 at 6:10 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Sure, Houston. I'll wait another week. Have a good new year and merry
> Christmas!
>
> On Fri, 18 Dec, 2020, 5:58 am Timothy Potter, 
> wrote:
>
>> Great point Houston! +1 on waiting until a week into January
>>
>> On Thu, Dec 17, 2020 at 4:46 PM Houston Putman 
>> wrote:
>>
>>> Thanks for volunteering Ishan.
>>>
>>> I think it might be a good idea to wait to cut and release 8.8 at least
>>> a week into January. Many people are going to be away during the holiday
>>> season, and particularly the last week of the year. Pushing into January
>>> just gives more people a chance to look at the release and be involved.
>>>
>>> - Houston
>>>
>>> On Fri, Dec 11, 2020 at 3:26 PM Noble Paul  wrote:
>>>
 Thanks Ishan for volunteering

 On Fri, Dec 11, 2020 at 5:07 AM Christine Poerschke (BLOOMBERG/
 LONDON)  wrote:
 >
 > With a view towards including it in the release, I'd appreciate code
 review input on
 >
 > https://github.com/apache/lucene-solr/pull/1992 for
 >
 > https://issues.apache.org/jira/browse/SOLR-14939 (JSON facets: range
 faceting to support cache=false parameter)
 >
 > if anyone has some time next week perhaps?
 >
 > Thanks in advance!
 >
 > Christine
 >
 > From: dev@lucene.apache.org At: 12/10/20 18:01:58
 > To: dev@lucene.apache.org
 > Subject: Re: 8.8 Release
 >
 > +1
 >
 > Joel Bernstein
 > http://joelsolr.blogspot.com/
 >
 >
 > On Thu, Dec 10, 2020 at 11:23 AM David Smiley 
 wrote:
 >>
 >> Thanks for volunteering!
 >>
 >> On Thu, Dec 10, 2020 at 11:11 AM Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com> wrote:
 >>>
 >>> Hi Devs,
 >>> There are lots of changes accumulated and some underway. I wish to
 volunteer for a 8.8 release, if there are no objections. I'm planning to
 build the RC in three weeks, i.e. 31 December (and cut the branch about 3-4
 days before that). Please let me know if someone has any concerns.
 >>> Thanks and regards,
 >>> Ishan
 >>>
 >> --
 >> Sent from Gmail Mobile
 >
 >


 --
 -
 Noble Paul

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

Re: additional term meta data

[Martin Gainty]

how to access first and last?
which version will you be merging


From: John Wang 
Sent: Tuesday, January 5, 2021 8:19 PM
To: dev@lucene.apache.org 
Subject: additional term meta data

Hi folks:

We like to propose a feature to add additional per-term metadata to the term 
diction.

Currently, the TermsEnum API returns docFreq as its only meta-data. We needed a 
way to quickly get the first and last doc id in the postings without having to 
scan through the entire postings list.

We have created a PR on our own fork and we would like to contribute this back 
to the community. Please let us know if this is something that's useful and/or 
fits Lucene's roadmap, we would be happy to submit a patch.

https://github.com/dashbase/lucene-solr/pull/1

Thank you

-John

Re: additional term meta data

[Martin Gainty]

how to access first and last doc-id?
for which lucene version will you be targeting your merge?

Request: please submit testcase to show proper operation

Thanks John!
martin-


From: John Wang 
Sent: Tuesday, January 5, 2021 8:19 PM
To: dev@lucene.apache.org 
Subject: additional term meta data

Hi folks:

We like to propose a feature to add additional per-term metadata to the term 
diction.

Currently, the TermsEnum API returns docFreq as its only meta-data. We needed a 
way to quickly get the first and last doc id in the postings without having to 
scan through the entire postings list.

We have created a PR on our own fork and we would like to contribute this back 
to the community. Please let us know if this is something that's useful and/or 
fits Lucene's roadmap, we would be happy to submit a patch.

https://github.com/dashbase/lucene-solr/pull/1

Thank you

-John

RFC: N-2 compatibility for file formats

[Simon Willnauer]

Hello all,

Currently Lucene supports reading and writing indices that have been
created with the current or previous (N-1) version of Lucene. Lucene
refuses to open an index created by N-2 or earlier versions.
I would like to propose that Lucene adds support for opening indices
created by version N-2 in read-only mode. Here's what I have in mind:

- Read-only support. You can open a reader on an index created by
version N-2, but you cannot open an IndexWriter on it, meaning that
you can neither delete, update, add documents or force-merge N-2
indices.

- File-format compatibility only. File-format compatibility enables
reading the content of old indices, but not more. Everything that is
done on top of file formats like analysis or the encoding of length
normalization factors is not guaranteed and only supported on a
best-effort basis.

The reason I came up with these limitations is because I wanted to
make the scope minimal in order to retain Lucene's ability to move
forward. If there is consensus to move forward with this, I would like
to target Lucene 9.0 with this change.

Simon

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

RE: [JENKINS] $PROJECT_NAME (${ENV,var="JAVA"}) - Build # $BUILD_NUMBER - $BUILD_STATUS!

[Uwe Schindler]

Hi,

the variables expansion of build emails is broken. I downgraded Jenkins to 
preious version. Looks like this issue: 
https://issues.jenkins.io/browse/JENKINS-64556

The whole thing looks like the TokenMacro Plugin cannot handle the neweset 
Jenkins version and triggers a NPE. This seem to affect many other plugins (as 
many use tokens and their expansion), so I expect a fix soon.

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Policeman Jenkins Server 
> Sent: Wednesday, January 6, 2021 1:36 AM
> To: bui...@lucene.apache.org
> Subject: [JENKINS] $PROJECT_NAME (${ENV,var="JAVA"}) - Build #
> $BUILD_NUMBER - $BUILD_STATUS!
> 
> Build: ${BUILD_URL}
> Java: ${ENV,var="JAVA_DESC"}
> 
> ${FAILED_TESTS}


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