Re: RoadMap?

[David Smiley]

On Thu, Aug 27, 2020 at 7:03 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> > I find it highly depressing that we can't, *in a major release*, manage
> to get rid of our deprecations -- particularly for code that has a new home
> and is packaged in a form that is trivial to install (thanks to our new
> awesome package manager).
>
> I'm not sure why you think "we can't". I can't even remember a single
> committer standing in the way of removing those *that already have a
> package*.
>

Okay, maybe I read the intent wrong.  I can see the example given was about
Solr Cell, which apparently has no new home, so I'm +0 with keeping it for
9.0.

Also, on the roadmap cwiki:

We should *not* remove all features/APIs deprecated in 8.x yet, to give
> users a path to upgrade to 9.x without all the extra noise. Deprecated
> features can be removed in a later 9.x release, when the new alternative is
> solid and well known.


Again, maybe I'm misreading but I'd like to us to manage to remove a lot of
deprecated stuff *as the norm*.  There will be exceptions to the norm --
Solr Cell, CDCR.  To make this point clear, I wish to add to the roadmap,
Solr 9.0 table, first row, saying basically "Remove lots of deprecated
stuff" with some JIRAs linked like
https://issues.apache.org/jira/browse/SOLR-13138

~ David

Re: [VOTE] Release Lucene/Solr 8.6.2 RC1

[Tomás Fernández Löbbe]

+1 (binding)

SUCCESS! [1:03:21.542868]

On Thu, Aug 27, 2020 at 2:35 PM Uwe Schindler  wrote:

> Hi,
>
>
>
> +1 Binding from my side.
>
>
>
> Results:
>
> https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/34/console
>
>
>
> Works with Java 8 and later.
>
> I did not fully check everything in the artifacts, as this is a bugfix
> release only.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Ignacio Vera 
> *Sent:* Wednesday, August 26, 2020 3:42 PM
> *To:* dev@lucene.apache.org
> *Subject:* [VOTE] Release Lucene/Solr 8.6.2 RC1
>
>
>
> Please vote for release candidate 1 for Lucene/Solr 8.6.2
>
>
>
> The artifacts can be downloaded from:
>
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>
>
>
> You can run the smoke tester directly with this command:
>
>
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>
>
>
> The vote will be open for at least 72 hours i.e. until 2020-08-29 15:00
> UTC.
>
>
>
> [ ] +1  approve
>
> [ ] +0  no opinion
>
> [ ] -1  disapprove (and reason why)
>
>
>
> Here is my +1
>
>
>
> SUCCESS! [1:14:00.656250]
>

Re: 2020-08 Committer virtual meeting

[David Smiley]

The meeting concluded with many in attendance.  Email/Slack me directly for
the video recording.  I updated the meeting agenda to include some bits of
what we discussed.  My notes were terrible so I didn't add much.  Next time
I might do a live edit during the meeting -- a practice I see where I work
that seems effective.  I crossed out items that we did *not* discuss (due
to time).  At the next meeting, we should start with those.

I was going to suggest another committer meeting in about a month, so ~ 4
weeks from today's meeting, same time.  I think the time works well across
time zones as good/bad as can be expected.  But 4 weeks from today is
Activate.  The week after is ApacheCon.  So what about in only 3 weeks --
the 17th?  Or say 6 weeks out -- October 8th?  I'm up for anything.

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


On Tue, Aug 18, 2020 at 2:44 PM David Smiley  wrote:

> Hello fellow committers,
>
> I'd like to organize another virtual Lucene/Solr committer meeting this
> month.  I created a meeting notes page in confluence here:
> https://cwiki.apache.org/confluence/display/LUCENE/2020-08+Committer+meeting
> It has some topics I'd like to talk about, some copied from last month
> that might be worth following up on, and I'm hoping others might add to the
> tentative agenda as well.  As usual there are many topics to discuss.  I
> suppose if we have these meetings more often, I'll be less compelled to
> raise seemingly all topics.
>
> When exactly is this?:  Perhaps next Thursday or maybe later. I'm using a
> "Doodle poll" to determine an optimal time slot.  For the link to the poll,
> go to the ASF Slack, #lucene-dev or #solr-dev channel, and you will see
> it.  You could also email me directly for it.
>
> For this virtual committer meeting and future ones:
>
>- This is in the spirit of committer meetings co-located with
>conferences.  ASF policy says that no "decisions" can be made in such a
>venue.  We make decisions on this dev list and indirectly via JIRA out in
>the open and with the opportunity for anyone to comment.
>- Who:  Committer-only or by invitation
>- Video chat with option of audio dial-in.  This time I will use
>Google Hangout.
>- Recorded for those invited only.  I'll dispose of the recording a
>week after.  The intention is for those who cannot be there due to a
>scheduling conflict to see/hear what was said.  I have the ability to do
>this recording via Salesforce's G-Suite subscription.
>- Published notes:  I (or someone) will take written meeting notes
>that are ultimately published for anyone to see (not restricted to those
>invited).  They will be transmitted to the dev list.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>

Re: RoadMap?

[Alexandre Rafalovitch]

Ok, sounds like UIMA repeat to me.

+1 to take it out and point at one of those other solutions in CHANGES
or whatever.

Regards,
   Alex.

On Thu, 27 Aug 2020 at 20:45, Erick Erickson  wrote:
>
> CDCR does work, kind of. But it requires extensive care and feeding and, as 
> Ishan says, it’s _very_ easy to shoot yourself in the foot. Or run out of 
> disk space. Or get to a state where you have to replicate the index. And 
> “bi-directional” means you can go from A -> B _or_ B -> A, but you can’t 
> index to both A and B at once. Anyone who’s using it invariably rolls their 
> own monitoring to make sure it’s still running. You want “fire and forget” 
> functionality, but that’s not where CDCR is at.
>
> The consequence of not having the monitoring in place is that the tlogs fill 
> up, and then your index can become corrupt. Yes, it’s fixable, but there’s 
> always problem N+1...
>
> I think CDCR could be made acceptable _if_ someone was willing to own it and 
> devote a lot of time to maintenance. But nobody is stepping up to do it, 
> certainly not me. And it’s a side issue, Solr is a search engine. There are 
> solutions out there that are built from the start to deal with keeping 
> separate DCs in sync. Let’s use those rather than a “kinda works” solution.
>
> One of the problems with Solr is that it’s become a hodgepodge of peripheral 
> stuff that somebody found useful at some point. And in a number of instances, 
> capabilities were added to Solr when no other tools were available. But the 
> state of the art have progressed, it’s time to jettison older stuff...
>
> The advantage of CDCR is that it is all contained in Solr, no outside 
> packages required. The disadvantage is that has very few people willing to 
> work on it.
>
> So I’m for taking it out of Solr. My prediction is that if it’s made a 
> package, it’ll languish and at some point become unusable with the 
> then-current version of Solr. And nobody who complains will be willing to 
> devote the time and effort to making it work with Solr X.Y.
>
> FWIW...
>
>
> > On Aug 27, 2020, at 7:50 PM, Ishan Chattopadhyaya 
> >  wrote:
> >
> > It does start. It is broken because it is fraught with dangers of users 
> > shooting themselves in their feet. Some context here: 
> > https://issues.apache.org/jira/browse/SOLR-14616?focusedCommentId=17153129=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17153129
> >
> > On Fri, Aug 28, 2020 at 4:52 AM Alexandre Rafalovitch  
> > wrote:
> > If CDCR is actively broken (does not start?), then isn't it
> > effectively deprecated from the last version that did not work? And if
> > it is not going to be maintained, then isn't the 'latest' version is
> > whichever we still did not delete it in. Because a broken feature is
> > only worth keeping in, if we ever plan to fix it.
> >
> > We have been through the same with UIMA, if I recall. It was broken
> > for a bit and then when I pulled it, ONE person got all upset.
> > SOLR-11694
> >
> > Regards,
> >Alex
> > Ps. I don't know the degree of 'broken' of this specific feature. So,
> > I am mostly talking practical principles here.
> >
> > On Thu, 27 Aug 2020 at 19:03, Ishan Chattopadhyaya
> >  wrote:
> > >
> > > > I find it highly depressing that we can't, *in a major release*, manage 
> > > > to get rid of our deprecations -- particularly for code that has a new 
> > > > home and is packaged in a form that is trivial to install (thanks to 
> > > > our new awesome package manager).
> > >
> > > I'm not sure why you think "we can't". I can't even remember a single 
> > > committer standing in the way of removing those *that already have a 
> > > package*. However, there's a backlash against removing CDCR even though 
> > > there is no one volunteering to support it (as a package) and it is 
> > > clearly broken, which is what totally puzzles me. 
> > > https://issues.apache.org/jira/browse/SOLR-14616
> > >
> > > On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch 
> > >  wrote:
> > >>
> > >> Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
> > >> learning magic gradle commands to make that happen without leaving
> > >> behind random crumbs.  Once that lands, I will do Jira search on all
> > >> DIH still-open tasks after that and close them pointing to the said
> > >> Jira.
> > >>
> > >> So, I guess somebody better -1 the Jira if they really want that one
> > >> to stay until ... ? And then read very carefully through SIP-10 of
> > >> which, this is just a first step.
> > >>
> > >> In general, maybe we can manage to do so many new features and cleanup
> > >> in 9 that will make Solr TLP look like a great Big Bang moment...
> > >>
> > >> And it will probably take a little longer to achieve that, so the -
> > >> effective - deprecation schedule would still be ok.
> > >>
> > >> Regards,
> > >>Alex.
> > >>
> > >> On Thu, 27 Aug 2020 at 18:35, David Smiley  wrote:
> > >> >>
> > >> >> It has been proposed on the list 

Re: RoadMap?

[Erick Erickson]

CDCR does work, kind of. But it requires extensive care and feeding and, as 
Ishan says, it’s _very_ easy to shoot yourself in the foot. Or run out of disk 
space. Or get to a state where you have to replicate the index. And 
“bi-directional” means you can go from A -> B _or_ B -> A, but you can’t index 
to both A and B at once. Anyone who’s using it invariably rolls their own 
monitoring to make sure it’s still running. You want “fire and forget” 
functionality, but that’s not where CDCR is at.

The consequence of not having the monitoring in place is that the tlogs fill 
up, and then your index can become corrupt. Yes, it’s fixable, but there’s 
always problem N+1...

I think CDCR could be made acceptable _if_ someone was willing to own it and 
devote a lot of time to maintenance. But nobody is stepping up to do it, 
certainly not me. And it’s a side issue, Solr is a search engine. There are 
solutions out there that are built from the start to deal with keeping separate 
DCs in sync. Let’s use those rather than a “kinda works” solution.

One of the problems with Solr is that it’s become a hodgepodge of peripheral 
stuff that somebody found useful at some point. And in a number of instances, 
capabilities were added to Solr when no other tools were available. But the 
state of the art have progressed, it’s time to jettison older stuff...

The advantage of CDCR is that it is all contained in Solr, no outside packages 
required. The disadvantage is that has very few people willing to work on it.

So I’m for taking it out of Solr. My prediction is that if it’s made a package, 
it’ll languish and at some point become unusable with the then-current version 
of Solr. And nobody who complains will be willing to devote the time and effort 
to making it work with Solr X.Y.

FWIW...


> On Aug 27, 2020, at 7:50 PM, Ishan Chattopadhyaya  
> wrote:
> 
> It does start. It is broken because it is fraught with dangers of users 
> shooting themselves in their feet. Some context here: 
> https://issues.apache.org/jira/browse/SOLR-14616?focusedCommentId=17153129=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17153129
> 
> On Fri, Aug 28, 2020 at 4:52 AM Alexandre Rafalovitch  
> wrote:
> If CDCR is actively broken (does not start?), then isn't it
> effectively deprecated from the last version that did not work? And if
> it is not going to be maintained, then isn't the 'latest' version is
> whichever we still did not delete it in. Because a broken feature is
> only worth keeping in, if we ever plan to fix it.
> 
> We have been through the same with UIMA, if I recall. It was broken
> for a bit and then when I pulled it, ONE person got all upset.
> SOLR-11694
> 
> Regards,
>Alex
> Ps. I don't know the degree of 'broken' of this specific feature. So,
> I am mostly talking practical principles here.
> 
> On Thu, 27 Aug 2020 at 19:03, Ishan Chattopadhyaya
>  wrote:
> >
> > > I find it highly depressing that we can't, *in a major release*, manage 
> > > to get rid of our deprecations -- particularly for code that has a new 
> > > home and is packaged in a form that is trivial to install (thanks to our 
> > > new awesome package manager).
> >
> > I'm not sure why you think "we can't". I can't even remember a single 
> > committer standing in the way of removing those *that already have a 
> > package*. However, there's a backlash against removing CDCR even though 
> > there is no one volunteering to support it (as a package) and it is clearly 
> > broken, which is what totally puzzles me. 
> > https://issues.apache.org/jira/browse/SOLR-14616
> >
> > On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch  
> > wrote:
> >>
> >> Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
> >> learning magic gradle commands to make that happen without leaving
> >> behind random crumbs.  Once that lands, I will do Jira search on all
> >> DIH still-open tasks after that and close them pointing to the said
> >> Jira.
> >>
> >> So, I guess somebody better -1 the Jira if they really want that one
> >> to stay until ... ? And then read very carefully through SIP-10 of
> >> which, this is just a first step.
> >>
> >> In general, maybe we can manage to do so many new features and cleanup
> >> in 9 that will make Solr TLP look like a great Big Bang moment...
> >>
> >> And it will probably take a little longer to achieve that, so the -
> >> effective - deprecation schedule would still be ok.
> >>
> >> Regards,
> >>Alex.
> >>
> >> On Thu, 27 Aug 2020 at 18:35, David Smiley  wrote:
> >> >>
> >> >> It has been proposed on the list to NOT rip out all deprecations in 
> >> >> 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still 
> >> >> available, and then have yet some time to change their processes to 
> >> >> adapt to the new way of doing stuff. I like that proposal. Sure, 9.0 
> >> >> will remove lots of deprecated code, but I think it is a mistake to do 
> >> >> all of the proposed removals 

Re: RoadMap?

[Ishan Chattopadhyaya]

It does start. It is broken because it is fraught with dangers of users
shooting themselves in their feet. Some context here:
https://issues.apache.org/jira/browse/SOLR-14616?focusedCommentId=17153129=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17153129

On Fri, Aug 28, 2020 at 4:52 AM Alexandre Rafalovitch 
wrote:

> If CDCR is actively broken (does not start?), then isn't it
> effectively deprecated from the last version that did not work? And if
> it is not going to be maintained, then isn't the 'latest' version is
> whichever we still did not delete it in. Because a broken feature is
> only worth keeping in, if we ever plan to fix it.
>
> We have been through the same with UIMA, if I recall. It was broken
> for a bit and then when I pulled it, ONE person got all upset.
> SOLR-11694
>
> Regards,
>Alex
> Ps. I don't know the degree of 'broken' of this specific feature. So,
> I am mostly talking practical principles here.
>
> On Thu, 27 Aug 2020 at 19:03, Ishan Chattopadhyaya
>  wrote:
> >
> > > I find it highly depressing that we can't, *in a major release*,
> manage to get rid of our deprecations -- particularly for code that has a
> new home and is packaged in a form that is trivial to install (thanks to
> our new awesome package manager).
> >
> > I'm not sure why you think "we can't". I can't even remember a single
> committer standing in the way of removing those *that already have a
> package*. However, there's a backlash against removing CDCR even though
> there is no one volunteering to support it (as a package) and it is clearly
> broken, which is what totally puzzles me.
> https://issues.apache.org/jira/browse/SOLR-14616
> >
> > On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch <
> arafa...@gmail.com> wrote:
> >>
> >> Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
> >> learning magic gradle commands to make that happen without leaving
> >> behind random crumbs.  Once that lands, I will do Jira search on all
> >> DIH still-open tasks after that and close them pointing to the said
> >> Jira.
> >>
> >> So, I guess somebody better -1 the Jira if they really want that one
> >> to stay until ... ? And then read very carefully through SIP-10 of
> >> which, this is just a first step.
> >>
> >> In general, maybe we can manage to do so many new features and cleanup
> >> in 9 that will make Solr TLP look like a great Big Bang moment...
> >>
> >> And it will probably take a little longer to achieve that, so the -
> >> effective - deprecation schedule would still be ok.
> >>
> >> Regards,
> >>Alex.
> >>
> >> On Thu, 27 Aug 2020 at 18:35, David Smiley  wrote:
> >> >>
> >> >> It has been proposed on the list to NOT rip out all deprecations in
> 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available,
> and then have yet some time to change their processes to adapt to the new
> way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
> >> >
> >> >
> >> > I find it highly depressing that we can't, *in a major release*,
> manage to get rid of our deprecations -- particularly for code that has a
> new home and is packaged in a form that is trivial to install (thanks to
> our new awesome package manager).  I'm sympathetic to waiting to delete
> until *after* there is an actual package ready at that time (rather than
> just the promise of one).
> >> >
> >> > Also, users generally are cautious on performing a major version
> upgrade.  There's time.
> >> >
> >> > ~ David Smiley
> >> > Apache Lucene/Solr Search Developer
> >> > http://www.linkedin.com/in/davidwsmiley
> >> >
> >> >
> >> > On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl 
> wrote:
> >> >>
> >> >> I edited the page to introduce the (super important) Solr TLP split
> into the roadmap.
> >> >> Also added a rough timeframe and a «major theme» for each release
> above the issue table.
> >> >> I added 8.8 and 9.1 as I think it is important to track what gets
> done just before 9.0 and what can be deferred to after 9.0.
> >> >>
> >> >> It has been proposed on the list to NOT rip out all deprecations in
> 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available,
> and then have yet some time to change their processes to adapt to the new
> way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
> >> >>
> >> >> Thanks Gus for taking ownership and suggesting a process! Feel free
> to rework what I edited into a structure you see more fit.
> >> >>
> >> >> Jan
> >> 

RE: Removing Ant support take II

[Uwe Schindler]

+1

I will disable the "Lucene-Artifacts-master" and "Solr-Artifacts-master" jobs 
tomorrow afternoon my time.

Dev-tools/maven is obsolete, its just template files of no use without Ant.
Lucene/tools needs review, but all Ivy/Ant classes are obsolete, some groovy 
scripts are still used. So there's cleanup needed (grep all filenames through 
*.gradle). lucene/tools/fobiddenapis is obsolete, too, once the check task to 
verify that the signature are identical was removed. I can take care of that. 
Lucene/tools/javadocs should be moved to gradle dir (and removed from src.tgz 
files for licensing reasons).

Uwe

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

> -Original Message-
> From: Erick Erickson 
> Sent: Friday, August 28, 2020 12:12 AM
> To: dev@lucene.apache.org
> Subject: Removing Ant support take II
> 
> Did I understand correctly that I can remove the entire dev-tools/maven
> directory for this attempt?
> 
> Absent objections, I’ll push this Friday before 10:00 AM, UTC-5.
> -
> 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: RoadMap?

[Alexandre Rafalovitch]

If CDCR is actively broken (does not start?), then isn't it
effectively deprecated from the last version that did not work? And if
it is not going to be maintained, then isn't the 'latest' version is
whichever we still did not delete it in. Because a broken feature is
only worth keeping in, if we ever plan to fix it.

We have been through the same with UIMA, if I recall. It was broken
for a bit and then when I pulled it, ONE person got all upset.
SOLR-11694

Regards,
   Alex
Ps. I don't know the degree of 'broken' of this specific feature. So,
I am mostly talking practical principles here.

On Thu, 27 Aug 2020 at 19:03, Ishan Chattopadhyaya
 wrote:
>
> > I find it highly depressing that we can't, *in a major release*, manage to 
> > get rid of our deprecations -- particularly for code that has a new home 
> > and is packaged in a form that is trivial to install (thanks to our new 
> > awesome package manager).
>
> I'm not sure why you think "we can't". I can't even remember a single 
> committer standing in the way of removing those *that already have a 
> package*. However, there's a backlash against removing CDCR even though there 
> is no one volunteering to support it (as a package) and it is clearly broken, 
> which is what totally puzzles me. 
> https://issues.apache.org/jira/browse/SOLR-14616
>
> On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch  
> wrote:
>>
>> Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
>> learning magic gradle commands to make that happen without leaving
>> behind random crumbs.  Once that lands, I will do Jira search on all
>> DIH still-open tasks after that and close them pointing to the said
>> Jira.
>>
>> So, I guess somebody better -1 the Jira if they really want that one
>> to stay until ... ? And then read very carefully through SIP-10 of
>> which, this is just a first step.
>>
>> In general, maybe we can manage to do so many new features and cleanup
>> in 9 that will make Solr TLP look like a great Big Bang moment...
>>
>> And it will probably take a little longer to achieve that, so the -
>> effective - deprecation schedule would still be ok.
>>
>> Regards,
>>Alex.
>>
>> On Thu, 27 Aug 2020 at 18:35, David Smiley  wrote:
>> >>
>> >> It has been proposed on the list to NOT rip out all deprecations in 9.0, 
>> >> but allow users to upgrade to 9.0 with e.g. SolrCell still available, and 
>> >> then have yet some time to change their processes to adapt to the new way 
>> >> of doing stuff. I like that proposal. Sure, 9.0 will remove lots of 
>> >> deprecated code, but I think it is a mistake to do all of the proposed 
>> >> removals at once. We can spread removals out in 9.x releases, after users 
>> >> have had a few releases with a choice between old and new and the new 
>> >> alternative is solid.
>> >
>> >
>> > I find it highly depressing that we can't, *in a major release*, manage to 
>> > get rid of our deprecations -- particularly for code that has a new home 
>> > and is packaged in a form that is trivial to install (thanks to our new 
>> > awesome package manager).  I'm sympathetic to waiting to delete until 
>> > *after* there is an actual package ready at that time (rather than just 
>> > the promise of one).
>> >
>> > Also, users generally are cautious on performing a major version upgrade.  
>> > There's time.
>> >
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley
>> >
>> >
>> > On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl  wrote:
>> >>
>> >> I edited the page to introduce the (super important) Solr TLP split into 
>> >> the roadmap.
>> >> Also added a rough timeframe and a «major theme» for each release above 
>> >> the issue table.
>> >> I added 8.8 and 9.1 as I think it is important to track what gets done 
>> >> just before 9.0 and what can be deferred to after 9.0.
>> >>
>> >> It has been proposed on the list to NOT rip out all deprecations in 9.0, 
>> >> but allow users to upgrade to 9.0 with e.g. SolrCell still available, and 
>> >> then have yet some time to change their processes to adapt to the new way 
>> >> of doing stuff. I like that proposal. Sure, 9.0 will remove lots of 
>> >> deprecated code, but I think it is a mistake to do all of the proposed 
>> >> removals at once. We can spread removals out in 9.x releases, after users 
>> >> have had a few releases with a choice between old and new and the new 
>> >> alternative is solid.
>> >>
>> >> Thanks Gus for taking ownership and suggesting a process! Feel free to 
>> >> rework what I edited into a structure you see more fit.
>> >>
>> >> Jan
>> >>
>> >> 11. aug. 2020 kl. 18:51 skrev Gus Heck :
>> >>
>> >> I was thinking that level of detail is in the Jira... I don't see any 
>> >> reason for things to disappear (in fact rejected should go in a rejected 
>> >> list for future reference.)
>> >>
>> >> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg  wrote:
>> >>>
>> >>> Maybe also add “in progress”? So items do not 

Re: RoadMap?

[Ishan Chattopadhyaya]

> I find it highly depressing that we can't, *in a major release*, manage
to get rid of our deprecations -- particularly for code that has a new home
and is packaged in a form that is trivial to install (thanks to our new
awesome package manager).

I'm not sure why you think "we can't". I can't even remember a single
committer standing in the way of removing those *that already have a
package*. However, there's a backlash against removing CDCR even though
there is no one volunteering to support it (as a package) and it is clearly
broken, which is what totally puzzles me.
https://issues.apache.org/jira/browse/SOLR-14616

On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch 
wrote:

> Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
> learning magic gradle commands to make that happen without leaving
> behind random crumbs.  Once that lands, I will do Jira search on all
> DIH still-open tasks after that and close them pointing to the said
> Jira.
>
> So, I guess somebody better -1 the Jira if they really want that one
> to stay until ... ? And then read very carefully through SIP-10 of
> which, this is just a first step.
>
> In general, maybe we can manage to do so many new features and cleanup
> in 9 that will make Solr TLP look like a great Big Bang moment...
>
> And it will probably take a little longer to achieve that, so the -
> effective - deprecation schedule would still be ok.
>
> Regards,
>Alex.
>
> On Thu, 27 Aug 2020 at 18:35, David Smiley  wrote:
> >>
> >> It has been proposed on the list to NOT rip out all deprecations in
> 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available,
> and then have yet some time to change their processes to adapt to the new
> way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
> >
> >
> > I find it highly depressing that we can't, *in a major release*, manage
> to get rid of our deprecations -- particularly for code that has a new home
> and is packaged in a form that is trivial to install (thanks to our new
> awesome package manager).  I'm sympathetic to waiting to delete until
> *after* there is an actual package ready at that time (rather than just the
> promise of one).
> >
> > Also, users generally are cautious on performing a major version
> upgrade.  There's time.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl 
> wrote:
> >>
> >> I edited the page to introduce the (super important) Solr TLP split
> into the roadmap.
> >> Also added a rough timeframe and a «major theme» for each release above
> the issue table.
> >> I added 8.8 and 9.1 as I think it is important to track what gets done
> just before 9.0 and what can be deferred to after 9.0.
> >>
> >> It has been proposed on the list to NOT rip out all deprecations in
> 9.0, but allow users to upgrade to 9.0 with e.g. SolrCell still available,
> and then have yet some time to change their processes to adapt to the new
> way of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
> >>
> >> Thanks Gus for taking ownership and suggesting a process! Feel free to
> rework what I edited into a structure you see more fit.
> >>
> >> Jan
> >>
> >> 11. aug. 2020 kl. 18:51 skrev Gus Heck :
> >>
> >> I was thinking that level of detail is in the Jira... I don't see any
> reason for things to disappear (in fact rejected should go in a rejected
> list for future reference.)
> >>
> >> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg 
> wrote:
> >>>
> >>> Maybe also add “in progress”? So items do not disappear suddenly from
> the page when work really starts on them?
> >>>
> >>> On Tue 11 Aug 2020 at 17:15, Gus Heck  wrote:
> 
>  Cool, since I brought it up, I can volunteer to help manage the page.
> We should get jira issue links in there wherever possible. Do we want to
> build an initial list and have some sort of Proposed/Planned workflow so
> readers can have confidence (or appropriate lack of confidence) in what
> they see there? voting on things seems like too much but maybe folks who
> care watch the page, and if something is on there for a week without
> objection it can be called accepted? If a discussion starts here it can be
> marked "Considering" so... something like this:
> 
>  4 states: Proposed, Considering, Planned, Rejected
> 
>  Workflow like this:
>  Proposed ---(no objection 1 wk) --> Planned
>  

Re: Benchmark for Apache Lucene Library

[Ishan Chattopadhyaya]

https://home.apache.org/~mikemccand/lucenebench/

On Fri, 28 Aug, 2020, 1:12 am Performance Enggring, <
performance.enggr...@gmail.com> wrote:

> Hello Lucene Experts,
>
> Hope everyone is doing well!
>
> I am looking for an Apache Lucene benchmark tool, which covers all key
> aspects of a benchmark, including Scalability, Relevance,
> Representativeness and Repeatability.
> I am reaching out to you to seek your suggestions on the same and it would
> be really helpful, if you can provide any reference.
>
> --
> Regards,
> SK
>

Re: RoadMap?

[Alexandre Rafalovitch]

Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily
learning magic gradle commands to make that happen without leaving
behind random crumbs.  Once that lands, I will do Jira search on all
DIH still-open tasks after that and close them pointing to the said
Jira.

So, I guess somebody better -1 the Jira if they really want that one
to stay until ... ? And then read very carefully through SIP-10 of
which, this is just a first step.

In general, maybe we can manage to do so many new features and cleanup
in 9 that will make Solr TLP look like a great Big Bang moment...

And it will probably take a little longer to achieve that, so the -
effective - deprecation schedule would still be ok.

Regards,
   Alex.

On Thu, 27 Aug 2020 at 18:35, David Smiley  wrote:
>>
>> It has been proposed on the list to NOT rip out all deprecations in 9.0, but 
>> allow users to upgrade to 9.0 with e.g. SolrCell still available, and then 
>> have yet some time to change their processes to adapt to the new way of 
>> doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated 
>> code, but I think it is a mistake to do all of the proposed removals at 
>> once. We can spread removals out in 9.x releases, after users have had a few 
>> releases with a choice between old and new and the new alternative is solid.
>
>
> I find it highly depressing that we can't, *in a major release*, manage to 
> get rid of our deprecations -- particularly for code that has a new home and 
> is packaged in a form that is trivial to install (thanks to our new awesome 
> package manager).  I'm sympathetic to waiting to delete until *after* there 
> is an actual package ready at that time (rather than just the promise of one).
>
> Also, users generally are cautious on performing a major version upgrade.  
> There's time.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl  wrote:
>>
>> I edited the page to introduce the (super important) Solr TLP split into the 
>> roadmap.
>> Also added a rough timeframe and a «major theme» for each release above the 
>> issue table.
>> I added 8.8 and 9.1 as I think it is important to track what gets done just 
>> before 9.0 and what can be deferred to after 9.0.
>>
>> It has been proposed on the list to NOT rip out all deprecations in 9.0, but 
>> allow users to upgrade to 9.0 with e.g. SolrCell still available, and then 
>> have yet some time to change their processes to adapt to the new way of 
>> doing stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated 
>> code, but I think it is a mistake to do all of the proposed removals at 
>> once. We can spread removals out in 9.x releases, after users have had a few 
>> releases with a choice between old and new and the new alternative is solid.
>>
>> Thanks Gus for taking ownership and suggesting a process! Feel free to 
>> rework what I edited into a structure you see more fit.
>>
>> Jan
>>
>> 11. aug. 2020 kl. 18:51 skrev Gus Heck :
>>
>> I was thinking that level of detail is in the Jira... I don't see any reason 
>> for things to disappear (in fact rejected should go in a rejected list for 
>> future reference.)
>>
>> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg  wrote:
>>>
>>> Maybe also add “in progress”? So items do not disappear suddenly from the 
>>> page when work really starts on them?
>>>
>>> On Tue 11 Aug 2020 at 17:15, Gus Heck  wrote:

 Cool, since I brought it up, I can volunteer to help manage the page. We 
 should get jira issue links in there wherever possible. Do we want to 
 build an initial list and have some sort of Proposed/Planned workflow so 
 readers can have confidence (or appropriate lack of confidence) in what 
 they see there? voting on things seems like too much but maybe folks who 
 care watch the page, and if something is on there for a week without 
 objection it can be called accepted? If a discussion starts here it can be 
 marked "Considering" so... something like this:

 4 states: Proposed, Considering, Planned, Rejected

 Workflow like this:
 Proposed ---(no objection 1 wk) --> Planned
 Proposed ---(discussion)--> Considering
 Considering (agreement) --> Planned
 Considering (deferred) ---> Proposed (later release)
 Considering (unsuitable) -> Rejected
 Considering (promoted) ---> Proposed (earlier release)
 Planned (difficulty found) ---> Considering

 Anything in "Considering" should have an active dev list thread, and if it 
 didn't happen on the list it didn't happen :). Any of that (or differences 
 of opinion during Considering) can be overridden by a formal vote of course

 -Gus




 On Tue, Aug 11, 2020 at 10:29 AM Ishan Chattopadhyaya 
  wrote:
>
> I've created a placeholder 

Re: RoadMap?

[Erick Erickson]

IMO, it’s super-awkward to preserve something for 9.0 then remove it for 9.1. I 
understand the tendency to say “deprecating it in 8.7 then removing it in the 
next release is too fast”, but that strikes me as even worse than taking it out 
of 9.0.

> On Aug 27, 2020, at 6:35 PM, David Smiley  wrote:
> 
> It has been proposed on the list to NOT rip out all deprecations in 9.0, but 
> allow users to upgrade to 9.0 with e.g. SolrCell still available, and then 
> have yet some time to change their processes to adapt to the new way of doing 
> stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, 
> but I think it is a mistake to do all of the proposed removals at once. We 
> can spread removals out in 9.x releases, after users have had a few releases 
> with a choice between old and new and the new alternative is solid.
> 
> I find it highly depressing that we can't, *in a major release*, manage to 
> get rid of our deprecations -- particularly for code that has a new home and 
> is packaged in a form that is trivial to install (thanks to our new awesome 
> package manager).  I'm sympathetic to waiting to delete until *after* there 
> is an actual package ready at that time (rather than just the promise of one).
> 
> Also, users generally are cautious on performing a major version upgrade.  
> There's time.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> 
> On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl  wrote:
> I edited the page to introduce the (super important) Solr TLP split into the 
> roadmap.
> Also added a rough timeframe and a «major theme» for each release above the 
> issue table.
> I added 8.8 and 9.1 as I think it is important to track what gets done just 
> before 9.0 and what can be deferred to after 9.0.
> 
> It has been proposed on the list to NOT rip out all deprecations in 9.0, but 
> allow users to upgrade to 9.0 with e.g. SolrCell still available, and then 
> have yet some time to change their processes to adapt to the new way of doing 
> stuff. I like that proposal. Sure, 9.0 will remove lots of deprecated code, 
> but I think it is a mistake to do all of the proposed removals at once. We 
> can spread removals out in 9.x releases, after users have had a few releases 
> with a choice between old and new and the new alternative is solid.
> 
> Thanks Gus for taking ownership and suggesting a process! Feel free to rework 
> what I edited into a structure you see more fit.
> 
> Jan
> 
>> 11. aug. 2020 kl. 18:51 skrev Gus Heck :
>> 
>> I was thinking that level of detail is in the Jira... I don't see any reason 
>> for things to disappear (in fact rejected should go in a rejected list for 
>> future reference.)
>> 
>> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg  wrote:
>> Maybe also add “in progress”? So items do not disappear suddenly from the 
>> page when work really starts on them?
>> 
>> On Tue 11 Aug 2020 at 17:15, Gus Heck  wrote:
>> Cool, since I brought it up, I can volunteer to help manage the page. We 
>> should get jira issue links in there wherever possible. Do we want to build 
>> an initial list and have some sort of Proposed/Planned workflow so readers 
>> can have confidence (or appropriate lack of confidence) in what they see 
>> there? voting on things seems like too much but maybe folks who care watch 
>> the page, and if something is on there for a week without objection it can 
>> be called accepted? If a discussion starts here it can be marked 
>> "Considering" so... something like this:
>> 
>> 4 states: Proposed, Considering, Planned, Rejected
>> 
>> Workflow like this:
>> Proposed ---(no objection 1 wk) --> Planned 
>> Proposed ---(discussion)--> Considering
>> Considering (agreement) --> Planned
>> Considering (deferred) ---> Proposed (later release)
>> Considering (unsuitable) -> Rejected
>> Considering (promoted) ---> Proposed (earlier release)
>> Planned (difficulty found) ---> Considering
>> 
>> Anything in "Considering" should have an active dev list thread, and if it 
>> didn't happen on the list it didn't happen :). Any of that (or differences 
>> of opinion during Considering) can be overridden by a formal vote of course
>> 
>> -Gus
>> 
>> 
>> 
>> 
>> On Tue, Aug 11, 2020 at 10:29 AM Ishan Chattopadhyaya 
>>  wrote:
>> I've created a placeholder document here: 
>> https://cwiki.apache.org/confluence/display/SOLR/Roadmap
>> Let us put in all our items there.
>> 
>> On Tue, Aug 11, 2020 at 4:45 PM Jan Høydahl  wrote:
>> Let’s revive this email thread about Roadmap.
>> 
>> 
>> 
>> 
>> 
>> With so many large initiatives going on, and the TLP split also, I think it 
>> makes perfect sense with a Roadmap.
>> 
>> 
>> I know we’re not used to that kind of thing - we tend to just let things 
>> play out as it happens to land in various releases, but this time is 
>> special, and I think we’d benefit from more 

Re: RoadMap?

[David Smiley]

>
> It has been proposed on the list to NOT rip out all deprecations in 9.0,
> but allow users to upgrade to 9.0 with e.g. SolrCell still available, and
> then have yet some time to change their processes to adapt to the new way
> of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
>

I find it highly depressing that we can't, *in a major release*, manage to
get rid of our deprecations -- particularly for code that has a new home
and is packaged in a form that is trivial to install (thanks to our new
awesome package manager).  I'm sympathetic to waiting to delete until
*after* there is an actual package ready at that time (rather than just the
promise of one).

Also, users generally are cautious on performing a major version upgrade.
There's time.

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


On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl  wrote:

> I edited the page to introduce the (super important) Solr TLP split into
> the roadmap.
> Also added a rough timeframe and a «major theme» for each release above
> the issue table.
> I added 8.8 and 9.1 as I think it is important to track what gets done
> just before 9.0 and what can be deferred to after 9.0.
>
> It has been proposed on the list to NOT rip out all deprecations in 9.0,
> but allow users to upgrade to 9.0 with e.g. SolrCell still available, and
> then have yet some time to change their processes to adapt to the new way
> of doing stuff. I like that proposal. Sure, 9.0 will remove lots of
> deprecated code, but I think it is a mistake to do all of the proposed
> removals at once. We can spread removals out in 9.x releases, after users
> have had a few releases with a choice between old and new and the new
> alternative is solid.
>
> Thanks Gus for taking ownership and suggesting a process! Feel free to
> rework what I edited into a structure you see more fit.
>
> Jan
>
> 11. aug. 2020 kl. 18:51 skrev Gus Heck :
>
> I was thinking that level of detail is in the Jira... I don't see any
> reason for things to disappear (in fact rejected should go in a rejected
> list for future reference.)
>
> On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg  wrote:
>
>> Maybe also add “in progress”? So items do not disappear suddenly from the
>> page when work really starts on them?
>>
>> On Tue 11 Aug 2020 at 17:15, Gus Heck  wrote:
>>
>>> Cool, since I brought it up, I can volunteer to help manage the page. We
>>> should get jira issue links in there wherever possible. Do we want to build
>>> an initial list and have some sort of Proposed/Planned workflow so readers
>>> can have confidence (or appropriate lack of confidence) in what they see
>>> there? voting on things seems like too much but maybe folks who care watch
>>> the page, and if something is on there for a week without objection it can
>>> be called accepted? If a discussion starts here it can be marked
>>> "Considering" so... something like this:
>>>
>>> 4 states: Proposed, Considering, Planned, Rejected
>>>
>>> Workflow like this:
>>> Proposed ---(no objection 1 wk) --> Planned
>>> Proposed ---(discussion)--> Considering
>>> Considering (agreement) --> Planned
>>> Considering (deferred) ---> Proposed (later release)
>>> Considering (unsuitable) -> Rejected
>>> Considering (promoted) ---> Proposed (earlier release)
>>> Planned (difficulty found) ---> Considering
>>>
>>> Anything in "Considering" should have an active dev list thread, and if
>>> it didn't happen on the list it didn't happen :). Any of that (or
>>> differences of opinion during Considering) can be overridden by a formal
>>> vote of course
>>>
>>> -Gus
>>>
>>>
>>>
>>>
>>> On Tue, Aug 11, 2020 at 10:29 AM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
 I've created a placeholder document here:
 https://cwiki.apache.org/confluence/display/SOLR/Roadmap
 Let us put in all our items there.

 On Tue, Aug 11, 2020 at 4:45 PM Jan Høydahl 
 wrote:

> Let’s revive this email thread about Roadmap.
>
>
>
>
>
> With so many large initiatives going on, and the TLP split also, I
> think it makes perfect sense with a Roadmap.
>
>
> I know we’re not used to that kind of thing - we tend to just let
> things play out as it happens to land in various releases, but this time 
> is
> special, and I think we’d benefit from more coordination. I don’t know how
> to enforce such coordination though, other than appealing to all 
> committers
> to endorse the roadmap and respect it when they merge things. We may not 
> be
> able to set a release date for 9.0 right now, but we 

Removing Ant support take II

[Erick Erickson]

Did I understand correctly that I can remove the entire dev-tools/maven 
directory for this attempt?

Absent objections, I’ll push this Friday before 10:00 AM, UTC-5.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [VOTE] Release Lucene/Solr 8.6.2 RC1

[Uwe Schindler]

Hi,

 

+1 Binding from my side.

 

Results:

https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/34/console

 

Works with Java 8 and later.

I did not fully check everything in the artifacts, as this is a bugfix release 
only.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Ignacio Vera  
Sent: Wednesday, August 26, 2020 3:42 PM
To: dev@lucene.apache.org
Subject: [VOTE] Release Lucene/Solr 8.6.2 RC1

 

Please vote for release candidate 1 for Lucene/Solr 8.6.2

 

The artifacts can be downloaded from:

https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e

 

You can run the smoke tester directly with this command:

 

python3 -u dev-tools/scripts/smokeTestRelease.py \

https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e

 

The vote will be open for at least 72 hours i.e. until 2020-08-29 15:00 UTC.

 

[ ] +1  approve

[ ] +0  no opinion

[ ] -1  disapprove (and reason why)

 

Here is my +1

 

SUCCESS! [1:14:00.656250]

Re: Current workflow for steps before commiting changes

[Erick Erickson]

Alexandre:

"./gradlew check” is all you need. That does what “ant precommit test” would do.

Dawid put some pretty great help in, "./gradlew help” shows the top-level help 
tasks, and “./gradlew helpAnt” gives some very useful gradle versions of some 
of the familiar Ant targets you’re used to.

And if you want to see _everything_, “./gradlew tasks”, but prepare to be 
overwhelmed….

Best,
Erick


> On Aug 27, 2020, at 4:38 PM, Alexandre Rafalovitch  wrote:
> 
> Hello,
> 
> So, what's the current post-changes pre-commit workflow for master (9)?
> 
> Do I run gradlew precommit? Does that include actual tests or need
> those separately? Do I need to run ant precommit as well?
> 
> I am mostly removing things, but need to make sure no dangling
> references will cause issues.
> 
> Regards,
>   Alex.
> 
> -
> 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

Current workflow for steps before commiting changes

[Alexandre Rafalovitch]

Hello,

So, what's the current post-changes pre-commit workflow for master (9)?

Do I run gradlew precommit? Does that include actual tests or need
those separately? Do I need to run ant precommit as well?

I am mostly removing things, but need to make sure no dangling
references will cause issues.

Regards,
   Alex.

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

Benchmark for Apache Lucene Library

[Performance Enggring]

Hello Lucene Experts,

Hope everyone is doing well!

I am looking for an Apache Lucene benchmark tool, which covers all key
aspects of a benchmark, including Scalability, Relevance,
Representativeness and Repeatability.
I am reaching out to you to seek your suggestions on the same and it would
be really helpful, if you can provide any reference.

-- 
Regards,
SK

Re: [VOTE] Release Lucene/Solr 8.6.2 RC1

[Anshum Gupta]

+1 (binding)

SUCCESS! [1:01:12.850746]

I ran the smoke tester w/ Java8 and tried basic Solr operations.


On Wed, Aug 26, 2020 at 6:42 AM Ignacio Vera  wrote:

> Please vote for release candidate 1 for Lucene/Solr 8.6.2
>
>
> The artifacts can be downloaded from:
>
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>
>
> You can run the smoke tester directly with this command:
>
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>
>
> The vote will be open for at least 72 hours i.e. until 2020-08-29 15:00
> UTC.
>
>
> [ ] +1  approve
>
> [ ] +0  no opinion
>
> [ ] -1  disapprove (and reason why)
>
>
> Here is my +1
>
> SUCCESS! [1:14:00.656250]
>


-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.6.2 RC1

[Jan Høydahl]

+1 (binding)

SUCCESS! [1:06:03.480313] - I just ran the smoketester, no more checks…

Jan

> 27. aug. 2020 kl. 17:40 skrev Houston Putman :
> 
> +1 (non-binding)
> 
> SUCCESS! [1:02:26.611225]
> 
> On Thu, Aug 27, 2020 at 10:03 AM Simon Willnauer  > wrote:
> +1 binding release looks good to me
> 
> On Thu, Aug 27, 2020 at 3:58 PM Atri Sharma  > wrote:
> >
> > +1 (binding)
> >
> > SUCCESS! [1:14:17.24939]
> >
> > On Thu, 27 Aug 2020 at 18:41, Michael Sokolov  > > wrote:
> >>
> >> SUCCESS! [0:56:28.589654]
> >>
> >>
> >>
> >> +1
> >>
> >>
> >>
> >> On Wed, Aug 26, 2020 at 12:41 PM Nhat Nguyen
> >>
> >> mailto:nhat.ngu...@elastic.co>.invalid> wrote:
> >>
> >> >
> >>
> >> > +1
> >>
> >> >
> >>
> >> > SUCCESS! [0:52:44.607871]
> >>
> >> >
> >>
> >> > On Wed, Aug 26, 2020 at 12:12 PM Tomoko Uchida 
> >> > mailto:tomoko.uchida.1...@gmail.com>> 
> >> > wrote:
> >>
> >> >>
> >>
> >> >> +1 (non-binding)
> >>
> >> >> SUCCESS! [0:51:55.207272]
> >>
> >> >>
> >>
> >> >>
> >>
> >> >> 2020年8月26日(水) 22:42 Ignacio Vera  >> >> >:
> >>
> >> >>>
> >>
> >> >>> Please vote for release candidate 1 for Lucene/Solr 8.6.2
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> The artifacts can be downloaded from:
> >>
> >> >>>
> >>
> >> >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
> >> >>>  
> >> >>> 
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> You can run the smoke tester directly with this command:
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >>
> >> >>>
> >>
> >> >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
> >> >>>  
> >> >>> 
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> The vote will be open for at least 72 hours i.e. until 2020-08-29 
> >> >>> 15:00 UTC.
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> [ ] +1  approve
> >>
> >> >>>
> >>
> >> >>> [ ] +0  no opinion
> >>
> >> >>>
> >>
> >> >>> [ ] -1  disapprove (and reason why)
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> Here is my +1
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> SUCCESS! [1:14:00.656250]
> >>
> >>
> >>
> >> -
> >>
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> >> 
> >>
> >> For additional commands, e-mail: dev-h...@lucene.apache.org 
> >> 
> >>
> >>
> >>
> >
> >
> > --
> > Regards,
> >
> > Atri
> > Apache Concerted
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 

Re: [VOTE] Release Lucene/Solr 8.6.2 RC1

[Houston Putman]

+1 (non-binding)

SUCCESS! [1:02:26.611225]

On Thu, Aug 27, 2020 at 10:03 AM Simon Willnauer 
wrote:

> +1 binding release looks good to me
>
> On Thu, Aug 27, 2020 at 3:58 PM Atri Sharma  wrote:
> >
> > +1 (binding)
> >
> > SUCCESS! [1:14:17.24939]
> >
> > On Thu, 27 Aug 2020 at 18:41, Michael Sokolov 
> wrote:
> >>
> >> SUCCESS! [0:56:28.589654]
> >>
> >>
> >>
> >> +1
> >>
> >>
> >>
> >> On Wed, Aug 26, 2020 at 12:41 PM Nhat Nguyen
> >>
> >>  wrote:
> >>
> >> >
> >>
> >> > +1
> >>
> >> >
> >>
> >> > SUCCESS! [0:52:44.607871]
> >>
> >> >
> >>
> >> > On Wed, Aug 26, 2020 at 12:12 PM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
> >>
> >> >>
> >>
> >> >> +1 (non-binding)
> >>
> >> >> SUCCESS! [0:51:55.207272]
> >>
> >> >>
> >>
> >> >>
> >>
> >> >> 2020年8月26日(水) 22:42 Ignacio Vera :
> >>
> >> >>>
> >>
> >> >>> Please vote for release candidate 1 for Lucene/Solr 8.6.2
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> The artifacts can be downloaded from:
> >>
> >> >>>
> >>
> >> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> You can run the smoke tester directly with this command:
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >>
> >> >>>
> >>
> >> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> The vote will be open for at least 72 hours i.e. until 2020-08-29
> 15:00 UTC.
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> [ ] +1  approve
> >>
> >> >>>
> >>
> >> >>> [ ] +0  no opinion
> >>
> >> >>>
> >>
> >> >>> [ ] -1  disapprove (and reason why)
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> Here is my +1
> >>
> >> >>>
> >>
> >> >>>
> >>
> >> >>> SUCCESS! [1:14:00.656250]
> >>
> >>
> >>
> >> -
> >>
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>
> >>
> >>
> >
> >
> > --
> > Regards,
> >
> > Atri
> > Apache Concerted
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 8.6.2 RC1

[Simon Willnauer]

+1 binding release looks good to me

On Thu, Aug 27, 2020 at 3:58 PM Atri Sharma  wrote:
>
> +1 (binding)
>
> SUCCESS! [1:14:17.24939]
>
> On Thu, 27 Aug 2020 at 18:41, Michael Sokolov  wrote:
>>
>> SUCCESS! [0:56:28.589654]
>>
>>
>>
>> +1
>>
>>
>>
>> On Wed, Aug 26, 2020 at 12:41 PM Nhat Nguyen
>>
>>  wrote:
>>
>> >
>>
>> > +1
>>
>> >
>>
>> > SUCCESS! [0:52:44.607871]
>>
>> >
>>
>> > On Wed, Aug 26, 2020 at 12:12 PM Tomoko Uchida 
>> >  wrote:
>>
>> >>
>>
>> >> +1 (non-binding)
>>
>> >> SUCCESS! [0:51:55.207272]
>>
>> >>
>>
>> >>
>>
>> >> 2020年8月26日(水) 22:42 Ignacio Vera :
>>
>> >>>
>>
>> >>> Please vote for release candidate 1 for Lucene/Solr 8.6.2
>>
>> >>>
>>
>> >>>
>>
>> >>> The artifacts can be downloaded from:
>>
>> >>>
>>
>> >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>>
>> >>>
>>
>> >>>
>>
>> >>> You can run the smoke tester directly with this command:
>>
>> >>>
>>
>> >>>
>>
>> >>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>
>> >>>
>>
>> >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>>
>> >>>
>>
>> >>>
>>
>> >>> The vote will be open for at least 72 hours i.e. until 2020-08-29 15:00 
>> >>> UTC.
>>
>> >>>
>>
>> >>>
>>
>> >>> [ ] +1  approve
>>
>> >>>
>>
>> >>> [ ] +0  no opinion
>>
>> >>>
>>
>> >>> [ ] -1  disapprove (and reason why)
>>
>> >>>
>>
>> >>>
>>
>> >>> Here is my +1
>>
>> >>>
>>
>> >>>
>>
>> >>> SUCCESS! [1:14:00.656250]
>>
>>
>>
>> -
>>
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>>
>
>
> --
> Regards,
>
> Atri
> Apache Concerted

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

Re: [VOTE] Release Lucene/Solr 8.6.2 RC1

[Atri Sharma]

+1 (binding)

SUCCESS! [1:14:17.24939]

On Thu, 27 Aug 2020 at 18:41, Michael Sokolov  wrote:

> SUCCESS! [0:56:28.589654]
>
>
>
> +1
>
>
>
> On Wed, Aug 26, 2020 at 12:41 PM Nhat Nguyen
>
>  wrote:
>
> >
>
> > +1
>
> >
>
> > SUCCESS! [0:52:44.607871]
>
> >
>
> > On Wed, Aug 26, 2020 at 12:12 PM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
> >>
>
> >> +1 (non-binding)
>
> >> SUCCESS! [0:51:55.207272]
>
> >>
>
> >>
>
> >> 2020年8月26日(水) 22:42 Ignacio Vera :
>
> >>>
>
> >>> Please vote for release candidate 1 for Lucene/Solr 8.6.2
>
> >>>
>
> >>>
>
> >>> The artifacts can be downloaded from:
>
> >>>
>
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>
> >>>
>
> >>>
>
> >>> You can run the smoke tester directly with this command:
>
> >>>
>
> >>>
>
> >>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> >>>
>
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>
> >>>
>
> >>>
>
> >>> The vote will be open for at least 72 hours i.e. until 2020-08-29
> 15:00 UTC.
>
> >>>
>
> >>>
>
> >>> [ ] +1  approve
>
> >>>
>
> >>> [ ] +0  no opinion
>
> >>>
>
> >>> [ ] -1  disapprove (and reason why)
>
> >>>
>
> >>>
>
> >>> Here is my +1
>
> >>>
>
> >>>
>
> >>> SUCCESS! [1:14:00.656250]
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
>

-- 
Regards,

Atri
Apache Concerted

Re: [VOTE] Release Lucene/Solr 8.6.2 RC1

[Timothy Potter]

+1  (binding)

SUCCESS! [1:07:47.265949]

On Thu, Aug 27, 2020 at 7:11 AM Michael Sokolov  wrote:

> SUCCESS! [0:56:28.589654]
>
> +1
>
> On Wed, Aug 26, 2020 at 12:41 PM Nhat Nguyen
>  wrote:
> >
> > +1
> >
> > SUCCESS! [0:52:44.607871]
> >
> > On Wed, Aug 26, 2020 at 12:12 PM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
> >>
> >> +1 (non-binding)
> >> SUCCESS! [0:51:55.207272]
> >>
> >>
> >> 2020年8月26日(水) 22:42 Ignacio Vera :
> >>>
> >>> Please vote for release candidate 1 for Lucene/Solr 8.6.2
> >>>
> >>>
> >>> The artifacts can be downloaded from:
> >>>
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
> >>>
> >>>
> >>> You can run the smoke tester directly with this command:
> >>>
> >>>
> >>> python3 -u dev-tools/scripts/smokeTestRelease.py \
> >>>
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
> >>>
> >>>
> >>> The vote will be open for at least 72 hours i.e. until 2020-08-29
> 15:00 UTC.
> >>>
> >>>
> >>> [ ] +1  approve
> >>>
> >>> [ ] +0  no opinion
> >>>
> >>> [ ] -1  disapprove (and reason why)
> >>>
> >>>
> >>> Here is my +1
> >>>
> >>>
> >>> SUCCESS! [1:14:00.656250]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 8.6.2 RC1

[Michael Sokolov]

SUCCESS! [0:56:28.589654]

+1

On Wed, Aug 26, 2020 at 12:41 PM Nhat Nguyen
 wrote:
>
> +1
>
> SUCCESS! [0:52:44.607871]
>
> On Wed, Aug 26, 2020 at 12:12 PM Tomoko Uchida  
> wrote:
>>
>> +1 (non-binding)
>> SUCCESS! [0:51:55.207272]
>>
>>
>> 2020年8月26日(水) 22:42 Ignacio Vera :
>>>
>>> Please vote for release candidate 1 for Lucene/Solr 8.6.2
>>>
>>>
>>> The artifacts can be downloaded from:
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>>>
>>>
>>> You can run the smoke tester directly with this command:
>>>
>>>
>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>>>
>>>
>>> The vote will be open for at least 72 hours i.e. until 2020-08-29 15:00 UTC.
>>>
>>>
>>> [ ] +1  approve
>>>
>>> [ ] +0  no opinion
>>>
>>> [ ] -1  disapprove (and reason why)
>>>
>>>
>>> Here is my +1
>>>
>>>
>>> SUCCESS! [1:14:00.656250]

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

Re: Failing tests 100% of the time.

[Atri Sharma]

This was my bad, sorry folks. Another reason for me to move from ant to
gradle.

Thanks a ton for taking this one, Erick!

On Thu, 27 Aug 2020 at 18:15, Erick Erickson 
wrote:

> There are a number of tests failing 100% of the time. I should be able to
> push a fix momentarily, it’s an NPE that seems straightforward to cure.
>
>
>
> In the interests of getting this out of people’s way ASAP, I’m going to
> push the fix after getting a few tests that have been failing to run,
> _then_ run the full test suite. If that doesn’t work I’ll roll back to
> before this problem started.
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
Regards,

Atri
Apache Concerted

Failing tests 100% of the time.

[Erick Erickson]

There are a number of tests failing 100% of the time. I should be able to push 
a fix momentarily, it’s an NPE that seems straightforward to cure.

In the interests of getting this out of people’s way ASAP, I’m going to push 
the fix after getting a few tests that have been failing to run, _then_ run the 
full test suite. If that doesn’t work I’ll roll back to before this problem 
started.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org