Re: What should we do of branch_8x?

[Noble Paul]

I think this is a reasonable suggestion Uwe.

- We don't need to bring Gradle to 8.x
- We can release 8.12 from a fork of 8.11.
- we don't need to keep the Lucene source files in that branch. We can nuke
it and just keep the Lucene binaries

On Mon, Nov 22, 2021, 8:49 AM Uwe Schindler  wrote:

> Hi,
>
> If this is really needed, I'd propose the following:
>
> - fork the branch_8_11 to solr's repo
> - delete all subdirectories below lucene, keep common-build and other
> stuff.
> - add a single ivy.xml there that refers to all lucene jars of 8.11.x
> (latest)
> - adapt solr's "copy-lucene-jars" ant task to copy the ivy output dir
> - delete the lucene stuff from release wizard.
>
> This is quick and easy. Adapting Gradle for a minor release is too hard.
>
> Am 21. November 2021 21:34:40 UTC schrieb Noble Paul  >:
>>
>> All Solr users using 8x and they will need some time to get comfortable
>> with 9x . So, there is a good chance we may need to release an 8.12 based
>> on Lucene 8.11
>>
>> On Mon, Nov 22, 2021, 8:22 AM Adrien Grand  wrote:
>>
>>> +1 to making branch_8x read-only as Uwe suggested
>>>
>>> I think Uwe's other point is also important: if we ever wanted to do a
>>> Solr 8.12, it'd probably be a better option to fork the 8.11 branch than to
>>> try to reuse branch_8x. So we don't need to tie the decision about what we
>>> want to do with branch_8x with future plans around an 8.12 release?
>>>
>>> On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:
>>>
>>>> This is of course all possible, but: WHY the heck do this?
>>>>
>>>>
>>>>
>>>> Lucene 9.0 will come out likely very soon. After that just update the
>>>> gradle file of Solr main and remove the temporary repository (better
>>>> comment it out). After that adapt some changes and release Solr 9.0.
>>>>
>>>>
>>>>
>>>> From that point on both projects have a clear split point and everybody
>>>> can make sure that the backwards compatibility is handled according to
>>>> project’s needs.
>>>>
>>>>
>>>>
>>>> If the Solr 9.0 release is a intermediary point (not all deprecations
>>>> removed), release Solr 10.0 four months later, who cares? Solr 9.0 will be
>>>> the release with many new features and Java 11 as minimum requirement.
>>>>
>>>>
>>>>
>>>> I would really, really not start and fuck up the release process for
>>>> 8.x! Why not release 8.11.1 soon, if you have any changes in Solr to do?
>>>> Why do this release needs to be called 8.12? It is just a version number,
>>>> so why the heck this big issues? I won’t think that Solr will add any major
>>>> features before Solr 9. So what is your exact problem?
>>>>
>>>>
>>>>
>>>> Sorry, but this discussion is complete nonsense. Its just version
>>>> numbers and some hick-hack between two parties that disagree. Keep calm and
>>>> don’t try to make it overcomplicated!
>>>>
>>>>
>>>>
>>>> I never said that we should kill or delete branch_8x. It can stay there
>>>> forever. I just suggested to make it read-only and add a note. Unless
>>>> there’s really a need to do some 8.12 release (in which case, I’d fork 8.11
>>>> branch and move Lucene) I see no reason to act and fuck up the repositories
>>>> of both projects which have now a very clear state.
>>>>
>>>>
>>>>
>>>> Uwe
>>>>
>>>>
>>>>
>>>> -
>>>>
>>>> Uwe Schindler
>>>>
>>>> Achterdiek 19, D-28357 Bremen
>>>>
>>>> https://www.thetaphi.de
>>>>
>>>> eMail: u...@thetaphi.de
>>>>
>>>>
>>>>
>>>> *From:* Gus Heck 
>>>> *Sent:* Sunday, November 21, 2021 5:05 PM
>>>> *To:* dev 
>>>> *Subject:* Re: What should we do of branch_8x?
>>>>
>>>>
>>>>
>>>> Release of Solr 8.12 It should require the current lucene-solr 8.x
>>>> branch to remove the lucene bits and declare a dependency on lucene 8.11
>>>> lucene, that bit shouldn't be too hard if done soon... and the release
>>>> process for 8.x would not publish a lucene artifact which is likely the
>>>> harder bit. I think the option should be open assuming someone is willing
>>>

Re: What should we do of branch_8x?

[Noble Paul]

All Solr users using 8x and they will need some time to get comfortable
with 9x . So, there is a good chance we may need to release an 8.12 based
on Lucene 8.11

On Mon, Nov 22, 2021, 8:22 AM Adrien Grand  wrote:

> +1 to making branch_8x read-only as Uwe suggested
>
> I think Uwe's other point is also important: if we ever wanted to do a
> Solr 8.12, it'd probably be a better option to fork the 8.11 branch than to
> try to reuse branch_8x. So we don't need to tie the decision about what we
> want to do with branch_8x with future plans around an 8.12 release?
>
> On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:
>
>> This is of course all possible, but: WHY the heck do this?
>>
>>
>>
>> Lucene 9.0 will come out likely very soon. After that just update the
>> gradle file of Solr main and remove the temporary repository (better
>> comment it out). After that adapt some changes and release Solr 9.0.
>>
>>
>>
>> From that point on both projects have a clear split point and everybody
>> can make sure that the backwards compatibility is handled according to
>> project’s needs.
>>
>>
>>
>> If the Solr 9.0 release is a intermediary point (not all deprecations
>> removed), release Solr 10.0 four months later, who cares? Solr 9.0 will be
>> the release with many new features and Java 11 as minimum requirement.
>>
>>
>>
>> I would really, really not start and fuck up the release process for 8.x!
>> Why not release 8.11.1 soon, if you have any changes in Solr to do? Why do
>> this release needs to be called 8.12? It is just a version number, so why
>> the heck this big issues? I won’t think that Solr will add any major
>> features before Solr 9. So what is your exact problem?
>>
>>
>>
>> Sorry, but this discussion is complete nonsense. Its just version numbers
>> and some hick-hack between two parties that disagree. Keep calm and don’t
>> try to make it overcomplicated!
>>
>>
>>
>> I never said that we should kill or delete branch_8x. It can stay there
>> forever. I just suggested to make it read-only and add a note. Unless
>> there’s really a need to do some 8.12 release (in which case, I’d fork 8.11
>> branch and move Lucene) I see no reason to act and fuck up the repositories
>> of both projects which have now a very clear state.
>>
>>
>>
>> Uwe
>>
>>
>>
>> -
>>
>> Uwe Schindler
>>
>> Achterdiek 19, D-28357 Bremen
>>
>> https://www.thetaphi.de
>>
>> eMail: u...@thetaphi.de
>>
>>
>>
>> *From:* Gus Heck 
>> *Sent:* Sunday, November 21, 2021 5:05 PM
>> *To:* dev 
>> *Subject:* Re: What should we do of branch_8x?
>>
>>
>>
>> Release of Solr 8.12 It should require the current lucene-solr 8.x branch
>> to remove the lucene bits and declare a dependency on lucene 8.11 lucene,
>> that bit shouldn't be too hard if done soon... and the release process for
>> 8.x would not publish a lucene artifact which is likely the harder bit. I
>> think the option should be open assuming someone is willing to do that
>> work.What should not be an option is any further lucene releases on 8.x
>> and I'd be very leery of any attempt to consume lucene 9.0 on Solr 8.x
>>
>>
>>
>> The Lucene guarantees are irrelevant unless someone contemplates
>> releasing an 8.12 lucene, and I really think that would require a positive
>> vote from the Lucene PMC (which sounds very unlikely since I see fingers
>> twitching over the -1 holsters there :) )
>>
>>
>>
>> So while I don't favor deleting the entire solr 8.x branch I think it's
>> now fine to remove lucene from it.
>>
>>
>>
>> To make things pretty, one could push the 8.x branch to the solr repo
>> AFTER lucene is removed, but that sounds like busy work unless there is
>> some formal or financial need to close the old repo. They are now fully
>> separate projects and what solr does with the non-lucene bits is not a
>> concern to lucene pmc (though almost all of us are on both committees of
>> course, but hat wearing etc..)
>>
>>
>>
>> On Sun, Nov 21, 2021 at 8:43 AM Robert Muir  wrote:
>>
>> I dunno, this seems really crazy to me. Splitting out solr into its
>> own repository and allowing it to be released independently from
>> lucene has already been done, lots of work :) Why not just move
>> forwards?
>>
>> On Sun, Nov 21, 2021 at 8:16 AM Ishan Chattopadhyaya
>>  wrote:
>> >
>> >
>> >
>> > On Sun, 21 Nov, 2021, 6:31 pm Robert Muir,  wrote:
>> >>
>> >> Sorry, I just don't understand the implications of what you are
>> suggesting.
>> >>
>> >> The code in question is lucene+solr combined, and the build system and
>> >> packaging and everything only knows how to do that. So are you forking
>> >> all the lucene code into the solr repo too?
>> >
>> >
>> > Need to split it up and remove the Lucene code from there in order to
>> be able to release Solr independently. We can do so later (I'm currently on
>> travel), if/when needed.
>> >>
>> >>
>> >> I don't really understand your need to have a branch_8x. we can nuke
>> >> it, and you can do any of this from a branch_8_11 some other day, no?
>> >

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Noble Paul]

+1


On Tue, May 18, 2021 at 9:30 PM Colvin Cowie  wrote:
>
> Hello,
>
> I raised SOLR-15410 yesterday with a PR to fix an issue with GC logging when 
> using new versions of OpenJ9. It's small, so if somebody could have a look at 
> it in time for 8.9 that would be great
>
> Thanks,
> Colvin
>
> On Thu, 13 May 2021 at 17:52, Nhat Nguyen  
> wrote:
>>
>> Hi Mayya,
>>
>> I would like to backport LUCENE-9935, which enables bulk-merge for stored 
>> fields with index sort, to 8.x this weekend. The patch is ready, but we 
>> prefer to give CI some cycles before backporting. Please let me know if it's 
>> okay with the release plan.
>>
>> Thanks,
>> Nhat
>>
>> On Thu, May 13, 2021 at 12:44 PM Gus Heck  wrote:
>>>
>>> Perhaps https://issues.apache.org/jira/browse/SOLR-15378 should be 
>>> investigated before 8.9, maybe make it a blocker?
>>>
>>> On Thu, May 13, 2021 at 1:35 AM Robert Muir  wrote:
>>>>
>>>> Mayya, I created backport for Adrien's issue here, to try to help out:
>>>> https://github.com/apache/lucene-solr/pull/2495
>>>>
>>>> Personally, I felt that merging non-trivial changes from main branch
>>>> to 8.x has some additional risks when cherry-picking:
>>>> * structural changes in main branch making merging more difficult
>>>> (e.g. LUCENE-9705 reorganization of codec versioning, great change
>>>> moving forwards though)
>>>> * there are many style changes due to spotless in main branch which
>>>> add noise to merging against old code.
>>>> * In the specific case of LUCENE-9827, the usual additional tricky
>>>> backwards compatibility for 8.x must be added in the backport (due to
>>>> minor version bumps there) which can go wrong.
>>>>
>>>> I still think that particular change is worth considering for 8.9, it
>>>> isn't just a performance bug but also a huge improvement to test
>>>> coverage that helps combat risks.
>>>>
>>>> But we should still take some precautions when releasing an 8.x IMO:
>>>> * be mindful of what we are backporting and the risks involved: it is 
>>>> harder.
>>>> * try to let jenkins bake changes in 8.x branches for longer than
>>>> usual? even a few days really helps.
>>>>
>>>> On Tue, May 11, 2021 at 1:29 PM Mayya Sharipova
>>>>  wrote:
>>>> >
>>>> > Thanks everyone,
>>>> >
>>>> > Adrien, I  am happy to try to be a release manager for this release.
>>>> >
>>>> > Adrien, and Gus, please let me know when your changes are merged to 8.x
>>>> >
>>>> >
>>>> >
>>>> > On Tue, May 11, 2021 at 10:38 AM Gus Heck  wrote:
>>>> >>
>>>> >> I'm also looking to find time to get 
>>>> >> https://issues.apache.org/jira/browse/SOLR-14597 into some sort of 8x. 
>>>> >> I've recently completed the back port of 2/3 of the lucene tickets that 
>>>> >> are related, and hope to work on the third tomorrow
>>>> >>
>>>> >> I had some feedback there, but I think folks were waiting for the 
>>>> >> version integrated with the final form of the Lucene tickets before 
>>>> >> delving further. Hopefully this week I can start on a patch that does 
>>>> >> that.
>>>> >>
>>>> >> On Tue, May 11, 2021 at 10:25 AM Adrien Grand  wrote:
>>>> >>>
>>>> >>> I would like to backport LUCENE-9827 before we release 8.9, a 
>>>> >>> performance regression to stored fields merges. I'll work on this as 
>>>> >>> soon as possible.
>>>> >>>
>>>> >>> On Thu, May 6, 2021 at 10:28 PM Adrien Grand  wrote:
>>>> >>>>
>>>> >>>> +1
>>>> >>>>
>>>> >>>> Mayya, are you volunteering to be the release manager?
>>>> >>>>
>>>> >>>> Le jeu. 6 mai 2021 à 18:06, Ishan Chattopadhyaya 
>>>> >>>>  a écrit :
>>>> >>>>>
>>>> >>>>> +1
>>>> >>>>>
>>>> >>>>> On Thu, May 6, 2021 at 7:50 PM Mayya Sharipova 
>>>> >>>>>  wrote:
>>>> >>>>>>
>>>> >>>>>> Hello everyone,
>>>> >>>>>> I was wondering if we can have a 8.9.0 release. It has been more 
>>>> >>>>>> than 3 months since 8.8.0 was released.
>>>> >>>>>> 8.9.0 doesn't need to be the last release in the 8.x series.
>>>> >>>>>>
>>>> >>>>>> Thanks.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> --
>>>> >>> Adrien
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> http://www.needhamsoftware.com (work)
>>>> >> http://www.the111shift.com (play)
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>
>>>
>>>
>>> --
>>> http://www.needhamsoftware.com (work)
>>> http://www.the111shift.com (play)



-- 
-
Noble Paul

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

Re: Doubling down on our mistakes?

[Noble Paul]

Hi AB,
Please accept my I apologies for the heated discussion. The objective
was not that at all.

I saw the real damage that was caused to our client. It was
devastating. We were a little worried about the same happening to
another user who might upgrade.

So, I suggested a revert.

Whatever happened after that was due to the stress the situation has
put us in. We asked our client to upgrade from 8.4 and to 8.8 and the
cluster had a meltdown.

Please let's forget about what has transpired in the JIRA and let's
get back to saving the next user from such a meltdown

1) warn our users from upgrading from 8.4 (if they have not already done it)
2) revert this change and do a break fix release
3) Fix the actual bug that caused the null node_name in the first place

regards
Noble Paul


On Tue, May 18, 2021 at 10:22 PM Andrzej Białecki  wrote:
>
> Ishan, as I pointed out in Jira I don’t care for you implying that I have 
> evil intentions, I resent also your implication that I’m behaving 
> irrationally or don’t care for the users. Those of you who are interested may 
> read the comments in Jira and judge for themselves.
>
> You conveniently don’t mention that I WITHDREW my objection, and instead 
> proposed a lenient validation (but validation nonetheless!). It’s easy to 
> scream “revert! revert!” but it actually takes some consideration to properly 
> address the original purpose of this change - that is, detecting and avoiding 
> the corruption of replica state. Let’s focus on this and not on pointing 
> fingers.
>
> As for the production outage - I’m sorry this happened to you. As I hope you 
> and Noble and others are sorry for other inadvertently introduced bugs, which 
> I’m sure brought down many clusters at inconvenient hours...
>
>
> On 18 May 2021, at 13:26, Ishan Chattopadhyaya  
> wrote:
>
> https://issues.apache.org/jira/browse/SOLR-14245
>
> There was a production outage at odd hours at my (and Noble's) client, due to 
> this above change in Solr 8.5 onwards by Andrzej Bialecki.
>
> In short, there is some bug in Solr where a replica gets "null" as the 
> node_name (upon invocation of a collection API command). On the rare 
> occasions where we encountered such situations in the past, the replica would 
> be unavailable and the system would work fine overall. However, this change 
> (which introduces strict validation of errors while *reading* Replica 
> objects) now means that if such a situation arises (where some Solr's APIs 
> itself results in node_name being null in a state.json), all SolrJ clients 
> and all Solr nodes will go for a toss (possibly crash, and not start back up).
>
> This change was rushed in, without any discussions or review, without 
> extensive testing for the failures it will cause on existing systems where 
> cluster state is messed up but system is running, and without any 
> consideration for the impact on users.
>
> Noble and I are of the opinion that this change should be reverted 
> immediately, considering the impact to users. However, there is strong 
> disagreement on Andrzej's part.
>
> Mistakes happen, but doubling down on them irrationally [1] will destroy the 
> reputation of the project, let alone the peace of mind of those who are 
> running Solr in production.
>
> Does someone have any thoughts or opinions?
>
> [1] - 
> https://issues.apache.org/jira/browse/SOLR-14245?focusedCommentId=17346758=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17346758
>
>


-- 
-
Noble Paul

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

Re: Separate git repo(s) for Solr modules

[Noble Paul]

@Ilan Ginzburg 

I don't think the project split is counter productive because we have
lucene as a sub module. Solr does not use lucene like a simple library.
It's an integral part of Solr


On Tue, May 4, 2021 at 10:02 PM Ilan Ginzburg  wrote:

> As with any dependency on any project, you update the dependency project
> first then consume the updated dependency in Solr.
>
> If the idea is to be able to modify Lucene and Solr in parallel, then the
> project split is counterproductive.
>
> From the Solr perspective, Lucene and Zookerper are really two “similar”
> dependencies and IMO we should think about them in that way.
>
> Ilan
>
> On Tue 4 May 2021 at 09:45, Noble Paul  wrote:
>
>> @Houston
>>
>> So, Are you suggesting we should not do that ?
>>
>> On Tue, May 4, 2021 at 2:35 PM Houston Putman 
>> wrote:
>>
>>> In the future we wont be able to “work on both at the same time”, once
>>> Lucene 9 is cut. Why not pull that bandaid now?
>>>
>>> On Mon, May 3, 2021 at 11:32 PM Noble Paul  wrote:
>>>
>>>> I'm still struggling to understand the workflow when I'm working on a
>>>> feature that spans lucene and solr.
>>>>
>>>> I'm yet to see an argument against sub-modules
>>>>
>>>> On Wed, Feb 17, 2021 at 3:18 AM Jason Gerlowski 
>>>> wrote:
>>>>
>>>>> > Shoving such a component into lucene-solr repo makes no sense, given
>>>>> its branching strategy is based on master / branch_8x
>>>>>
>>>>> I get how this could cause issues - I def hadn't thought much about
>>>>> multi-version support and branching.  But I don't think moving plugins
>>>>> to a separate repo solves that problem for us.  If our first class
>>>>> plugins are set up to have different release "lines" that don't line
>>>>> up with major Solr versions, it's only a matter of time before two of
>>>>> those plugins have branch requirements that conflict.  Unless I'm
>>>>> missing something here?
>>>>>
>>>>> > I'd prefer that a module only leave our "contribs" area when the
>>>>> concerns/limitations become real.  Doing it prematurely could lead to
>>>>> atrophy of the module
>>>>>
>>>>> +1 to David's comment.   I def hadn't considered the branching-scheme
>>>>> issues that Ishan brought up in his last reply, and they seem like
>>>>> valid concerns to me.  But the risk and the downsides of "atrophy" are
>>>>> serious enough that I'd vote to not risk them until this starts to
>>>>> cause us issues in practice.  Even if, for now, that means we won't be
>>>>> able to build a single plugin jar that supports (e.g.) 3 major Solr
>>>>> versions.  IMO that's a much smaller loss.
>>>>>
>>>>> On Tue, Feb 16, 2021 at 9:40 AM David Smiley 
>>>>> wrote:
>>>>> >
>>>>> > On Tue, Feb 16, 2021 at 8:38 AM Eric Pugh <
>>>>> ep...@opensourceconnections.com> wrote:
>>>>> >>
>>>>> >> Testing across multiple versions is always very difficult ;-).  I
>>>>> recently saw this very interesting approach to using our Dockerized Solr’s
>>>>> to test a component against a number of previous versions of Solr.
>>>>> https://github.com/querqy/querqy/pull/147. I’m hopeful it could be a
>>>>> model for other packages to adopt.
>>>>> >
>>>>> >
>>>>> > Thanks for the link to that Querqy PR.  That is *very* similar to
>>>>> what I do at work (minus multi-version testing), and also similar to how I
>>>>> test multiple versions in one of my pet projects by using a CI build 
>>>>> matrix
>>>>> of a configurable dependency.  I didn't know Testcontainer.org has its own
>>>>> Solr module -- https://www.testcontainers.org/modules/solr/ but we
>>>>> implemented that ourselves; not hard.
>>>>> >
>>>>> >>
>>>>> >> Trying to maintain across multiple versions is kind of a Sisyphean
>>>>> task, and I don’t think plays to open source communities strengths.   It’s
>>>>> hard enough to keep all components of Solr up to date with the latest
>>>>> Lucene and the latest Solr….  (Try out wt=xlsx Response Writer, it’s
>>>>> currently broken on mast

Re: Separate git repo(s) for Solr modules

[Noble Paul]

@Houston

So, Are you suggesting we should not do that ?

On Tue, May 4, 2021 at 2:35 PM Houston Putman 
wrote:

> In the future we wont be able to “work on both at the same time”, once
> Lucene 9 is cut. Why not pull that bandaid now?
>
> On Mon, May 3, 2021 at 11:32 PM Noble Paul  wrote:
>
>> I'm still struggling to understand the workflow when I'm working on a
>> feature that spans lucene and solr.
>>
>> I'm yet to see an argument against sub-modules
>>
>> On Wed, Feb 17, 2021 at 3:18 AM Jason Gerlowski 
>> wrote:
>>
>>> > Shoving such a component into lucene-solr repo makes no sense, given
>>> its branching strategy is based on master / branch_8x
>>>
>>> I get how this could cause issues - I def hadn't thought much about
>>> multi-version support and branching.  But I don't think moving plugins
>>> to a separate repo solves that problem for us.  If our first class
>>> plugins are set up to have different release "lines" that don't line
>>> up with major Solr versions, it's only a matter of time before two of
>>> those plugins have branch requirements that conflict.  Unless I'm
>>> missing something here?
>>>
>>> > I'd prefer that a module only leave our "contribs" area when the
>>> concerns/limitations become real.  Doing it prematurely could lead to
>>> atrophy of the module
>>>
>>> +1 to David's comment.   I def hadn't considered the branching-scheme
>>> issues that Ishan brought up in his last reply, and they seem like
>>> valid concerns to me.  But the risk and the downsides of "atrophy" are
>>> serious enough that I'd vote to not risk them until this starts to
>>> cause us issues in practice.  Even if, for now, that means we won't be
>>> able to build a single plugin jar that supports (e.g.) 3 major Solr
>>> versions.  IMO that's a much smaller loss.
>>>
>>> On Tue, Feb 16, 2021 at 9:40 AM David Smiley  wrote:
>>> >
>>> > On Tue, Feb 16, 2021 at 8:38 AM Eric Pugh <
>>> ep...@opensourceconnections.com> wrote:
>>> >>
>>> >> Testing across multiple versions is always very difficult ;-).  I
>>> recently saw this very interesting approach to using our Dockerized Solr’s
>>> to test a component against a number of previous versions of Solr.
>>> https://github.com/querqy/querqy/pull/147. I’m hopeful it could be a
>>> model for other packages to adopt.
>>> >
>>> >
>>> > Thanks for the link to that Querqy PR.  That is *very* similar to what
>>> I do at work (minus multi-version testing), and also similar to how I test
>>> multiple versions in one of my pet projects by using a CI build matrix of a
>>> configurable dependency.  I didn't know Testcontainer.org has its own Solr
>>> module -- https://www.testcontainers.org/modules/solr/ but we
>>> implemented that ourselves; not hard.
>>> >
>>> >>
>>> >> Trying to maintain across multiple versions is kind of a Sisyphean
>>> task, and I don’t think plays to open source communities strengths.   It’s
>>> hard enough to keep all components of Solr up to date with the latest
>>> Lucene and the latest Solr….  (Try out wt=xlsx Response Writer, it’s
>>> currently broken on master) .  Reminds me of the Apache Gump project ;-)
>>> >>
>>> >> If something is really going to be backcompatible across certain
>>> versions, then maybe having it’s own repo makes sense,
>>> >
>>> >
>>> > I'd prefer that a module only leave our "contribs" area when the
>>> concerns/limitations become real.  Doing it prematurely could lead to
>>> atrophy of the module
>>> >
>>> >>
>>> >> but I suspect it means those components may go stale….   Look at DIH
>>> and Velocity components that are moved over to their own repos, both are
>>> getting stale, and I’d argue it’s because they don’t live in the main
>>> project where all of us have oversight and easy access.
>>> >
>>> >
>>> > Agreed :-(
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>> --
>> -
>> Noble Paul
>>
>

-- 
-
Noble Paul

Re: Separate git repo(s) for Solr modules

[Noble Paul]

I'm still struggling to understand the workflow when I'm working on a
feature that spans lucene and solr.

I'm yet to see an argument against sub-modules

On Wed, Feb 17, 2021 at 3:18 AM Jason Gerlowski 
wrote:

> > Shoving such a component into lucene-solr repo makes no sense, given its
> branching strategy is based on master / branch_8x
>
> I get how this could cause issues - I def hadn't thought much about
> multi-version support and branching.  But I don't think moving plugins
> to a separate repo solves that problem for us.  If our first class
> plugins are set up to have different release "lines" that don't line
> up with major Solr versions, it's only a matter of time before two of
> those plugins have branch requirements that conflict.  Unless I'm
> missing something here?
>
> > I'd prefer that a module only leave our "contribs" area when the
> concerns/limitations become real.  Doing it prematurely could lead to
> atrophy of the module
>
> +1 to David's comment.   I def hadn't considered the branching-scheme
> issues that Ishan brought up in his last reply, and they seem like
> valid concerns to me.  But the risk and the downsides of "atrophy" are
> serious enough that I'd vote to not risk them until this starts to
> cause us issues in practice.  Even if, for now, that means we won't be
> able to build a single plugin jar that supports (e.g.) 3 major Solr
> versions.  IMO that's a much smaller loss.
>
> On Tue, Feb 16, 2021 at 9:40 AM David Smiley  wrote:
> >
> > On Tue, Feb 16, 2021 at 8:38 AM Eric Pugh <
> ep...@opensourceconnections.com> wrote:
> >>
> >> Testing across multiple versions is always very difficult ;-).  I
> recently saw this very interesting approach to using our Dockerized Solr’s
> to test a component against a number of previous versions of Solr.
> https://github.com/querqy/querqy/pull/147. I’m hopeful it could be a
> model for other packages to adopt.
> >
> >
> > Thanks for the link to that Querqy PR.  That is *very* similar to what I
> do at work (minus multi-version testing), and also similar to how I test
> multiple versions in one of my pet projects by using a CI build matrix of a
> configurable dependency.  I didn't know Testcontainer.org has its own Solr
> module -- https://www.testcontainers.org/modules/solr/ but we implemented
> that ourselves; not hard.
> >
> >>
> >> Trying to maintain across multiple versions is kind of a Sisyphean
> task, and I don’t think plays to open source communities strengths.   It’s
> hard enough to keep all components of Solr up to date with the latest
> Lucene and the latest Solr….  (Try out wt=xlsx Response Writer, it’s
> currently broken on master) .  Reminds me of the Apache Gump project ;-)
> >>
> >> If something is really going to be backcompatible across certain
> versions, then maybe having it’s own repo makes sense,
> >
> >
> > I'd prefer that a module only leave our "contribs" area when the
> concerns/limitations become real.  Doing it prematurely could lead to
> atrophy of the module
> >
> >>
> >> but I suspect it means those components may go stale….   Look at DIH
> and Velocity components that are moved over to their own repos, both are
> getting stale, and I’d argue it’s because they don’t live in the main
> project where all of us have oversight and easy access.
> >
> >
> > Agreed :-(
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
-
Noble Paul

Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!

[Noble Paul]

Congrats Jan

On Sun, Feb 21, 2021, 3:04 AM Marcus Eagan  wrote:

> Awesome, way to go Jan!
>
> - Marcus
>
> On Sat, Feb 20, 2021 at 10:53 Lucky Sharma  wrote:
>
>> Congratulations Jan
>>
>> Regards,
>> Lucky Sharma
>>
>> On Sat, 20 Feb 2021 at 8:07 PM, Karl Wright  wrote:
>>
>>> Congratulations!
>>> Karl
>>>
>>> On Sat, Feb 20, 2021 at 6:28 AM Uwe Schindler  wrote:
>>>
 Congrats Jan!



 Uwe



 -

 Uwe Schindler

 Achterdiek 19, D-28357 Bremen
 

 https://www.thetaphi.de

 eMail: u...@thetaphi.de



 *From:* Anshum Gupta 
 *Sent:* Thursday, February 18, 2021 7:55 PM
 *To:* Lucene Dev ; solr-u...@lucene.apache.org
 *Subject:* Congratulations to the new Apache Solr PMC Chair, Jan
 Høydahl!



 Hi everyone,



 I’d like to inform everyone that the newly formed Apache Solr PMC
 nominated and elected Jan Høydahl for the position of the Solr PMC Chair
 and Vice President. This decision was approved by the board in its February
 2021 meeting.



 Congratulations Jan!



 --

 Anshum Gupta

>>> --
>> Warm Regards,
>>
>> Lucky Sharma
>> Contact No :+91 9821559918
>>
> --
> Marcus Eagan
>
>

Re: Congratulations to the new Lucene PMC Chair, Michael Sokolov!

[Noble Paul]

Congrats

On Thu, Feb 18, 2021 at 11:04 PM Atri Sharma  wrote:
>
> Congratulations!
>
> On Thu, 18 Feb 2021, 17:31 Jan Høydahl,  wrote:
>>
>> Congratulations Mike!
>>
>> Jan Høydahl
>>
>> > 17. feb. 2021 kl. 22:31 skrev Anshum Gupta :
>> >
>> > 
>> > Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice 
>> > President position.
>> >
>> > This year we nominated and elected Michael Sokolov as the Chair, a 
>> > decision that the board approved in its February 2021 meeting.
>> >
>> > Congratulations, Mike!
>> >
>> > --
>> > Anshum Gupta
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>


-- 
-
Noble Paul

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

Re: [VOTE] Release Lucene/Solr 8.8.1 RC2

[Noble Paul]

SUCCESS! [1:04:46.520370]

+1 Binding

On Wed, Feb 17, 2021 at 1:44 PM Timothy Potter  wrote:
>
> And I continue to struggle with the python3 command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC2-rev64f3b496bfee762a9d2dbff40700f457f4464dfe
>
> On Tue, Feb 16, 2021 at 7:41 PM Timothy Potter  wrote:
> >
> > Please vote for release candidate 2 for Lucene/Solr 8.8.1
> >
> > The artifacts can be downloaded from:
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC2-rev64f3b496bfee762a9d2dbff40700f457f4464dfe
> >
> > 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.8.1-RC2-rev64f3b496bfee762a9d2dbff40700f457f4464dfe
> >
> > The vote will be open for at least 72 hours i.e. until 2021-02-20 03:00 UTC.
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > Here is my +1 SUCCESS! [0:50:07.947952]
> >
> > Also, as with RC1, in addition to the smoke test, I built a Docker
> > image from the RC locally and verified:
> >
> > a. A rolling upgrade of a 3-node 8.7.0 cluster to the 8.8.1 RC
> > completes successfully w/o any NPEs or weirdness with leader election
> > / recoveries.
> > b. The base_url property is stored in replica state after the upgrade
> > c. A basic client application built with SolrJ 8.7.0 can load cluster
> > state info directly from ZK and query the 8.8.1 RC2 servers.
> > d. Same client app built with SolrJ 8.8.0 works as well.
> >
> > As this bug-fix release is primarily needed to address a SolrJ
> > back-compat break (SOLR-15145) and unfortunately our smoke tester
> > framework does not test for backcompat of older SolrJ against the RC,
> > I ask others to please test rolling upgrades of servers (ideally
> > multi-node clusters) running pre-8.8.0 to this RC if possible. Also,
> > please try client applications that are using an older SolrJ, esp.
> > those that load cluster state directly from ZK.
> >
> > Best regards,
> > Tim
>
> -----
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: [VOTE] Release Lucene/Solr 8.8.1 RC1

[Noble Paul]

@Anshum Gupta

The failure seems to be because of a timeout during collection
creation. My h/w is really fast and beefy and may be that's why it
doesn't get reproduced. We have sped up collection creation
significantly in branch_8x. Can you please re run the same tests on 8x
branch please? If it's already fixed may be we should spin an RC2 with
the latest fixes

On Tue, Feb 16, 2021 at 5:02 PM Anshum Gupta  wrote:
>
> Interesting.
>
> I didn't use the flag, but just changed the code to comment out the 
> randomization from SolrCloudTestCase.java.
>
> I think Tim did the same, so I'm not sure if that's the difference or if 
> there's a difference of environment.
>
> On Mon, Feb 15, 2021 at 9:48 PM Ishan Chattopadhyaya 
>  wrote:
>>
>> I did another round of beast, this time setting that flag to true (as 
>> suggested to me by Noble).
>>
>> ant -Duse.perreplica=true -Dtests.dups=1 -Dtests.iters=5 -Dbeast.iters=5 
>> -Dtestcase=SolrCloudReportersTest beast
>>
>> -beast:
>>   [beaster] Beast round 1 results: 
>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/1
>>   [beaster] Beast round 2 results: 
>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/2
>>   [beaster] Beast round 3 results: 
>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/3
>>   [beaster] Beast round 4 results: 
>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/4
>>   [beaster] Beast round 5 results: 
>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/5
>>   [beaster] Beasting finished Successfully.
>>
>>
>> I'm not sure what's going on :-(
>>
>> On Tue, Feb 16, 2021 at 11:13 AM Anshum Gupta  wrote:
>>>
>>> Ishan/Noble, thanks for taking a look at this.
>>>
>>> I only just started to look at the cause, so I'm sure you have better 
>>> context on why this is failing and if it makes sense to still release with 
>>> this issue.
>>>
>>> FYI, I was able to get a successful smoke test run finally, but the fact 
>>> that it took me over 7 runs.
>>>
>>> Also, can you confirm how did you run the test? you might be getting lucky 
>>> with the randomization here. Both me and Tim just commented out the 
>>> randomization for USE_PER_REPLICA_STATE and hardcoding this value to true 
>>> consistently got the test to fail. The default (false) did get the test to 
>>> pass 100% of the times.
>>>
>>> If you think we can have this fix before the release, it might make more 
>>> sense to have a single release for users as it wouldn't involve tracking 
>>> the complexity of what's broken in a released version. I still would like 
>>> to spend some more time tomorrow before voting on this one, but at least 
>>> the smoke test is out of the way. I'll try and debug this tomorrow.
>>>
>>>
>>> On Mon, Feb 15, 2021 at 8:40 PM Ishan Chattopadhyaya 
>>>  wrote:
>>>>
>>>> I tried light beasting the test on branch_8_8:
>>>> ant -Dtests.dups=1 -Dtests.iters=5 -Dbeast.iters=5 
>>>> -Dtestcase=SolrCloudReportersTest beast
>>>>
>>>> No failures.
>>>>
>>>>   [beaster] Beast round 1 results: 
>>>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/1
>>>>   [beaster] Beast round 2 results: 
>>>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/2
>>>>   [beaster] Beast round 3 results: 
>>>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/3
>>>>   [beaster] Beast round 4 results: 
>>>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/4
>>>>   [beaster] Beast round 5 results: 
>>>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/5
>>>>   [beaster] Beasting finished Successfully.
>>>>
>>>> On Tue, Feb 16, 2021 at 10:07 AM Noble Paul  wrote:
>>>>>
>>>>> @Anshum Gupta
>>>>>
>>>>> I think we should not hold up the release of RC1 because of that failure.
>>>>>
>>>>> This is a new feature and new features take time to get hardened.
>>>>>
>>>>> However, We can investigate and fix this anyway.
>>>>>
>>>>> If required, we can do a 8.8.3
>>>>>
>>>>> On Tue, Feb 16, 2021 at 3:10 PM Ishan Chattopadhyaya
>>>>>  wrote:
>>>>> >
>>>>> > Here's my +1 for the RC1.
>>>>> >
>>>>> > SUCCESS! [0:42:38.936787]
>>>>

Re: [VOTE] Release Lucene/Solr 8.8.1 RC1

[Noble Paul]

@Anshum Gupta

I think we should not hold up the release of RC1 because of that failure.

This is a new feature and new features take time to get hardened.

However, We can investigate and fix this anyway.

If required, we can do a 8.8.3

On Tue, Feb 16, 2021 at 3:10 PM Ishan Chattopadhyaya
 wrote:
>
> Here's my +1 for the RC1.
>
> SUCCESS! [0:42:38.936787]
>
> On Tue, Feb 16, 2021 at 9:02 AM Ishan Chattopadhyaya 
>  wrote:
>>
>> Per Replica States is a new feature introduced in 8.8.0. It will require a 
>> critical bugfix (SOLR-15138) immediately after 8.8.1 (in a 8.8.2 release). 
>> If this issue is confirmed to be PRS related, then I think we should 
>> continue with this release and fix PRS in 8.8.2.
>>
>> However, if you still want us to investigate and fix this issue now, we can 
>> take a look. If you have a failing seed handy, please let me know.
>>
>> On Tue, Feb 16, 2021 at 8:33 AM Ishan Chattopadhyaya 
>>  wrote:
>>>
>>> Surprising. I'll take a look.
>>>
>>> On Tue, 16 Feb, 2021, 7:29 am Anshum Gupta,  wrote:
>>>>
>>>> I've unsuccessfully tried getting the smoketester to pass and have had 6 
>>>> fails so far.
>>>>
>>>> At this point it seems like SolrCloudReporterTest and 
>>>> AutoscalingHistoryTest tests are failing pretty consistently for me.
>>>>
>>>> The former is a new failure, and seems to be caused by the 
>>>> USE_PER_REPLICA_STATE randomization.
>>>>
>>>> Both Tim and me tried running the tests without the randomization and 
>>>> defaulting that property to false gets the tests to pass, however it seems 
>>>> to be failing every time the value for USE_PER_REPLICA_STATE is set to 
>>>> true.
>>>>
>>>> I'm not voting -1 yet, as I'm not sure how much this affects the build vs 
>>>> the test, but once we have a clearer picture, we might need a fix and have 
>>>> to respin this.
>>>>
>>>> -Anshum
>>>>
>>>> On Sun, Feb 14, 2021 at 8:31 AM Timothy Potter  
>>>> wrote:
>>>>>
>>>>> Looks like an extra space got added on the end of the python3 command, 
>>>>> try this one:
>>>>>
>>>>> python3 -u dev-tools/scripts/smokeTestRelease.py 
>>>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Feb 14, 2021 at 9:26 AM Timothy Potter  
>>>>> wrote:
>>>>>>
>>>>>> Please vote for release candidate 1 for Lucene/Solr 8.8.1
>>>>>>
>>>>>>
>>>>>> The artifacts can be downloaded from:
>>>>>>
>>>>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>>>>>>
>>>>>>
>>>>>> 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.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>>>>>>
>>>>>>
>>>>>> The vote will be open for at least 72 hours i.e. until 2021-02-17 17:00 
>>>>>> UTC.
>>>>>>
>>>>>>
>>>>>> Here is my +1 ~ SUCCESS! [0:50:06.728441]
>>>>>>
>>>>>>
>>>>>> In addition to the smoke test, I built a Docker image from 
>>>>>> solr-8.8.1.tgz locally and verified:
>>>>>>
>>>>>>
>>>>>> a. A rolling upgrade of a 3-node 8.7.0 cluster to the 8.8.1 RC completes 
>>>>>> successfully w/o any NPEs or weirdness with leader election / recoveries.
>>>>>>
>>>>>>
>>>>>> b. The base_url property is stored in replica state after the upgrade
>>>>>>
>>>>>>
>>>>>> c. A basic client application built with SolrJ 8.7.0 can load cluster 
>>>>>> state info directly from ZK and query the 8.8.1 RC1 servers.
>>>>>>
>>>>>>
>>>>>> d. Same client app built with SolrJ 8.8.0 works as well.
>>>>>>
>>>>>>
>>>>>> As this bug-fix release is primarily needed to address a SolrJ 
>>>>>> back-compat break (SOLR-15145) and unfortunately our smoke tester 
>>>>>> framework does not test for backcompat of older SolrJ against the RC, I 
>>>>>> ask others to please test rolling upgrades of servers (ideally 
>>>>>> multi-node clusters) running pre-8.8.0 to this RC if possible. Also, 
>>>>>> please try client applications that are using an older SolrJ, esp. those 
>>>>>> that load cluster state directly from ZK.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Anshum Gupta



-- 
-
Noble Paul

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

[ANNOUNCE] Apache Solr 8.8.0 released

[Noble Paul]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted search and analytics, rich document
parsing, geospatial search, extensive REST APIs as well as parallel SQL.
Solr is enterprise grade, secure and highly scalable, providing fault
tolerant distributed search and indexing, and powers the search and
navigation features of many of the world's largest internet sites.

The release is available for immediate download at:

 https://lucene.apache.org/solr/downloads.html

Please read CHANGES.txt for a detailed list of changes:

 https://lucene.apache.org/solr/8_8_0/changes/Changes.html Solr 8.8.0

Release Highlights:

Reducing overseer bottlenecks using per-replica states. More stability and
lesser load on large cluster that use this feature.

Better restart and collection creation performance.

Interleaving support in Learning To Rank

A summary of important changes is published in the Solr Reference Guide at:

 https://lucene.apache.org/solr/guide/8_8/solr-upgrade-notes.html.

For the most exhaustive list, see the full release notes at
https://lucene.apache.org/solr/8_8_0/changes/Changes.html

or

by viewing the CHANGES.txt file accompanying the distribution. Solr's
release notes usually don't include Lucene layer changes. Lucene's release
notes are at

https://lucene.apache.org/core/8_8_0/changes/Changes.html

- -
Noble Paul
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.0.0
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCgAGBQJgF/RnACEJEMOP9ew/z9s+FiEEz85fu5IMPHRc7uCEw4/1
7D/P2z6fzRAAm4AKbeIGWfPK+0nsrZCAPaDucGZYVL0lPQr3eF4jnmhi60dF
Sv9rD5Mq5ZSTTuJlpwoaxowxVp4M1tV1vmCdfBRkgoUD3dwS/snryr/AK69R
zdjjV/BABtcMNA7cMYIrkolGl37g4kI1alLfU36Uf/3M0NfUcw0keW1XuMOr
uV7AzXhZGw4eL4LJt7I7gXJs1kgE6/sPSmoKBVckKisrruiUSYmH9r/EhXXU
YB8cxd5tenMrchbjcOquC9X2JJjB++/LyJw3mFNIO5W3UpjqwtI8IGDo1Sxl
fM32FuAWVVDZsiBKXuRzsIO/iEPfgZFfTcoSJkD0Rt/Q6gJPZIuBmiUFaYfs
9fzufNDuXdPKFEndSHfwdPMJwvk3XA5+xYzhkcQH+3FKOPmYXkvLolOC3j+r
ZtbgI421jDIahpVPbFtgUPB2dM3mw34B73wP5MIOHHxz22tVKe6PBOeihccK
mOr0r1tZHR+11aijYf+Nlhv3hpbpRoDbQ7pRkRyu53Od47p6itZAi60TFFIJ
bDw26wZRNRrEuYhriJUeM7ahvJNlcE6VaO0szUDL5g/x2Oa9jKMHPpsUF9pS
9HbJWcnflxq0iU+sfdv7Eoxzv6zkXMTUsbpT2XjKcZZN5jd2rWV3JfiU6FiZ
jpqJBHzwGan9qKKswNKyDKhoa2jPdSYIbqQ=
=NbSI
-END PGP SIGNATURE-

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

[ANNOUNCE] Apache Lucene 8.8.0 released

[Noble Paul]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

01/02/2021, Apache Lucene™ 8.8 available

The Lucene PMC is pleased to announce the release of Apache Lucene 8.8.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for
nearly any application that requires full-text search, especially
cross-platform.

This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below. The release is
available for immediate download at:

http://lucene.apache.org/core/mirrors-core-latest-redir.html

Lucene 8.8 Release Highlights:

LatLonPoint query that accepts an array of LatLonGeometries, support for
spatial relationships,
XYPoint query that accepts an array of XYGeometries
Doc values now allow configuring how to trade compression for retrieval
speed

Further details of changes are available in the change log available
at: https://lucene.apache.org/core/8_8_0/changes/Changes.html

Please report any feedback to the mailing lists
(http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring
network for distributing releases. It is possible that the mirror you
are using may not have replicated the release yet. If that is the
case, please try another mirror. This also applies to Maven access.

Note: The Apache Software Foundation uses an extensive mirroring network
for
distributing releases. It is possible that the mirror you are using may not
have
replicated the release yet. If that is the case, please try another mirror.

This also applies to Maven access.

- -
Noble Paul
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.0.0
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCgAGBQJgF/NjACEJEMOP9ew/z9s+FiEEz85fu5IMPHRc7uCEw4/1
7D/P2z5DOhAAlPaylatvf6yPGaxFeLXVx/pnLHHzJBgNbfs97z44oUDAnIwb
xM6pUmfJ+akAyRZnHBWozzDqGu+vlG6AO4X8SvKkTkZrbPeLAmkZR1nnSCtP
d3Mw8bv4IZaHCJMF2e19bERtD/mDCi0OKJM8Hxm9Jksv9s1EhjMfmkIgaXX4
A6OQGKKRG118Zxfpg3S5nI1Ij3giVMMqXn/xApxjANvnV0bg3sbyO4SrhsgR
twkbuBW5B0ibL2NUO3Ooax6aFfUeRA+P3gtvpFt1996uJF0yvnx5dWFR96/A
3zSH1m3C0xZO6GC6+zYeOzrCXZ32qHeaSuwEcQaDvPcyQwqe/4SH1+XOPMtD
BZbMiAQDJESnch/lPeujZV8vbXzjSHrH/uXYt+qw/e0YrkymgqayIw+LgE1u
knzbQFszLrjGR0Ygxoin6ZHpJcUWn7a6zhtM6MgVfhx3Yo7o+2Dkdb9wq83y
ZD0vbexd3BXyehu/xjHFc7/DUhrjKJQR2mXKXhxMDmsbKLTFvKO+76HMXTy8
W9hMbG6IxvuFKr7NwHJSDnJUlSWtgX0XHgn+DP/ubYCvFFP0oZQhgAtxsdxi
oBVWHCx0IbN4HiV8p6UUKvYiAaBmVvVMNB4FOCuWeEQj7Eh6SOkhwIy5Q9no
fYLF6wazcLq4hEN1Yj0lmLIqacF6EeMNAzY=
=Mndl
-END PGP SIGNATURE-

-
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.8.0 RC2

[Noble Paul]

Yes, if someone is willing to invest time to fix the failures we
should. totally do it.

Unfortunately, I don't see anyone making that investment


On Sat, Jan 30, 2021 at 12:12 AM Jason Gerlowski  wrote:
>
> I agree with Noble that we shouldn't let those flakies hold up the
> release. It really sucks, but Solr wouldn't've gotten out a release in
> years if that was our bar.
>
> FWIW though I disagree with his finer point that we shouldn't worry
> about autoscaling in particular because it's slated for removal in
> 9.0.  We're not releasing 9.0, we're releasing 8.8.  And there's
> likely to be an 8.8.1 or 8.9 at some point later.  So there's
> definitely a "point in trying to fix" those failures, generally
> speaking.
>
> Jason
>
> On Thu, Jan 28, 2021 at 6:01 PM Noble Paul  wrote:
> >
> > I'm not sure why the tests fail. But, there is no point in trying to
> > fix them if that code is removed from master and we do not plan to
> > support them anyway
> >
> > On Fri, Jan 29, 2021 at 9:43 AM David Smiley  
> > wrote:
> > >
> > > Ah; I see they appear to be 8x only.  Any idea what the story is with 
> > > them?  Do you think it is just test flakiness or flakiness in Solr's 
> > > related functionality?
> > >
> > > ~ David
> > >
> > >
> > > On Thu, Jan 28, 2021 at 5:36 PM Noble Paul  wrote:
> > >>
> > >> Both of those are gone for good @David Smiley  I think we can safely
> > >> make them BadApples
> > >>
> > >> On Fri, Jan 29, 2021 at 9:07 AM David Smiley  wrote:
> > >> >
> > >> > I ran it twice on my old-ish MacBook, and it failed each time on Solr 
> > >> > tests that have a history of flakiness (as shown by Hossman's awesome 
> > >> > fucit.org site) -- AutoscalingHistoryHandlerTest & TestWithCollection. 
> > >> >  Neither seed repeated.  I'll pass on voting.
> > >> >
> > >> > ~ David Smiley
> > >> > Apache Lucene/Solr Search Developer
> > >> > http://www.linkedin.com/in/davidwsmiley
> > >> >
> > >> >
> > >> > On Thu, Jan 28, 2021 at 11:35 AM Cassandra Targett 
> > >> >  wrote:
> > >> >>
> > >> >> I’ve updated the Ref Guide to remove the DRAFT status on 8.8 pages, 
> > >> >> so that’s done. I’ll also take care of the next Ref Guide step to 
> > >> >> update the website to show 8.8 as the latest.
> > >> >> On Jan 28, 2021, 9:59 AM -0600, Tomás Fernández Löbbe 
> > >> >> , wrote:
> > >> >>
> > >> >> It’s 9 binding: Noble, Tim, me, Ignacio, Mike M, Namgyu, Atri, Anshum 
> > >> >> and Mike S.
> > >> >>
> > >> >> 1 non-binding: Haoyu
> > >> >>
> > >> >>
> > >> >> On Thu, Jan 28, 2021 at 5:34 AM Michael Sokolov  
> > >> >> wrote:
> > >> >>>
> > >> >>> SUCCESS! [0:58:25.213071]
> > >> >>>
> > >> >>> +1 better late than never?
> > >> >>>
> > >> >>> On Thu, Jan 28, 2021 at 8:04 AM Ishan Chattopadhyaya
> > >> >>>  wrote:
> > >> >>> >
> > >> >>> > Thanks Noble!
> > >> >>> >
> > >> >>> > On Thu, 28 Jan, 2021, 4:24 pm Noble Paul,  
> > >> >>> > wrote:
> > >> >>> >>
> > >> >>> >> [+1]  9  (4 binding)
> > >> >>> >>
> > >> >>> >>  [0]  0
> > >> >>> >>
> > >> >>> >> [-1]  0
> > >> >>> >>
> > >> >>> >>
> > >> >>> >> This vote has PASSED.
> > >> >>> >>
> > >> >>> >> I shall proceed with the rest of the release process
> > >> >>> >>
> > >> >>> >> On Thu, Jan 28, 2021 at 6:24 PM Anshum Gupta 
> > >> >>> >>  wrote:
> > >> >>> >> >
> > >> >>> >> > Thanks for handing the release, Noble!
> > >> >>> >> >
> > >> >>> >> > +1 (binding)
> > >> >>> >> >
> > >> >>> >> > SUCCESS! [0:56:12.016387]

Re: [VOTE] Release Lucene/Solr 8.8.0 RC2

[Noble Paul]

I'm not sure why the tests fail. But, there is no point in trying to
fix them if that code is removed from master and we do not plan to
support them anyway

On Fri, Jan 29, 2021 at 9:43 AM David Smiley  wrote:
>
> Ah; I see they appear to be 8x only.  Any idea what the story is with them?  
> Do you think it is just test flakiness or flakiness in Solr's related 
> functionality?
>
> ~ David
>
>
> On Thu, Jan 28, 2021 at 5:36 PM Noble Paul  wrote:
>>
>> Both of those are gone for good @David Smiley  I think we can safely
>> make them BadApples
>>
>> On Fri, Jan 29, 2021 at 9:07 AM David Smiley  wrote:
>> >
>> > I ran it twice on my old-ish MacBook, and it failed each time on Solr 
>> > tests that have a history of flakiness (as shown by Hossman's awesome 
>> > fucit.org site) -- AutoscalingHistoryHandlerTest & TestWithCollection.  
>> > Neither seed repeated.  I'll pass on voting.
>> >
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley
>> >
>> >
>> > On Thu, Jan 28, 2021 at 11:35 AM Cassandra Targett  
>> > wrote:
>> >>
>> >> I’ve updated the Ref Guide to remove the DRAFT status on 8.8 pages, so 
>> >> that’s done. I’ll also take care of the next Ref Guide step to update the 
>> >> website to show 8.8 as the latest.
>> >> On Jan 28, 2021, 9:59 AM -0600, Tomás Fernández Löbbe 
>> >> , wrote:
>> >>
>> >> It’s 9 binding: Noble, Tim, me, Ignacio, Mike M, Namgyu, Atri, Anshum and 
>> >> Mike S.
>> >>
>> >> 1 non-binding: Haoyu
>> >>
>> >>
>> >> On Thu, Jan 28, 2021 at 5:34 AM Michael Sokolov  
>> >> wrote:
>> >>>
>> >>> SUCCESS! [0:58:25.213071]
>> >>>
>> >>> +1 better late than never?
>> >>>
>> >>> On Thu, Jan 28, 2021 at 8:04 AM Ishan Chattopadhyaya
>> >>>  wrote:
>> >>> >
>> >>> > Thanks Noble!
>> >>> >
>> >>> > On Thu, 28 Jan, 2021, 4:24 pm Noble Paul,  wrote:
>> >>> >>
>> >>> >> [+1]  9  (4 binding)
>> >>> >>
>> >>> >>  [0]  0
>> >>> >>
>> >>> >> [-1]  0
>> >>> >>
>> >>> >>
>> >>> >> This vote has PASSED.
>> >>> >>
>> >>> >> I shall proceed with the rest of the release process
>> >>> >>
>> >>> >> On Thu, Jan 28, 2021 at 6:24 PM Anshum Gupta  
>> >>> >> wrote:
>> >>> >> >
>> >>> >> > Thanks for handing the release, Noble!
>> >>> >> >
>> >>> >> > +1 (binding)
>> >>> >> >
>> >>> >> > SUCCESS! [0:56:12.016387]
>> >>> >> >
>> >>> >> > Ran the smoke tester, a demo app, and checked the change log. All 
>> >>> >> > of that looks good.
>> >>> >> >
>> >>> >> > On Mon, Jan 25, 2021 at 2:22 AM Noble Paul  
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> Please vote for release candidate 2 for Lucene/Solr 8.8.0
>> >>> >> >>
>> >>> >> >> The artifacts can be downloaded from:
>> >>> >> >>
>> >>> >> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>> >>> >> >>
>> >>> >> >> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> >>> >> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> The vote will be open for at least 72 hours
>> >>> >> >>
>> >>> >> >> [ ] +1  approve
>> >>> >> >> [ ] +0  no opinion
>> >>> >> >> [ ] -1  disapprove (and reason why)
>> >>> >> >>
>> >>> >> >> Here is my +1
>> >>> >> >> --
>> >>> >> >> -
>> >>> >> >> Noble Paul
>> >>> >> >>
>> >>> >> >> -
>> >>> >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >>> >> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>> >> >>
>> >>> >> >
>> >>> >> >
>> >>> >> > --
>> >>> >> > Anshum Gupta
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> -
>> >>> >> Noble Paul
>> >>> >>
>> >>> >> -
>> >>> >> 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
>> >>>
>>
>>
>> --
>> -
>> Noble Paul



-- 
-
Noble Paul

-
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.8.0 RC2

[Noble Paul]

Both of those are gone for good @David Smiley  I think we can safely
make them BadApples

On Fri, Jan 29, 2021 at 9:07 AM David Smiley  wrote:
>
> I ran it twice on my old-ish MacBook, and it failed each time on Solr tests 
> that have a history of flakiness (as shown by Hossman's awesome fucit.org 
> site) -- AutoscalingHistoryHandlerTest & TestWithCollection.  Neither seed 
> repeated.  I'll pass on voting.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Jan 28, 2021 at 11:35 AM Cassandra Targett  
> wrote:
>>
>> I’ve updated the Ref Guide to remove the DRAFT status on 8.8 pages, so 
>> that’s done. I’ll also take care of the next Ref Guide step to update the 
>> website to show 8.8 as the latest.
>> On Jan 28, 2021, 9:59 AM -0600, Tomás Fernández Löbbe 
>> , wrote:
>>
>> It’s 9 binding: Noble, Tim, me, Ignacio, Mike M, Namgyu, Atri, Anshum and 
>> Mike S.
>>
>> 1 non-binding: Haoyu
>>
>>
>> On Thu, Jan 28, 2021 at 5:34 AM Michael Sokolov  wrote:
>>>
>>> SUCCESS! [0:58:25.213071]
>>>
>>> +1 better late than never?
>>>
>>> On Thu, Jan 28, 2021 at 8:04 AM Ishan Chattopadhyaya
>>>  wrote:
>>> >
>>> > Thanks Noble!
>>> >
>>> > On Thu, 28 Jan, 2021, 4:24 pm Noble Paul,  wrote:
>>> >>
>>> >> [+1]  9  (4 binding)
>>> >>
>>> >>  [0]  0
>>> >>
>>> >> [-1]  0
>>> >>
>>> >>
>>> >> This vote has PASSED.
>>> >>
>>> >> I shall proceed with the rest of the release process
>>> >>
>>> >> On Thu, Jan 28, 2021 at 6:24 PM Anshum Gupta  
>>> >> wrote:
>>> >> >
>>> >> > Thanks for handing the release, Noble!
>>> >> >
>>> >> > +1 (binding)
>>> >> >
>>> >> > SUCCESS! [0:56:12.016387]
>>> >> >
>>> >> > Ran the smoke tester, a demo app, and checked the change log. All of 
>>> >> > that looks good.
>>> >> >
>>> >> > On Mon, Jan 25, 2021 at 2:22 AM Noble Paul  
>>> >> > wrote:
>>> >> >>
>>> >> >> Please vote for release candidate 2 for Lucene/Solr 8.8.0
>>> >> >>
>>> >> >> The artifacts can be downloaded from:
>>> >> >>
>>> >> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>>> >> >>
>>> >> >> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>> >> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> The vote will be open for at least 72 hours
>>> >> >>
>>> >> >> [ ] +1  approve
>>> >> >> [ ] +0  no opinion
>>> >> >> [ ] -1  disapprove (and reason why)
>>> >> >>
>>> >> >> Here is my +1
>>> >> >> --
>>> >> >> -
>>> >> >> Noble Paul
>>> >> >>
>>> >> >> -
>>> >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> >> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >> >>
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Anshum Gupta
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> -
>>> >> Noble Paul
>>> >>
>>> >> -
>>> >> 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
>>>


-- 
-
Noble Paul

-
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.8.0 RC2

[Noble Paul]

Yeah , there were 5 binding votes

On Thu, Jan 28, 2021 at 11:19 PM Atri Sharma  wrote:
>
> Hi Noble,
>
> Is the binding vote count not incorrect?
>
> On Thu, 28 Jan 2021, 16:24 Noble Paul,  wrote:
>>
>> [+1]  9  (4 binding)
>>
>>  [0]  0
>>
>> [-1]  0
>>
>>
>> This vote has PASSED.
>>
>> I shall proceed with the rest of the release process
>>
>> On Thu, Jan 28, 2021 at 6:24 PM Anshum Gupta  wrote:
>> >
>> > Thanks for handing the release, Noble!
>> >
>> > +1 (binding)
>> >
>> > SUCCESS! [0:56:12.016387]
>> >
>> > Ran the smoke tester, a demo app, and checked the change log. All of that 
>> > looks good.
>> >
>> > On Mon, Jan 25, 2021 at 2:22 AM Noble Paul  wrote:
>> >>
>> >> Please vote for release candidate 2 for Lucene/Solr 8.8.0
>> >>
>> >> The artifacts can be downloaded from:
>> >>
>> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>> >>
>> >> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>> >>
>> >>
>> >>
>> >> The vote will be open for at least 72 hours
>> >>
>> >> [ ] +1  approve
>> >> [ ] +0  no opinion
>> >> [ ] -1  disapprove (and reason why)
>> >>
>> >> Here is my +1
>> >> --
>> >> -
>> >> Noble Paul
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> >
>> >
>> > --
>> > Anshum Gupta
>>
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>


-- 
-
Noble Paul

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

Re: [VOTE] Release Lucene/Solr 8.8.0 RC2

[Noble Paul]

[+1]  9  (4 binding)

 [0]  0

[-1]  0


This vote has PASSED.

I shall proceed with the rest of the release process

On Thu, Jan 28, 2021 at 6:24 PM Anshum Gupta  wrote:
>
> Thanks for handing the release, Noble!
>
> +1 (binding)
>
> SUCCESS! [0:56:12.016387]
>
> Ran the smoke tester, a demo app, and checked the change log. All of that 
> looks good.
>
> On Mon, Jan 25, 2021 at 2:22 AM Noble Paul  wrote:
>>
>> Please vote for release candidate 2 for Lucene/Solr 8.8.0
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>>
>>
>>
>> The vote will be open for at least 72 hours
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> Anshum Gupta



-- 
-
Noble Paul

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

[VOTE] Release Lucene/Solr 8.8.0 RC2

[Noble Paul]

Please vote for release candidate 2 for Lucene/Solr 8.8.0

The artifacts can be downloaded from:

https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/



The vote will be open for at least 72 hours

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Here is my +1
--
-
Noble Paul

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

Re: 8.8 Release

[Noble Paul]

I've pushed the changes.

@Ishan Chattopadhyaya  if you are unavailable just ping me. I'll put up RC2

On Sat, Jan 23, 2021 at 2:48 PM Noble Paul  wrote:
>
> please hold on there is a concurrency issue, I'm fixing it
>
> On Sat, Jan 23, 2021 at 12:54 PM Ishan Chattopadhyaya
>  wrote:
> >
> > My attempt to spin RC2 failed at one of the LTR tests, 
> > https://gist.github.com/chatman/567afa09cc3e233d151f8e8b0f6b63e7.
> > This is a rare failure, so wondering if there's a bug somewhere (either in 
> > LTR or schema loading). Ping Christine, Noble, FYI.
> >
> > I'm trying another run, I have only an hour before I'm gone for a while. If 
> > it fails again, I would request Noble to pick it up.
> >
> > On Fri, Jan 22, 2021 at 8:37 PM Christine Poerschke (BLOOMBERG/ LONDON) 
> >  wrote:
> >>
> >> No worries, thanks for the review input!
> >>
> >> The SOLR-15071 commits are now complete.
> >>
> >> From: dev@lucene.apache.org At: 01/22/21 13:33:19
> >> To: Christine Poerschke (BLOOMBERG/ LONDON ) , dev@lucene.apache.org
> >> Subject: Re: 8.8 Release
> >>
> >> Sorry, I should have explicitly approved that PR; you had addressed my 
> >> concerns and I forgot about it, thinking it was in 8.8.
> >> ~ David Smiley
> >> Apache Lucene/Solr Search Developer
> >> http://www.linkedin.com/in/davidwsmiley
> >>
> >>
> >> On Fri, Jan 22, 2021 at 4:29 AM Christine Poerschke (BLOOMBERG/ LONDON) 
> >>  wrote:
> >>>
> >>> Hello Ishan. Is there still time for me to merge and backport 
> >>> https://github.com/apache/lucene-solr/pull/2196 for the fix this London 
> >>> morning for inclusion in RC2? The PR is essentially reviewed but not yet 
> >>> approved and with other things also going on I'd held off on it then so 
> >>> far. What do you think? Thanks!
> >>>
> >>> From: dev@lucene.apache.org At: 01/12/21 02:38:20
> >>> To: dev@lucene.apache.org
> >>> Subject: Re: 8.8 Release
> >>>
> >>> Thanks Tim. I've now cut the branch for 8.8.
> >>> @David, let's get the fix in for the release.
> >>>
> >>>
> >>> On Tue, Jan 12, 2021 at 2:13 AM David Smiley  wrote:
> >>>>
> >>>> FYI https://issues.apache.org/jira/browse/SOLR-15071 for LTR a regression
> >>>> Christine hasn't posted the fix yet but I'd guess there's a user 
> >>>> work-around so the issue isn't pressing I suppose.
> >>>>
> >>>> ~ David Smiley
> >>>> Apache Lucene/Solr Search Developer
> >>>> http://www.linkedin.com/in/davidwsmiley
> >>>>
> >>>>
> >>>> On Mon, Jan 11, 2021 at 1:32 PM Timothy Potter  
> >>>> wrote:
> >>>>>
> >>>>> Fix is in branch_8x and master now, sorry for the delay ;-)
> >>>>>
> >>>>> Cheers,
> >>>>> Tim
> >>>>>
> >>>>> On Mon, Jan 11, 2021 at 10:50 AM Ishan Chattopadhyaya 
> >>>>>  wrote:
> >>>>>>
> >>>>>> Thanks Tim!
> >>>>>>
> >>>>>> On Mon, 11 Jan, 2021, 11:00 pm Timothy Potter,  
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> 15036 will be in later today, so you can plan to cut this evening US 
> >>>>>>> time or tomorrow.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Tim
> >>>>>>>
> >>>>>>> On Mon, Jan 11, 2021 at 9:54 AM Ishan Chattopadhyaya 
> >>>>>>>  wrote:
> >>>>>>>>
> >>>>>>>> I think all the issues mentioned above are in the branch, except 
> >>>>>>>> SOLR-15036. Tim, I'll cut a branch once that is in, latest by 
> >>>>>>>> Wednesday AM (USA time).
> >>>>>>>> Thanks,
> >>>>>>>> Ishan
> >>>>>>>>
> >>>>>>>> On Thu, Jan 7, 2021 at 5:07 AM Timothy Potter  
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> 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 
> >>>>>>>>&g

Re: 8.8 Release

[Noble Paul]

gt; 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 
>>>>>>>>>>  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 
>>>>>>>>>>>  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 
>>>>>>>>>>>>>>> >>  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
>>>>>>>>>>>>>>>
>>>
>>


-- 
-
Noble Paul

-
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.8.0 RC1

[Noble Paul]

+1
SUCCESS! [1:10:23.173123]
On Ubuntu 20.04.1

On Thu, Jan 21, 2021 at 12:30 AM jim ferenczi  wrote:
>
> +1
>
> SUCCESS! [1:06:13.147855]
>
> Le mer. 20 janv. 2021 à 08:39, Atri Sharma  a écrit :
>>
>> +1 (binding)
>>
>> SUCCESS! [1:04:15:20393]
>>
>> On Wed, Jan 20, 2021 at 1:03 PM Ignacio Vera  wrote:
>> >
>> > +1 (binding)
>> >
>> > SUCCESS! [1:05:30.358141]
>> >
>> >
>> > On Tue, Jan 19, 2021 at 8:25 PM Timothy Potter  
>> > wrote:
>> >>
>> >> +1 (binding)
>> >>
>> >> SUCCESS! [1:07:15.796578]
>> >>
>> >>
>> >> Also built a *local* Docker image from the RC and tested various features 
>> >> with the Solr operator on K8s, such as the updates to the Prom exporter & 
>> >> Grafana dashboard for query performance.
>> >>
>> >>
>> >> Looks good!
>> >>
>> >>
>> >> On Tue, Jan 19, 2021 at 12:06 PM Houston Putman  
>> >> wrote:
>> >>>
>> >>> +1
>> >>>
>> >>> SUCCESS! [1:01:28.552891]
>> >>>
>> >>> On Tue, Jan 19, 2021 at 1:53 PM Cassandra Targett 
>> >>>  wrote:
>> >>>>
>> >>>> I’ve put up the DRAFT version of the Ref Guide for 8.8: 
>> >>>> https://lucene.apache.org/solr/guide/8_8/.
>> >>>>
>> >>>> I also created the Jenkins job for building the 8.8 guide which pushes 
>> >>>> to the Nightlies server in case we have edits between now and release 
>> >>>> (https://nightlies.apache.org/Lucene/Solr-reference-guide-8.8/).
>> >>>>
>> >>>> Note branch_8_8 does not (yet) include the new Math Expressions guide 
>> >>>> being worked on in SOLR-13105. Still hoping that will make it, but 
>> >>>> thought I’d get this out sooner rather than later just in case.
>> >>>> On Jan 19, 2021, 10:51 AM -0600, Ishan Chattopadhyaya 
>> >>>> , wrote:
>> >>>>
>> >>>> Please vote for release candidate 1 for Lucene/Solr 8.8.0
>> >>>>
>> >>>> The artifacts can be downloaded from:
>> >>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC1-rev737cb9c49b08f6e3964c1e8a80132da3c764e027
>> >>>>
>> >>>> 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.8.0-RC1-rev737cb9c49b08f6e3964c1e8a80132da3c764e027
>> >>>>
>> >>>> The vote will be open for at least 72 hours i.e. until 2021-01-22 17:00 
>> >>>> UTC.
>> >>>>
>> >>>> [ ] +1  approve
>> >>>> [ ] +0  no opinion
>> >>>> [ ] -1  disapprove (and reason why)
>> >>>>
>> >>>> Here is my +1
>> >>>> 
>>
>> --
>> Regards,
>>
>> Atri
>> Apache Concerted
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>


-- 
-
Noble Paul

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

Re: 8.8 Release

[Noble Paul]

Family first.

We got this covered Ishan

On Fri, Jan 15, 2021 at 12:43 PM David Smiley  wrote:
>
> Wow. Good call on handing off the release duties so you can focus on family. 
> Take care!
>
> On Thu, Jan 14, 2021 at 3:46 PM Ishan Chattopadhyaya 
>  wrote:
>>
>> Hi Devs,
>>
>> Just admitted mom to a hospital, she has given us a sudden health scare. I 
>> doubt I'll be around for this release or for some time now.
>>
>> I've spoken to Noble and requested him to take over the release duties here.
>>
>> Thanks and regards,
>> Ishan
>>
>> On Thu, 14 Jan, 2021, 2:03 pm Noble Paul,  wrote:
>>>
>>> I've merged it .
>>> Thanks
>>>
>>> On Thu, Jan 14, 2021 at 5:12 PM Ishan Chattopadhyaya
>>>  wrote:
>>> >
>>> > Sure Noble, if you are confident it doesn't disrupt the stability of the 
>>> > release, please go ahead. In case there are any problems with 
>>> > stability/performance discovered (due to this issue) at the time of the 
>>> > release, I'll revert this. Thanks!
>>> >
>>> > On Thu, Jan 14, 2021 at 11:33 AM Noble Paul  wrote:
>>> >>
>>> >> @Ishan Chattopadhyaya
>>> >>
>>> >> I wish to port https://issues.apache.org/jira/browse/SOLR-14155 to
>>> >> 8.8, if it is OK
>>> >>
>>> >> On Wed, Jan 13, 2021 at 9:20 AM Ishan Chattopadhyaya
>>> >>  wrote:
>>> >> >
>>> >> > Wish you a very happy new year, Namgyu!
>>> >> > Please proceed, thanks!
>>> >> >
>>> >> > On Wed, 13 Jan, 2021, 1:01 am Namgyu Kim,  wrote:
>>> >> >>
>>> >> >> Hi Ishan,
>>> >> >> It's late, but happy new year!
>>> >> >>
>>> >> >> There is a blocker issue for 8.x (including 8.8)
>>> >> >> https://issues.apache.org/jira/browse/LUCENE-9661
>>> >> >>
>>> >> >> Would it be okay to cherry-pick the commit for LUCENE-9661 to the 8.8 
>>> >> >> branch after merging?
>>> >> >>
>>> >> >> On Wed, Jan 13, 2021 at 1:48 AM Ishan Chattopadhyaya 
>>> >> >>  wrote:
>>> >> >>>
>>> >> >>> Please go for it if you think it won't disrupt the stability and can 
>>> >> >>> be wrapped up in 2-3 days.
>>> >> >>>
>>> >> >>> On Tue, 12 Jan, 2021, 10:08 pm Walter Underwood, 
>>> >> >>>  wrote:
>>> >> >>>>
>>> >> >>>> I’d love for SOLR-15056 to be in, but it is just a patch now and 
>>> >> >>>> hasn’t had anything besides
>>> >> >>>> local testing, so that is a bit of a long shot.
>>> >> >>>>
>>> >> >>>> wunder
>>> >> >>>> Walter Underwood
>>> >> >>>> wun...@wunderwood.org
>>> >> >>>> http://observer.wunderwood.org/  (my blog)
>>> >> >>>>
>>> >> >>>> On Jan 11, 2021, at 9:29 AM, Timothy Potter  
>>> >> >>>> wrote:
>>> >> >>>>
>>> >> >>>> 15036 will be in later today, so you can plan to cut this evening 
>>> >> >>>> US time or tomorrow.
>>> >> >>>>
>>> >> >>>> Cheers,
>>> >> >>>> Tim
>>> >> >>>>
>>> >> >>>> On Mon, Jan 11, 2021 at 9:54 AM Ishan Chattopadhyaya 
>>> >> >>>>  wrote:
>>> >> >>>>>
>>> >> >>>>> I think all the issues mentioned above are in the branch, except 
>>> >> >>>>> SOLR-15036. Tim, I'll cut a branch once that is in, latest by 
>>> >> >>>>> Wednesday AM (USA time).
>>> >> >>>>> Thanks,
>>> >> >>>>> Ishan
>>> >> >>>>>
>>> >> >>>>> On Thu, Jan 7, 2021 at 5:07 AM Timothy Potter 
>>> >> >>>>>  wrote:
>>> >> >>>>>>
>>> >> >>>>>> Thanks for following up on this Ishan ... I intend to get 
>>> >> >>>>>> SOLR-15059 and -15

Re: 8.8 Release

[Noble Paul]

I've merged it .
Thanks

On Thu, Jan 14, 2021 at 5:12 PM Ishan Chattopadhyaya
 wrote:
>
> Sure Noble, if you are confident it doesn't disrupt the stability of the 
> release, please go ahead. In case there are any problems with 
> stability/performance discovered (due to this issue) at the time of the 
> release, I'll revert this. Thanks!
>
> On Thu, Jan 14, 2021 at 11:33 AM Noble Paul  wrote:
>>
>> @Ishan Chattopadhyaya
>>
>> I wish to port https://issues.apache.org/jira/browse/SOLR-14155 to
>> 8.8, if it is OK
>>
>> On Wed, Jan 13, 2021 at 9:20 AM Ishan Chattopadhyaya
>>  wrote:
>> >
>> > Wish you a very happy new year, Namgyu!
>> > Please proceed, thanks!
>> >
>> > On Wed, 13 Jan, 2021, 1:01 am Namgyu Kim,  wrote:
>> >>
>> >> Hi Ishan,
>> >> It's late, but happy new year!
>> >>
>> >> There is a blocker issue for 8.x (including 8.8)
>> >> https://issues.apache.org/jira/browse/LUCENE-9661
>> >>
>> >> Would it be okay to cherry-pick the commit for LUCENE-9661 to the 8.8 
>> >> branch after merging?
>> >>
>> >> On Wed, Jan 13, 2021 at 1:48 AM Ishan Chattopadhyaya 
>> >>  wrote:
>> >>>
>> >>> Please go for it if you think it won't disrupt the stability and can be 
>> >>> wrapped up in 2-3 days.
>> >>>
>> >>> On Tue, 12 Jan, 2021, 10:08 pm Walter Underwood,  
>> >>> wrote:
>> >>>>
>> >>>> I’d love for SOLR-15056 to be in, but it is just a patch now and hasn’t 
>> >>>> had anything besides
>> >>>> local testing, so that is a bit of a long shot.
>> >>>>
>> >>>> wunder
>> >>>> Walter Underwood
>> >>>> wun...@wunderwood.org
>> >>>> http://observer.wunderwood.org/  (my blog)
>> >>>>
>> >>>> On Jan 11, 2021, at 9:29 AM, Timothy Potter  
>> >>>> wrote:
>> >>>>
>> >>>> 15036 will be in later today, so you can plan to cut this evening US 
>> >>>> time or tomorrow.
>> >>>>
>> >>>> Cheers,
>> >>>> Tim
>> >>>>
>> >>>> On Mon, Jan 11, 2021 at 9:54 AM Ishan Chattopadhyaya 
>> >>>>  wrote:
>> >>>>>
>> >>>>> I think all the issues mentioned above are in the branch, except 
>> >>>>> SOLR-15036. Tim, I'll cut a branch once that is in, latest by 
>> >>>>> Wednesday AM (USA time).
>> >>>>> Thanks,
>> >>>>> Ishan
>> >>>>>
>> >>>>> On Thu, Jan 7, 2021 at 5:07 AM Timothy Potter  
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> 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 
>> >>>>>>>  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 rele

Re: 8.8 Release

[Noble Paul]

@Ishan Chattopadhyaya

I wish to port https://issues.apache.org/jira/browse/SOLR-14155 to
8.8, if it is OK

On Wed, Jan 13, 2021 at 9:20 AM Ishan Chattopadhyaya
 wrote:
>
> Wish you a very happy new year, Namgyu!
> Please proceed, thanks!
>
> On Wed, 13 Jan, 2021, 1:01 am Namgyu Kim,  wrote:
>>
>> Hi Ishan,
>> It's late, but happy new year!
>>
>> There is a blocker issue for 8.x (including 8.8)
>> https://issues.apache.org/jira/browse/LUCENE-9661
>>
>> Would it be okay to cherry-pick the commit for LUCENE-9661 to the 8.8 branch 
>> after merging?
>>
>> On Wed, Jan 13, 2021 at 1:48 AM Ishan Chattopadhyaya 
>>  wrote:
>>>
>>> Please go for it if you think it won't disrupt the stability and can be 
>>> wrapped up in 2-3 days.
>>>
>>> On Tue, 12 Jan, 2021, 10:08 pm Walter Underwood,  
>>> wrote:
>>>>
>>>> I’d love for SOLR-15056 to be in, but it is just a patch now and hasn’t 
>>>> had anything besides
>>>> local testing, so that is a bit of a long shot.
>>>>
>>>> wunder
>>>> Walter Underwood
>>>> wun...@wunderwood.org
>>>> http://observer.wunderwood.org/  (my blog)
>>>>
>>>> On Jan 11, 2021, at 9:29 AM, Timothy Potter  wrote:
>>>>
>>>> 15036 will be in later today, so you can plan to cut this evening US time 
>>>> or tomorrow.
>>>>
>>>> Cheers,
>>>> Tim
>>>>
>>>> On Mon, Jan 11, 2021 at 9:54 AM Ishan Chattopadhyaya 
>>>>  wrote:
>>>>>
>>>>> I think all the issues mentioned above are in the branch, except 
>>>>> SOLR-15036. Tim, I'll cut a branch once that is in, latest by Wednesday 
>>>>> AM (USA time).
>>>>> Thanks,
>>>>> Ishan
>>>>>
>>>>> On Thu, Jan 7, 2021 at 5:07 AM Timothy Potter  
>>>>> wrote:
>>>>>>
>>>>>> 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 
>>>>>>>  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 
>>>>>>>>  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:
>>>>>>>>>>>
>>>>>>>>&g

Re: Requesting a new GH repository for CrossDC modules

[Noble Paul]

Thanks Anshum. I believe this will help everyone who wish to play with
other innovative ideas

On Thu, Jan 14, 2021, 7:08 AM Anshum Gupta  wrote:

> Based on the discussion on the committer meeting, I'll put in a request to
> create a solr sandbox repo.
>
> Thank you everyone.
>
> On Tue, Jan 12, 2021 at 8:13 PM Noble Paul  wrote:
>
>> I'm +1 for a  top level sandbox repo. Anyone should be able create a
>> project in that.
>>
>> Once the project graduates out of the sandbox we should create a top level
>>
>> On Wed, Jan 13, 2021, 11:30 AM Anshum Gupta 
>> wrote:
>>
>>> Building this as a branch is an option, but building it outside in a
>>> personal repo is exactly what's not the Apache Way.
>>>
>>> Code should be designed and built in the Apache world, else it'd be a
>>> grant/donation and not really a PR. Also, you can't create a PR against a
>>> repo that doesn't exist upstream.
>>>
>>> Do you have an objection against a mono-repo i.e. solr-sandbox too? That
>>> would open the door for us to use this for similar purposes in the future,
>>> until the code is ready to be released.
>>>
>>> Also, just to reiterate, creating a repo doesn't cost anything and we
>>> aren't releasing anything. This is a placeholder to put the code in. If it
>>> works out well, we can release it or iterate on the code/implementation. In
>>> any case, it would have zero impact on the project itself.
>>>
>>> -Anshum
>>>
>>> On Tue, Jan 12, 2021 at 3:37 PM Noble Paul  wrote:
>>>
>>>> I feel this is placing the cart before the horse.
>>>>
>>>> We can always build this as a branch or a repo under your own account.
>>>> Once we reach a point where the project is reasonably mature, you can
>>>> create a repo and contribute it upstream.
>>>>
>>>>
>>>> On Wed, Jan 13, 2021 at 6:27 AM Anshum Gupta 
>>>> wrote:
>>>> >
>>>> > I understand what you are saying, which is also my reason to not have
>>>> a mono-repo. This way it's easier to manage and drop a repository when it's
>>>> not needed. It doesn't cause clutter and lives in isolation.
>>>> >
>>>> > I think we are on the same page in terms of the intention.
>>>> >
>>>> >
>>>> > On Tue, Jan 12, 2021 at 10:51 AM Ishan Chattopadhyaya <
>>>> ichattopadhy...@gmail.com> wrote:
>>>> >>
>>>> >> Look at the branches that are cluttering up our main repository,
>>>> many symbolic of unfinished work. If we start one repo each for everything
>>>> we hope to finish, we'll make Solr annoying in a new way.
>>>> >>
>>>> >> There is no reason multiple artifacts can't be released
>>>> independently from the same repo. Why are you opposed to that idea, Anshum?
>>>> >>
>>>> >> On Tue, 12 Jan, 2021, 11:53 pm Anshum Gupta, 
>>>> wrote:
>>>> >>>
>>>> >>> Thank you everyone!
>>>> >>>
>>>> >>> I'll move forward with the cross-dc repo creation then as mentioned
>>>> in the original email :)
>>>> >>>
>>>> >>> If we want to change the approach on the repo, we can always change
>>>> that before we release anything in the future.
>>>> >>>
>>>> >>> On Mon, Jan 11, 2021 at 10:32 AM Mike Drob 
>>>> wrote:
>>>> >>>>
>>>> >>>> I'm seeing valid reasons to prefer one solr sandbox repo, or
>>>> prefer multiple many repos for future plugins or integrations. In this
>>>> specific case, I think the relevant deciding points are 1) we don't have
>>>> multiple things yet, so deciding between a "mono-repo" and a "multi-repo"
>>>> is not very consequential 2) we can always rename things later 3) in the
>>>> absence of a strong reason otherwise i'll defer to the people doing the
>>>> work (in this case, Anshum). We considered sandbox and can always create
>>>> one in the future. If Anshum feels that solr-cross-dc is better for now
>>>> than I'm fine with that too.
>>>> >>>>
>>>> >>>> On Sun, Jan 10, 2021 at 5:07 PM David Smiley 
>>>> wrote:
>>>> >>>>>
>>>> >>>>> (palm-to-face) -- LOL okay sorry.  I'm getting my t

Re: Requesting a new GH repository for CrossDC modules

[Noble Paul]

I'm +1 for a  top level sandbox repo. Anyone should be able create a
project in that.

Once the project graduates out of the sandbox we should create a top level

On Wed, Jan 13, 2021, 11:30 AM Anshum Gupta  wrote:

> Building this as a branch is an option, but building it outside in a
> personal repo is exactly what's not the Apache Way.
>
> Code should be designed and built in the Apache world, else it'd be a
> grant/donation and not really a PR. Also, you can't create a PR against a
> repo that doesn't exist upstream.
>
> Do you have an objection against a mono-repo i.e. solr-sandbox too? That
> would open the door for us to use this for similar purposes in the future,
> until the code is ready to be released.
>
> Also, just to reiterate, creating a repo doesn't cost anything and we
> aren't releasing anything. This is a placeholder to put the code in. If it
> works out well, we can release it or iterate on the code/implementation. In
> any case, it would have zero impact on the project itself.
>
> -Anshum
>
> On Tue, Jan 12, 2021 at 3:37 PM Noble Paul  wrote:
>
>> I feel this is placing the cart before the horse.
>>
>> We can always build this as a branch or a repo under your own account.
>> Once we reach a point where the project is reasonably mature, you can
>> create a repo and contribute it upstream.
>>
>>
>> On Wed, Jan 13, 2021 at 6:27 AM Anshum Gupta 
>> wrote:
>> >
>> > I understand what you are saying, which is also my reason to not have a
>> mono-repo. This way it's easier to manage and drop a repository when it's
>> not needed. It doesn't cause clutter and lives in isolation.
>> >
>> > I think we are on the same page in terms of the intention.
>> >
>> >
>> > On Tue, Jan 12, 2021 at 10:51 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >>
>> >> Look at the branches that are cluttering up our main repository, many
>> symbolic of unfinished work. If we start one repo each for everything we
>> hope to finish, we'll make Solr annoying in a new way.
>> >>
>> >> There is no reason multiple artifacts can't be released independently
>> from the same repo. Why are you opposed to that idea, Anshum?
>> >>
>> >> On Tue, 12 Jan, 2021, 11:53 pm Anshum Gupta, 
>> wrote:
>> >>>
>> >>> Thank you everyone!
>> >>>
>> >>> I'll move forward with the cross-dc repo creation then as mentioned
>> in the original email :)
>> >>>
>> >>> If we want to change the approach on the repo, we can always change
>> that before we release anything in the future.
>> >>>
>> >>> On Mon, Jan 11, 2021 at 10:32 AM Mike Drob  wrote:
>> >>>>
>> >>>> I'm seeing valid reasons to prefer one solr sandbox repo, or prefer
>> multiple many repos for future plugins or integrations. In this specific
>> case, I think the relevant deciding points are 1) we don't have multiple
>> things yet, so deciding between a "mono-repo" and a "multi-repo" is not
>> very consequential 2) we can always rename things later 3) in the absence
>> of a strong reason otherwise i'll defer to the people doing the work (in
>> this case, Anshum). We considered sandbox and can always create one in the
>> future. If Anshum feels that solr-cross-dc is better for now than I'm fine
>> with that too.
>> >>>>
>> >>>> On Sun, Jan 10, 2021 at 5:07 PM David Smiley 
>> wrote:
>> >>>>>
>> >>>>> (palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.
>> >>>>>
>> >>>>> A repo which holds multiple independent modules that can work with
>> Solr need not release them all at once.
>> >>>>>
>> >>>>> ~ David Smiley
>> >>>>> Apache Lucene/Solr Search Developer
>> >>>>> http://www.linkedin.com/in/davidwsmiley
>> >>>>>
>> >>>>>
>> >>>>> On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta 
>> wrote:
>> >>>>>>
>> >>>>>> David, this is about the Cross DC work that was supposed to be
>> done :-)
>> >>>>>>
>> >>>>>> The independent release cadence is primarily the reason why a new
>> repo makes sense to me in this case.
>> >>>>>>
>> >>>>>> On Sat, Jan 9, 2021 at 1:24 PM David Smiley 
>> wrote:
>> >>&g

Re: Requesting a new GH repository for CrossDC modules

[Noble Paul]

t;>>>> lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox 
>>>>>>>> etc., and develop it there.
>>>>>>>> b) All development for this effort happens in an external repository 
>>>>>>>> (https://github.com/apple/solr-dc or 
>>>>>>>> https://github.com/anshumg/solr-dc) and we raise a PR against Apache 
>>>>>>>> owned repository (which can be created if needed once we are all 
>>>>>>>> onboard).
>>>>>>>>
>>>>>>>> What does everyone else think?
>>>>>>>>
>>>>>>>> On Fri, Jan 8, 2021 at 10:23 AM Mike Drob  wrote:
>>>>>>>>>
>>>>>>>>> An external repository probably ends up requiring a software grant? I 
>>>>>>>>> know there is a material difference between code originating 
>>>>>>>>> externally and code originating within the umbrella of the ASF in 
>>>>>>>>> terms of IP, copyright, or other legal status.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya 
>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>> If all we need now is a place to commit a PoC for now (and something 
>>>>>>>>>> like sandbox repo or contribs won't suffice), why can't we have a 
>>>>>>>>>> separate repository in GitHub outside Apache and merge into an 
>>>>>>>>>> Apache repository only once the code takes reasonable shape?
>>>>>>>>>>
>>>>>>>>>> On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta,  
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the feedback, Mike.
>>>>>>>>>>>
>>>>>>>>>>> I like the idea of the sandbox, but that might be restricting when 
>>>>>>>>>>> we want to work on more than one repos.
>>>>>>>>>>>
>>>>>>>>>>> I'm not sure if that would happen in the near future, but as we can 
>>>>>>>>>>> always discard the repo and it doesn't really come at a cost, I 
>>>>>>>>>>> don't see a problem with having a repo created for this specific 
>>>>>>>>>>> reason.
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jan 7, 2021 at 12:45 PM Mike Drob  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure where I sit on this, going to start typing things and 
>>>>>>>>>>>> then hopefully I'll reach a conclusion by the end.
>>>>>>>>>>>>
>>>>>>>>>>>> This definitely needs to be outside of the core solr repo so that 
>>>>>>>>>>>> it can be versioned and released independently. And I disagree 
>>>>>>>>>>>> with Ishan about the consequence of abandoning the repository - if 
>>>>>>>>>>>> we realize that it's a bad direction then we can pivot, but we 
>>>>>>>>>>>> shouldn't let a fear of the unknown stop us from doing it in the 
>>>>>>>>>>>> first place.
>>>>>>>>>>>>
>>>>>>>>>>>> However, if all we need right now is a place to commit code that 
>>>>>>>>>>>> is WIP, then what we really want is a sandbox to play with, and 
>>>>>>>>>>>> not necessarily a strongly directed repo. Lucene has a sandbox in 
>>>>>>>>>>>> the main code. We could similarly start this under Solr contrib 
>>>>>>>>>>>> and move it out before an actual release of 9x happens. Or maybe 
>>>>>>>>>>>> we start with a [lucene-]solr-sandbox repository that we can throw 
>>>>>>>>>>>> all sorts of stuff into and then when components are mature enough 
>>>>>>>>>>>> they get to graduate into their own repo?
>>>>>>>>>>>>
>>>>>>>>>>>> Mike
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta 
>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I understand your concern, but this is the placeholder for where 
>>>>>>>>>>>>> the code would be, not what the code would look like.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Considering we agreed to do this in a repository outside of the 
>>>>>>>>>>>>> core, I believe this is a good place to start. The idea that the 
>>>>>>>>>>>>> release cadence for the cross-dc effort should be different from 
>>>>>>>>>>>>> that of core is an argument in favor of this approach, but I'm 
>>>>>>>>>>>>> happy to talk more about it.
>>>>>>>>>>>>> I just thought that based on the original email, folks were 
>>>>>>>>>>>>> on-board with the idea of this being outside of core Solr 
>>>>>>>>>>>>> artifact/release.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya 
>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -1 on this. Without finalizing on the shape of how the solution 
>>>>>>>>>>>>>> will look like, I don't think we should start a repository: it 
>>>>>>>>>>>>>> would be bad if we have to abandon the repository of our 
>>>>>>>>>>>>>> approach changes (say we want to keep it tightly integrated 
>>>>>>>>>>>>>> inside Solr).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, 
>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi everyone,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Inline with my earlier email, I'll be requesting a new 
>>>>>>>>>>>>>>> repository to host the cross-dc work. Please let me know if you 
>>>>>>>>>>>>>>> have any questions or concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Repository name: solr-crossdc
>>>>>>>>>>>>>>> Generated name: lucene-solr-crossdc.git (that's auto-generated, 
>>>>>>>>>>>>>>> so can't remove the TLP prefix)
>>>>>>>>>>>>>>> Commit notification list: commits-cros...@lucene.apache.org (I 
>>>>>>>>>>>>>>> think it makes sense for these commit notifications to go to a 
>>>>>>>>>>>>>>> new list, but I'm open to reusing the old one)
>>>>>>>>>>>>>>> GitHub notification list: dev@lucene.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll be submitting a request for the same later in the day 
>>>>>>>>>>>>>>> today if there are no concerns.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Anshum Gupta
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Anshum Gupta
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Anshum Gupta
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Anshum Gupta
>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>
>
>
> --
> Anshum Gupta



-- 
-
Noble Paul

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

Re: 9.0 release

[Noble Paul]

+1

On Tue, Dec 29, 2020 at 8:43 AM Erick Erickson  wrote:
>
> It’ll really be nice to not have to switch between gradle and ant when
> verifying changes ;).
>
> Not to mention that we’ll be able to stop having to deal with Java 8
> .vs. Java 11.
>
> I don’t expect this to be a short release, so yeah, I think it’s time to
> start the process.
>
> Erick
>
> > On Dec 28, 2020, at 2:36 PM, Atri Sharma  wrote:
> >
> > +1
> >
> > I think the division steps are pretty clearly documented-- a matter of 
> > executing them now.
> >
> > On Tue, 29 Dec 2020, 01:03 Dawid Weiss,  wrote:
> > It would be great indeed if we could push to finalize dividing the
> > codebases (some things have been proven to be doable - snapshot
> > builds, splitting the code,
> > build, etc.) and then follow up with proper releases of both Lucene
> > and Solr (on their independent TLP).
> >
> >
> > Dawid
> >
> > On Mon, Dec 28, 2020 at 7:17 PM Michael Sokolov  wrote:
> > >
> > > Hi everyone, as we head into a new year full of optimism, is it time
> > > to start discussing the next major release? We released 8.0 on Jun 18,
> > > 2019, over 18 months ago. Since then we've switched to a gradle-based
> > > build. We have added vector-valued fields and an HNSW neighbor search
> > > algorithm for them.  At the same time Solr has been getting a major
> > > overhaul which should justify a release, I think? IIRC there was talk
> > > of making 9.0 be the first release of Solr as its own TLP. Is it time
> > > to start planning for that now?
> > >
> > > -Mike
> > >
> > > -
> > > 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
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: [DISCUSS] SIP-12: Incremental Backup and Restore

[Noble Paul]

>, and implement the new imporved version as a V2-api only, and then deprecate 
>the v1 API?


V2 only please

On Tue, Dec 22, 2020 at 1:34 AM Jason Gerlowski  wrote:
>
> Hey Jan, thanks for the review.
>
> I hadn't thought about the V2 API in connection to this work.  You're
> right though I think - the SIP proposes net-new APIs, so it should add
> V2 equivalents at the very least.  I'll draft tentative details for
> these APIs on the SIP and we can refine things from there.
>
> I'm more up in the air on your specific suggestion to restrict the SIP
> changes to these v2 APIs.  It is an elegant approach to the
> backcompat, and it provides a carrot for v2 adoption - both of which I
> like.  But it would let users create snapshot-based backups (and keep
> us maintaining that code) longer than there's any strict need to.  And
> users are left on the less-efficient format by default.  (By contrast,
> the current SIP has snapshot-backup creation being replaced by
> incremental-backup creation as soon as the latter is available.).  Did
> you have a particular lifespan in mind for snapshot-based creation if
> we go with this approach?
>
> Jason
>
> On Thu, Dec 17, 2020 at 3:54 PM Jan Høydahl  wrote:
> >
> > Much needed! Thanks for initiating this Jason!
> >
> > As we want to move away from v1 APIs where a HTTP GET is used for creation 
> > and deletion, would it be an idea to leave the old backup/resotre APIs 
> > as-is, and implement the new imporved version as a V2-api only, and then 
> > deprecate the v1 API? Then we don't need to worry about back-compat, and we 
> > get a head-start on converting the COLLECTION API to v2 style.
> >
> > Jan
> >
> > > 15. des. 2020 kl. 15:48 skrev Jason Gerlowski :
> > >
> > > Hey all,
> > >
> > > This morning I published SIP-12, which proposes an overhaul of Solr's
> > > backup and restore functionality.  While the "headline" improvement in
> > > this SIP is a change to do backups incrementally, it bundles in a
> > > number of other improvements as well, including the addition of
> > > corruption checks, APIs to list and delete backups, and stronger
> > > integration points with popular object storage APIs.
> > >
> > > The SIP can be found here:
> > > https://cwiki.apache.org/confluence/display/SOLR/SIP-12%3A+Incremental+Backup+and+Restore
> > >
> > > Please read the SIP description and come back here for discussion.  As
> > > the discussion progresses we will update the SIP page with any
> > > outcomes and eventually move things to a VOTE.
> > >
> > > Looking forward to hearing your feedback.
> > >
> > > Best,
> > >
> > > Jason
> > >
> > > -
> > > 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
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: 8.8 Release

[Noble Paul]

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 
>>  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: JIRAs with user facing changes

[Noble Paul]

I don't think we have such an option in JIRA. However, we can add a
similar item to the checklist in github

On Sat, Oct 17, 2020 at 6:43 PM Andrzej Białecki  wrote:
>
> +1, we should strive to be consistent in the user-facing APIs / configs / UX.
>
> I’m wondering if there’s any support in Jira for conditional fields, so that 
> when you create a Jira issue if you tick off an option “Affects the UX?” it 
> opens a mandatory text field to describe the changes.
>
>
> > On 16 Oct 2020, at 20:19, Noble Paul  wrote:
> >
> > Hi,
> > I'm proposing a process for every ticket which has a user facing
> > change. The changes could be
> >
> > * A new command/end point
> > * A new request parameter
> > * A configuration (solr.xml, clusterprops.json, or any other file in ZK)
> > * A new file (part of file) in ZK
> > * A new file in file system
> >
> > I may have missed some.
> >
> > Please ensure that the changes are described in the description of the
> > JIRA. This gives a heads up to other committers that a new user facing
> > change is being introduced.
> >
> > Solr's UX is inconsistent & hard and the reason is that we all make
> > user-facing changes without enough review. Of course we add ref guide
> > documentation. But, it is not done until it is too late. The intent to
> > make a change should be made clear well in advance so that we get
> > early feedback. Other committers often see the changes pretty late and
> > at this point it is too late to change because of backward
> > incompatibility.
> >
> >
> > --
> > -
> > Noble Paul
> >
> > -
> > 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
>


-- 
-
Noble Paul

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

JIRAs with user facing changes

[Noble Paul]

Hi,
I'm proposing a process for every ticket which has a user facing
change. The changes could be

* A new command/end point
* A new request parameter
* A configuration (solr.xml, clusterprops.json, or any other file in ZK)
* A new file (part of file) in ZK
* A new file in file system

I may have missed some.

Please ensure that the changes are described in the description of the
JIRA. This gives a heads up to other committers that a new user facing
change is being introduced.

Solr's UX is inconsistent & hard and the reason is that we all make
user-facing changes without enough review. Of course we add ref guide
documentation. But, it is not done until it is too late. The intent to
make a change should be made clear well in advance so that we get
early feedback. Other committers often see the changes pretty late and
at this point it is too late to change because of backward
incompatibility.


-- 
-----
Noble Paul

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

Re: Removal of Apache HttpComponents/HttpClient for 9.0?

[Noble Paul]

+1 @David Smiley

On Sun, Oct 11, 2020 at 4:07 AM Ishan Chattopadhyaya
 wrote:
>
> Maybe we need them for kerberos? I'm totally fine getting rid of kerberos 
> support from Solr core some day, but it might not be very easy to refactor it 
> into a package.
>
> On Sat, 10 Oct, 2020, 10:26 pm David Smiley,  wrote:
>>
>> I think that historically, we are good at adding code but not good at 
>> removing code.  We add new ways to do things but keep the old.  Removal is 
>> more work often forgotten but doing nothing implicitly adds technical debt 
>> henceforth.
>>
>> With that segue... given that our latest SolrClient implementations are 
>> based on Jetty HttpClient (to support Http2 but should support 1.1?), do we 
>> need the original Apache HttpComponents/HttpClient as well?  This is an 
>> honest question... maybe there are subtle reasons they are needed and I 
>> think it would be good as a project that we are clear on them.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley



-- 
-
Noble Paul

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

Re: restlet dependencies

[Noble Paul]

I think we should call that out in the changes.txt and make the changes
right away.

On Wed, Oct 7, 2020, 8:20 AM Timothy Potter  wrote:

> Just want to close the loop on this restlet issue. I've removed the
> restlet dependency in master (e879a52291ef7dcd0514e7419d811b6ff800bcce) but
> have not backported that to 8.x yet.
>
> I'm hesitant to backport because I had to change public function
> signatures on ManagedResource, e.g.
> https://github.com/apache/lucene-solr/commit/e879a52291ef7dcd0514e7419d811b6ff800bcce#diff-faaf5cd2bfe038f81ca4c0cb1986b42dR355
> ...
>
> So technically, this could break upgrades for environments with extensions
> to those classes; practically speaking, I think the risk of that is low,
> but not sure it is worth it? From what I understand, the restlet maven
> issue was mostly affecting master / gradle builds and the ant/ivy builds in
> 8.x weren't affected as much?
>
> It's an easy back-port from master to 8.x if that's what we want to do,
> but wanted to raise awareness that it will break public function signatures
> on classes that may have extensions in the wild ;-)
>
> ~ Tim
>
> On Thu, Oct 1, 2020 at 8:36 AM Timothy Potter 
> wrote:
>
>> Awesome guys, thanks for the pointers ... am cooking up a PR (for master)
>> for this today
>>
>> On Thu, Oct 1, 2020 at 2:22 AM Noble Paul  wrote:
>>
>>> The annotation (
>>> https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/EndPoint.java
>>> )
>>> supports wild cards and templated paths
>>>
>>> On Thu, Oct 1, 2020 at 5:28 PM Ishan Chattopadhyaya
>>>  wrote:
>>> >
>>> > > But when I suggested porting the code that uses restlet to JAX-RS /
>>> Jersey, Ishan said
>>> > > that wasn't necessary and is already supported with some Annotations
>>> ... I have no idea
>>> > > what that means and need more info about what is already in place.
>>> >
>>> > I was mainly referring to the @Endpoint annotations. It is available
>>> for V2 APIs today (and I think it should be fine to use for anything we
>>> build now onwards, including managed resources V2).
>>> > It is possible to make it work with V1, but that will require some
>>> work.
>>> >
>>> > On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>> >>
>>> >> @Tim
>>> >>
>>> >> Please check ClusterAPI or ZookeeperReadAPI etc.
>>> >> Recently used it in Yasa:
>>> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
>>> >>
>>> >> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul 
>>> wrote:
>>> >>>
>>> >>> @Tim Potter
>>> >>>
>>> >>> I tried several times to get rid of the restlet dependency & keep the
>>> >>> functionality as is. I failed miserably. I'm not saying this to
>>> >>> discourage anyone who wants to give a try. Just letting you know that
>>> >>> it is not as easy as it may sound
>>> >>>
>>> >>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman <
>>> houstonput...@gmail.com> wrote:
>>> >>> >
>>> >>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>>> >>> >
>>> >>> >  - Houston
>>> >>> >
>>> >>> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
>>> tomasflo...@gmail.com> wrote:
>>> >>> >>
>>> >>> >> > Let's support the single file upload feature
>>> >>> >> +1, but let this behave exactly as a zip file with a single file
>>> in it (regarding trusted/untrusted). We just need to change the configset
>>> handler to be able to handle non-zip files, and have a way to "locate" that
>>> file inside the configset (in case it needs to go somewhere other than the
>>> root).
>>> >>> >>
>>> >>> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh <
>>> ep...@opensourceconnections.com> wrote:
>>> >>> >>>
>>> >>> >>> I think that me in “violent agreement” with you.   Let’s
>>> understand the Annotations approach that we have, or pick something that is
>>> commonly used like JAX-RS / Jersey.
>>> >>> >>>
>>

Re: Solr Alpha (EA) release of Reference Branch

[Noble Paul]

> I think the danger is high to treat this branch as a black box (or an "all or 
> nothing").

True Ilan.  Ideally, I would like a few of us to study the code &
start pulling in changes we are confident of (even to 8x branch, why
not). We cannot burden a single developer to do everything.

This cannot be a task just for one or 2 devs. We all will have to work
together to decompose the changes and digest them into master. I can
do my bit.

But, I'm sure we may hit a point where certain changes cannot be
isolated and absorbed. We will have to collectively make a call, how
to absorb them

On Tue, Oct 6, 2020 at 9:00 PM Ishan Chattopadhyaya
 wrote:
>
>
> I'm willing to help and I believe others will too if the amount of work for 
> contributing is reasonable (i.e. not a three months effort).
>
> I looked into the possibility of doing so. To me, it seemed to be that it is 
> very hard to do so: possibly 1 year project for me. Problem is that it is 
> hard to pull out a particular class of improvements (say thread management 
> improvement) and have all tests pass with it (because tests have gotten 
> extensive improvements of their own) and also observe the effect of the 
> improvement. IIUC, every improvement to Solr seemed to require many 
> iterations to get the tests happy. I remember Mark telling me that it may not 
> even be possible for him to do something like that (i.e. bring all changes 
> into master as tiny pieces).
>
> What I volunteered to do, however, is to decompose roughly all the general 
> improvements into smaller, manageable commits. However, making sure all tests 
> pass at every commit point is beyond my capability.
>
> On Tue, 6 Oct, 2020, 3:10 pm Ilan Ginzburg,  wrote:
>>
>> Another option to integrate this work into the main code line would be to 
>> understand what changes have been made and where (Mark's descriptions in 
>> Slack go in the right way but are still too high level), and then port or 
>> even redo them in main, one by one.
>>
>> I think the danger is high to treat this branch as a black box (or an "all 
>> or nothing"). Using the merging itself to change our understanding and 
>> increase our knowledge of what was done can greatly reduce the risk.
>>
>> We do develop new features in Solr 9 without beta releasing them, so if we 
>> port Mark's improvements by small chunks (and maybe in the process decide 
>> that some should not be ported or not now) I don't see why this can't 
>> integrate to become like other improvements done to the code. If specific 
>> changes do require a beta release, do that release from master and pick the 
>> right moment.
>>
>> I'm willing to help and I believe others will too if the amount of work for 
>> contributing is reasonable (i.e. not a three months effort). This requires 
>> documenting the changes done in that branch, pointing to where these changes 
>> happened and then picking them up one by one and porting them more or less 
>> independently of each other. We might only port a subset of changes by the 
>> time 9.0 is released, that's fine we can continue in following releases.
>>
>> My 2 cents...
>> Ilan
>>
>> Le mar. 6 oct. 2020 à 09:56, Noble Paul  a écrit :
>>>
>>> Yes, A docker image will definitely help. I wasn't trying to downplay that
>>>
>>> On Tue, Oct 6, 2020 at 6:55 PM Ishan Chattopadhyaya
>>>  wrote:
>>> >
>>> >
>>> > > Docker is not a big requirement for large scale installations. Most of 
>>> > > them already have their own install scripts. Availability of docker is 
>>> > > not important for them. If a user is only encouraged to install Solr 
>>> > > because of a docker image , most likely they are not running a large 
>>> > > enough cluster
>>> >
>>> > I disagree, Noble. Having a docker image us going to be useful to some 
>>> > clients, with complex usecases. Great point, David!
>>> >
>>> > On Tue, 6 Oct, 2020, 1:09 pm Ishan Chattopadhyaya, 
>>> >  wrote:
>>> >>
>>> >> As I said, I'm *personally* not confident in putting such a big 
>>> >> changeset into master that wasn't vetted in a real user environment 
>>> >> widely. I have, in the past, done enough bad things to Solr (directly or 
>>> >> indirectly), and I don't want to repeat the same. Also, I'll be very 
>>> >> uncomfortable if someone else did so.
>>> >>
>>> >> Having said this, if someone else wants to port the changes over to 
>>> >> master *with

Re: Solr Alpha (EA) release of Reference Branch

[Noble Paul]

Yes, A docker image will definitely help. I wasn't trying to downplay that

On Tue, Oct 6, 2020 at 6:55 PM Ishan Chattopadhyaya
 wrote:
>
>
> > Docker is not a big requirement for large scale installations. Most of them 
> > already have their own install scripts. Availability of docker is not 
> > important for them. If a user is only encouraged to install Solr because of 
> > a docker image , most likely they are not running a large enough cluster
>
> I disagree, Noble. Having a docker image us going to be useful to some 
> clients, with complex usecases. Great point, David!
>
> On Tue, 6 Oct, 2020, 1:09 pm Ishan Chattopadhyaya, 
>  wrote:
>>
>> As I said, I'm *personally* not confident in putting such a big changeset 
>> into master that wasn't vetted in a real user environment widely. I have, in 
>> the past, done enough bad things to Solr (directly or indirectly), and I 
>> don't want to repeat the same. Also, I'll be very uncomfortable if someone 
>> else did so.
>>
>> Having said this, if someone else wants to port the changes over to master 
>> *without first getting enough real world testing*, feel free to do so, and I 
>> can focus my efforts elsewhere.
>>
>> On Tue, 6 Oct, 2020, 9:22 am Tomás Fernández Löbbe,  
>> wrote:
>>>
>>> I was thinking (and I haven’t flushed it out completely but will throw the 
>>> idea) that an alternative approach with this timeline could be to cut 9x 
>>> branch around November/December? And then you could merge into master, it 
>>> would have the latest  changes from master plus the ref branch changes. 
>>> From there any nightly build could be use to help test/debug.
>>>
>>> That said I don’t know for sure what are the changes in the branch that do 
>>> not belong in 9. The problem with them being 10x only is that backports 
>>> would potentially be more difficult for all the life of 9.
>>>
>>> On Mon, Oct 5, 2020 at 4:54 PM Noble Paul  wrote:
>>>>
>>>> >I don't think it can be said what committers do and don't do with regards 
>>>> >to running Solr.  All of us would answer this differently and at 
>>>> >different points in time.
>>>>
>>>> " I have run it in one large cluster, so it is certified to be bug 
>>>> free/stable" I don't think it's a reasonable approach. We need as much 
>>>> feedback from our users because each of them stress Solr in a different 
>>>> way. This is not to suggest that committers are not doing testing or their 
>>>> tests are not valid. When I talk to the committers out here they say they 
>>>> do not see any performance stability issues at all. But, my client reports 
>>>> issues on a day to day basis.
>>>>
>>>>
>>>>
>>>> > Definitely publish a Docker image BTW -- it's the best way to try out 
>>>> > any software.
>>>>
>>>> Docker is not a big requirement for large scale installations. Most of 
>>>> them already have their own install scripts. Availability of docker is not 
>>>> important for them. If a user is only encouraged to install Solr because 
>>>> of a docker image , most likely they are not running a large enough cluster
>>>>
>>>>
>>>>
>>>> On Tue, Oct 6, 2020, 6:30 AM David Smiley  wrote:
>>>>>
>>>>> Thanks so much for your responses Ishan... I'm getting much more 
>>>>> information in this thread than my attempts to get questions answered on 
>>>>> the JIRA issue months ago.  And especially,  thank you for volunteering 
>>>>> for the difficult porting efforts!
>>>>>
>>>>> Tomas said:
>>>>>>
>>>>>>  I do agree with the previous comments that calling it "Solr 10" (even 
>>>>>> with the "-alpha") would confuse users, maybe use "reference"? or maybe 
>>>>>> something in reference to SOLR-14788?
>>>>>
>>>>>
>>>>> I have the opposite opinion.  This word "reference" is baffling to me 
>>>>> despite whatever Mark's explanation is.  I like the justification Ishan 
>>>>> gave for 10-alpha and I don't think I could re-phrase his justification 
>>>>> any better.  *If* the release was _not_ official (thus wouldn't show up 
>>>>> in the usual places anyone would look for a release), I think it would 
>>>>> alleviate that confusion concern even 

Re: Solr Alpha (EA) release of Reference Branch

[Noble Paul]

@Tomas Fernandez Lobbe
This is a very risky proposition. Let's say we cut 9x and now there is
 a new master taken from the reference branch. That master is now
going to be 10.0.

* We never get it to the hands of the users anytime soon. We will
never be able to reconcile these 2 branches
* The master & 9x branches will diverge so much that we cannot make
any meaningful commits to any of these branches

Reference branch will have all the features of Solr 9.0 because it is
forked from master (some latest changes are yet to be merged). So,
reference branch is 100% compatible with master. A user should be able
to do a drop in replacement between 9.0 & reference branch. It is also
possible to have  a cluster with nodes running 9x and reference
together( A rolling restart should be possible).
Let's take stock of what we have today.

Choice 1:
* Mark has made some significant changes to improve performance stability
* Mark has promised to make all tests pass over the next 2-3 weeks
* Ishan has promised to do the work to make a release possible
* Ishan has promised to port changes to master as soon as we get
enough user feedback. He has also expressed his reservations on doing
this before it is tested in the wild
* I promise to do code review & cleanup as much as possible. But I'm
hesitant to give a stamp of approval to make it THE official release

Choice: 2
* Tomas promise to port changes from the branch to master
* Tomas make a release

Choice 3:
* Status quo
* We throw away all the good work that is done & demotivate the developers
* Deprive users of all the promised goodness

I'm not sure what else is a choice and who is volunteering to work on
that. We need people who are willing to offer to get their hands
dirty. Personally, I'm totally against choice #3 and I'm willing to
collaborate with anyone who is has a plan to make all the goodness in
the branch available to our users

On Tue, Oct 6, 2020 at 6:39 PM Ishan Chattopadhyaya
 wrote:
>
> As I said, I'm *personally* not confident in putting such a big changeset 
> into master that wasn't vetted in a real user environment widely. I have, in 
> the past, done enough bad things to Solr (directly or indirectly), and I 
> don't want to repeat the same. Also, I'll be very uncomfortable if someone 
> else did so.
>
> Having said this, if someone else wants to port the changes over to master 
> *without first getting enough real world testing*, feel free to do so, and I 
> can focus my efforts elsewhere.
>
> On Tue, 6 Oct, 2020, 9:22 am Tomás Fernández Löbbe,  
> wrote:
>>
>> I was thinking (and I haven’t flushed it out completely but will throw the 
>> idea) that an alternative approach with this timeline could be to cut 9x 
>> branch around November/December? And then you could merge into master, it 
>> would have the latest  changes from master plus the ref branch changes. From 
>> there any nightly build could be use to help test/debug.
>>
>> That said I don’t know for sure what are the changes in the branch that do 
>> not belong in 9. The problem with them being 10x only is that backports 
>> would potentially be more difficult for all the life of 9.
>>
>> On Mon, Oct 5, 2020 at 4:54 PM Noble Paul  wrote:
>>>
>>> >I don't think it can be said what committers do and don't do with regards 
>>> >to running Solr.  All of us would answer this differently and at different 
>>> >points in time.
>>>
>>> " I have run it in one large cluster, so it is certified to be bug 
>>> free/stable" I don't think it's a reasonable approach. We need as much 
>>> feedback from our users because each of them stress Solr in a different 
>>> way. This is not to suggest that committers are not doing testing or their 
>>> tests are not valid. When I talk to the committers out here they say they 
>>> do not see any performance stability issues at all. But, my client reports 
>>> issues on a day to day basis.
>>>
>>>
>>>
>>> > Definitely publish a Docker image BTW -- it's the best way to try out any 
>>> > software.
>>>
>>> Docker is not a big requirement for large scale installations. Most of them 
>>> already have their own install scripts. Availability of docker is not 
>>> important for them. If a user is only encouraged to install Solr because of 
>>> a docker image , most likely they are not running a large enough cluster
>>>
>>>
>>>
>>> On Tue, Oct 6, 2020, 6:30 AM David Smiley  wrote:
>>>>
>>>> Thanks so much for your responses Ishan... I'm getting much more 
>>>> information in this thread than my attempts to get questions answered on 
>>>> the JI

Re: Solr Alpha (EA) release of Reference Branch

[Noble Paul]

>I don't think it can be said what committers do and don't do with regards
to running Solr.  All of us would answer this differently and at different
points in time.

" I have run it in one large cluster, so it is certified to be bug
free/stable" I don't think it's a reasonable approach. We need as much
feedback from our users because each of them stress Solr in a
different way. This is not to suggest that committers are not doing testing
or their tests are not valid. When I talk to the committers out here they
say they do not see any performance stability issues at all. But, my client
reports issues on a day to day basis.



> Definitely publish a Docker image BTW -- it's the best way to try out any
software.

Docker is not a big requirement for large scale installations. Most of them
already have their own install scripts. Availability of docker is not
important for them. If a user is only encouraged to install Solr because of
a docker image , most likely they are not running a large enough cluster



On Tue, Oct 6, 2020, 6:30 AM David Smiley  wrote:

> Thanks so much for your responses Ishan... I'm getting much more
> information in this thread than my attempts to get questions answered on
> the JIRA issue months ago.  And especially,  thank you for volunteering for
> the difficult porting efforts!
>
> Tomas said:
>
>>  I do agree with the previous comments that calling it "Solr 10" (even
>> with the "-alpha") would confuse users, maybe use "reference"? or maybe
>> something in reference to SOLR-14788?
>>
>
> I have the opposite opinion.  This word "reference" is baffling to me
> despite whatever Mark's explanation is.  I like the justification Ishan
> gave for 10-alpha and I don't think I could re-phrase his justification any
> better.  *If* the release was _not_ official (thus wouldn't show up in the
> usual places anyone would look for a release), I think it would alleviate
> that confusion concern even more, although I think "alpha" ought to be
> enough of a signal not to use it without digging deeper on what's going on.
>
> Alex then Ishan said:
>
>> > Maybe we could release it to
>> > committers community first and dogfood it "internally"?
>>
>> Alex: It is meaningless. Committers don't run large scale installations.
>> We barely even have time to take care of running unit tests before
>> destabilizing our builds. We are not the right audience. However, we all
>> can anyway check out the branch and start playing with it, even without a
>> release. There are orgs that don't want to install any code that wasn't
>> officially released; this release is geared towards them (to help us test
>> this at their scale).
>>
>
> I don't think it can be said what committers do and don't do with regards
> to running Solr.  All of us would answer this differently and at different
> points in time.  From time to time, though not at present, I've been well
> positioned to try out a new version of Solr in a stage/test environment to
> see how it goes.  (Putting on my Salesforce metaphorical hat...) Even
> though I'm not able to deploy it in a realistic way today, I'm able to run
> a battery of tests to see if one of the features we depend on have changed
> or is broken.  That's useful feedback to an alpha release!  And even though
> I'm saying I'm not well positioned to try out some new Solr release in a
> production-ish setting now, it's something I could make a good case for
> internally since upgrades take a lot of effort where I work.  It's in our
> interest for SolrCloud to be very stable (of course).
>
> Regardless, I think what you're driving at Ishan is that you want an
> "official" release -- one that goes through the whole ceremony.  You
> believe that people would be more likely to use it.  I think all we need to
> do is announce (similar to a real release) that there is some unofficial
> alpha distribution and that we want to solicit your feedback -- basically,
> help us find bugs.  Definitely publish a Docker image BTW -- it's the best
> way to try out any software.  I'm -0 on doing an official release for alpha
> software because it's unnecessary to achieve the goals and somewhat
> confusing.  I think the Solr 4 alpha/beta situation was different -- it was
> not some fork a committer was maintaining; it was the master branch of its
> time, and it was destined to be the very next release, not some possible
> future release.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>

Re: [VOTE] Release Lucene/Solr 8.6.3 RC1

[Noble Paul]

+1 (binding)
SUCCESS! [1:03:35.993520]
Ubuntu 20.04.1 LTS

On Mon, Oct 5, 2020 at 12:05 PM Namgyu Kim  wrote:
>
> +1 (binding)
>
> SUCCESS! [1:22:31.165879]
>
> On Sun, Oct 4, 2020 at 10:53 AM Jason Gerlowski  
> wrote:
>>
>> Please vote for release candidate 1 for Lucene/Solr 8.6.3
>>
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.3-RC1-reve001c2221812a0ba9e9378855040ce72f93eced4
>>
>>
>> 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.3-RC1-reve001c2221812a0ba9e9378855040ce72f93eced4
>>
>>
>> The vote will be open for at least 72 hours i.e. until 2020-10-07 02:00 UTC.
>>
>>
>> [ ] +1  approve
>>
>> [ ] +0  no opinion
>>
>> [ ] -1  disapprove (and reason why)
>>
>>
>> Here is my +1



-- 
-
Noble Paul

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

Re: Solr Alpha (EA) release of Reference Branch

[Noble Paul]

@Tomas Fernandez Lobbe


The naming is up for debate and it doesn't matter at this point in
time. I believe it has to be an official release to have enough
credibility. People trust the Apache brand and the community. This
will ensure that we get enough people to test this out. The very
objective of this release is to get help from our users to uncover any
bugs. Most big shops will not deploy unofficial releases in their
prod/staging environments. We wish to tick all the boxes for our users

On Mon, Oct 5, 2020 at 9:14 AM Uwe Schindler  wrote:
>
> Hi,
>
>
>
> In addition the gradle build scripts in the reference_impl branch seems very 
> outdated and does not support Policeman-Jenkins Multi-JVM testing. Although 
> it will print that it ran with later Java version, in fact it runs with JDK 
> 11 only, as RUNTIME_JAVA_HOME is ignored.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Uwe Schindler 
> Sent: Monday, October 5, 2020 12:01 AM
> To: 'Ishan Chattopadhyaya' 
> Cc: 'Lucene Dev' 
> Subject: RE: Solr Alpha (EA) release of Reference Branch
>
>
>
> Hi,
>
> I enabled the „gradlew check” runs on ASF Jenkins and Policeman Jenkins 
> (Linux, Windows, MacOS).
>
>
>
> I used branch (“reference_impl”). Is this correct, because it’s about a month 
> old?
>
> There’s also a much newer “reference_impl_dev” branch. Which one is correct?
>
>
>
> I will go sleeping now, sorry for failure mails during the night. Builds seem 
> to fail, but it’s too late to do anything against it.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Ishan Chattopadhyaya 
> Sent: Sunday, October 4, 2020 6:32 AM
> To: Uwe Schindler 
> Cc: Lucene Dev 
> Subject: Re: Solr Alpha (EA) release of Reference Branch
>
>
>
> Yes Uwe, it is ready for Jenkins testing. The Solr tests should run very fast 
> now.
>
>
>
> As for naming, our package manager in Solr will break if we don't specify a 
> major and a minor version. There's a concept of version constraints for 
> packages that need to compare against Solr version. I think release process 
> will also be much simpler if we have a major and minor version. We have done 
> a similar release in the past, 4.0.0-beta iirc.
>
>
>
> Why I favour 10.0-alpha or something like that is because users would clearly 
> know it is something that isn't coming right now (and hence very early 
> access), and it is logically a major version change (that comes after 8x). 
> With calling it 10x instead of 9x, we have the scope of abandoning the effort 
> as a whole if the early access releases have some serious problem or we 
> decide to take some other release strategy later.
>
>
>
> If the 10.0-alpha succeeds, we can always fold the changes back into a 9.1 or 
> go from 9.0 straight to 10.0, depending on what we decide later. 
> Alternatively, if the release looks good and 9.0 hasn't released yet, we can 
> fold those changes back to master, and either (a) release everything normally 
> as 9.0, or (b) call master as 10x and release from there (going from 8.8 to 
> 10.0 directly, skipping 9x altogether).
>
>
>
> Tldr, we shall have complete flexibility to go in any direction we want to.
>
>
>
> WDYT?
>
>
>
> On Sun, 4 Oct, 2020, 2:31 am Uwe Schindler,  wrote:
>
> Is the branch ready for Jenkins testing?
>
> If yes and "gradlew check" works, I really would like to set it up.
>
> Uwe
>
> Am October 3, 2020 7:42:22 PM UTC schrieb Ishan Chattopadhyaya 
> :
>
> Hi Devs,
>
>
>
> As you might be aware, the reference_impl branch has a lot of improvements 
> that we want to see in Solr master. However, it is currently a large 
> deviation from master and hence the stability and reliability (though 
> improved in certain aspects) remains to be tested in real production 
> environments before we gain confidence in bringing those changes to master.
>
>
>
> I propose that we do a one off preview release from that branch, say Solr 10 
> alpha (early access) or any other name that someone suggests, so that users 
> could try it out and report regressions or improvements etc.
>
>
>
> I volunteer to be the RM and planning to start the process around 1 
> December-15 December timeframe. Until then, we can tighten the loose ends on 
> the branch and plan for such a release.
>
>
>
> Is there any thoughts, concerns, questions?
>
>
>
> Regards,
>
> Ishan
>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de



-- 
-
Noble Paul

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

Re: Solr Alpha (EA) release of Reference Branch

[Noble Paul]

+1 Ishan

It's important that the branch gets some real world testing and
feedback. At this point we cannot be 100% sure about the stability of
that branch to port all the changes to master.

Users don't care what is Solr 9/Solr 10  or even Mark's Solr or even a
"Crazy Solr". As long as all the tests pass and they can do an upgrade
of their existing cluster to that release,that IS Solr. I think we do
not need to worry too much about it now. If/when we reach a point
where we have a new stable release of Solr that is 100% compatible
with our other branch, we can resume this discussion.

As Ilan said, we may get real feedback from our users deploying it on
production scale but non critical deployments. Our JUnit tests are not
good enough to uncover stability issues.

Let's focus on making all the tests pass and get this to the hands of our users.

On Sun, Oct 4, 2020 at 8:01 AM Uwe Schindler  wrote:
>
> Is the branch ready for Jenkins testing?
>
> If yes and "gradlew check" works, I really would like to set it up.
>
> Uwe
>
> Am October 3, 2020 7:42:22 PM UTC schrieb Ishan Chattopadhyaya 
> :
>>
>> Hi Devs,
>>
>> As you might be aware, the reference_impl branch has a lot of improvements 
>> that we want to see in Solr master. However, it is currently a large 
>> deviation from master and hence the stability and reliability (though 
>> improved in certain aspects) remains to be tested in real production 
>> environments before we gain confidence in bringing those changes to master.
>>
>> I propose that we do a one off preview release from that branch, say Solr 10 
>> alpha (early access) or any other name that someone suggests, so that users 
>> could try it out and report regressions or improvements etc.
>>
>> I volunteer to be the RM and planning to start the process around 1 
>> December-15 December timeframe. Until then, we can tighten the loose ends on 
>> the branch and plan for such a release.
>>
>> Is there any thoughts, concerns, questions?
>>
>> Regards,
>> Ishan
>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de



-- 
-
Noble Paul

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

Re: Backward compatability handling across major versions

[Noble Paul]

Yes, we break backward compatibility all the time. Solr is a web
service. Most users are only concerned about

* REST end points
* configurations in ZK
* index format

Java API changes are not that critical.  But, we still need to call them out.

The case in point was a configuration file stored in ZK. With that
change, it is IMPOSSIBLE to do a rolling upgrade. The only choice is
to

* Bring down the entire cluster
* Run the scripts to do an upgrade
* Pray everything comes back up

We should minimize any change that will prevent people from doing
rolling upgrades. If possible, our changes should be friendly to a
rolling upgrade.

All such changes MUST HAVE an associated ticket just to discuss the
backward compatibility break. We should weigh in the impact of such
changes on our users.



On Thu, Oct 1, 2020 at 10:18 PM David Smiley  wrote:
>
> Agreed that back-compat matters should not "sneak" into an issue that is not 
> about that.  There are of course gray areas -- much of Solr core Java APIs 
> are public yet we don't need to treat everything with such burdensome care.  
> It takes experience and some subjectivity to know.  The PR you point to is 
> very clear to me, as it's a web service API endpoint.
>
> We *can* break back-compat on a major release :-).  But such discussion 
> deserves its own issue about breaking that compatibility.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Oct 1, 2020 at 4:25 AM Ishan Chattopadhyaya 
>  wrote:
>>
>> Hi Devs,
>> As per earlier discussions, we want to do a better job of handling major 
>> version upgrades, possibly support rolling upgrades wherever possible. This 
>> implies that we don't break backward compatibility without a strong reason 
>> and adequate discussion around it.
>>
>> Recently, there was a PR that attempted to sneak in a backward incompatible 
>> change to an endpoint for plugins (package management). This change was 
>> totally unrelated to the JIRA/PR and there was absolutely no discussion or 
>> even an attempt to address the upgrade strategy with that change. The 
>> attitude was a careless one, on the lines of we can break backward 
>> compatibility in a major release. 
>> https://github.com/apache/lucene-solr/pull/1758#discussion_r494134314
>>
>> Do we have any consensus on whether we need a separate JIRA or broader 
>> discussion on any backward compatibility breaks? Or shall we let these 
>> changes be sneaked in, unless someone notices very carefully a few lines of 
>> changes in a 25 class PR?
>>
>> Looking for some suggestions here.
>> Thanks and regards,
>> Ishan



-- 
-
Noble Paul

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

Re: Backward compatability handling across major versions

[Noble Paul]

In fact I was shocked at the cavalier attitude with which backward
compatibility is broken. If we are going to make a backward
incompatible change

There should be a JIRA with the proper discussions

* What is the change?
* Why is the change important?
* What is the strategy for someone who does a rolling upgrade?
* Is it possible to avoid it?
* Can the change be done in a backward compatible way so that the
users are not inconvenienced

On Thu, Oct 1, 2020 at 6:25 PM Ishan Chattopadhyaya
 wrote:
>
> Hi Devs,
> As per earlier discussions, we want to do a better job of handling major 
> version upgrades, possibly support rolling upgrades wherever possible. This 
> implies that we don't break backward compatibility without a strong reason 
> and adequate discussion around it.
>
> Recently, there was a PR that attempted to sneak in a backward incompatible 
> change to an endpoint for plugins (package management). This change was 
> totally unrelated to the JIRA/PR and there was absolutely no discussion or 
> even an attempt to address the upgrade strategy with that change. The 
> attitude was a careless one, on the lines of we can break backward 
> compatibility in a major release. 
> https://github.com/apache/lucene-solr/pull/1758#discussion_r494134314
>
> Do we have any consensus on whether we need a separate JIRA or broader 
> discussion on any backward compatibility breaks? Or shall we let these 
> changes be sneaked in, unless someone notices very carefully a few lines of 
> changes in a 25 class PR?
>
> Looking for some suggestions here.
> Thanks and regards,
> Ishan



-- 
-
Noble Paul

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

Re: restlet dependencies

[Noble Paul]

The annotation 
(https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/api/EndPoint.java)
supports wild cards and templated paths

On Thu, Oct 1, 2020 at 5:28 PM Ishan Chattopadhyaya
 wrote:
>
> > But when I suggested porting the code that uses restlet to JAX-RS / Jersey, 
> > Ishan said
> > that wasn't necessary and is already supported with some Annotations ... I 
> > have no idea
> > what that means and need more info about what is already in place.
>
> I was mainly referring to the @Endpoint annotations. It is available for V2 
> APIs today (and I think it should be fine to use for anything we build now 
> onwards, including managed resources V2).
> It is possible to make it work with V1, but that will require some work.
>
> On Thu, Oct 1, 2020 at 12:50 PM Ishan Chattopadhyaya 
>  wrote:
>>
>> @Tim
>>
>> Please check ClusterAPI or ZookeeperReadAPI etc.
>> Recently used it in Yasa: 
>> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
>>
>> On Thu, Oct 1, 2020 at 10:46 AM Noble Paul  wrote:
>>>
>>> @Tim Potter
>>>
>>> I tried several times to get rid of the restlet dependency & keep the
>>> functionality as is. I failed miserably. I'm not saying this to
>>> discourage anyone who wants to give a try. Just letting you know that
>>> it is not as easy as it may sound
>>>
>>> On Thu, Oct 1, 2020 at 2:42 AM Houston Putman  
>>> wrote:
>>> >
>>> > +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>>> >
>>> >  - Houston
>>> >
>>> > On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe 
>>> >  wrote:
>>> >>
>>> >> > Let's support the single file upload feature
>>> >> +1, but let this behave exactly as a zip file with a single file in it 
>>> >> (regarding trusted/untrusted). We just need to change the configset 
>>> >> handler to be able to handle non-zip files, and have a way to "locate" 
>>> >> that file inside the configset (in case it needs to go somewhere other 
>>> >> than the root).
>>> >>
>>> >> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh 
>>> >>  wrote:
>>> >>>
>>> >>> I think that me in “violent agreement” with you.   Let’s understand the 
>>> >>> Annotations approach that we have, or pick something that is commonly 
>>> >>> used like JAX-RS / Jersey.
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sep 30, 2020, at 11:41 AM, Timothy Potter  
>>> >>> wrote:
>>> >>>
>>> >>> I'm sorry, I don't understand what you mean by "make it a single 
>>> >>> pattern (the annotations?)" Eric?
>>> >>>
>>> >>> To me, the pattern is well established in the Java world: JAX-RS (with 
>>> >>> Jersey as the underlying impl. which has nice integration with Jetty). 
>>> >>> But when I suggested porting the code that uses restlet to JAX-RS / 
>>> >>> Jersey, Ishan said that wasn't necessary and is already supported with 
>>> >>> some Annotations ... I have no idea what that means and need more info 
>>> >>> about what is already in place. Short of that, replacing restlet with 
>>> >>> JAX-RS / Jersey looks like a trivial amount of work to me (and I'm 
>>> >>> happy to take it on).
>>> >>>
>>> >>> Tim
>>> >>>
>>> >>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh 
>>> >>>  wrote:
>>> >>>>
>>> >>>> The use case of “I want to update something via a API” is I think 
>>> >>>> pretty common, and it would be nice to make it a single pattern (the 
>>> >>>> annotations?) with lots of examples/developer docs for the next person.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter  
>>> >>>> wrote:
>>> >>>>
>>> >>>> I started looking into removing Managed Resources in master and wanted 
>>> >>>> to mention that the LTR contrib also relies on this framework 
>>> >>>> (ManagedModelStore and ManagedFeatureStore, see: 
>>> >

Re: restlet dependencies

[Noble Paul]

@Tim Potter

I tried several times to get rid of the restlet dependency & keep the
functionality as is. I failed miserably. I'm not saying this to
discourage anyone who wants to give a try. Just letting you know that
it is not as easy as it may sound

On Thu, Oct 1, 2020 at 2:42 AM Houston Putman  wrote:
>
> +1 to Tomas' proposal. Created SOLR-14907 to track the effort.
>
>  - Houston
>
> On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe 
>  wrote:
>>
>> > Let's support the single file upload feature
>> +1, but let this behave exactly as a zip file with a single file in it 
>> (regarding trusted/untrusted). We just need to change the configset handler 
>> to be able to handle non-zip files, and have a way to "locate" that file 
>> inside the configset (in case it needs to go somewhere other than the root).
>>
>> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh  
>> wrote:
>>>
>>> I think that me in “violent agreement” with you.   Let’s understand the 
>>> Annotations approach that we have, or pick something that is commonly used 
>>> like JAX-RS / Jersey.
>>>
>>>
>>>
>>> On Sep 30, 2020, at 11:41 AM, Timothy Potter  wrote:
>>>
>>> I'm sorry, I don't understand what you mean by "make it a single pattern 
>>> (the annotations?)" Eric?
>>>
>>> To me, the pattern is well established in the Java world: JAX-RS (with 
>>> Jersey as the underlying impl. which has nice integration with Jetty). But 
>>> when I suggested porting the code that uses restlet to JAX-RS / Jersey, 
>>> Ishan said that wasn't necessary and is already supported with some 
>>> Annotations ... I have no idea what that means and need more info about 
>>> what is already in place. Short of that, replacing restlet with JAX-RS / 
>>> Jersey looks like a trivial amount of work to me (and I'm happy to take it 
>>> on).
>>>
>>> Tim
>>>
>>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh  
>>> wrote:
>>>>
>>>> The use case of “I want to update something via a API” is I think pretty 
>>>> common, and it would be nice to make it a single pattern (the 
>>>> annotations?) with lots of examples/developer docs for the next person.
>>>>
>>>>
>>>>
>>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter  wrote:
>>>>
>>>> I started looking into removing Managed Resources in master and wanted to 
>>>> mention that the LTR contrib also relies on this framework 
>>>> (ManagedModelStore and ManagedFeatureStore, see: 
>>>> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
>>>>  I only mention this b/c it's been said several times in this thread that 
>>>> nobody uses this feature and it's only for editing config/schema like 
>>>> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so 
>>>> bullish on removing the ability to manage dynamic resources using a REST 
>>>> like API. I agree that changing resources like the synonym set could be 
>>>> replaced with configSet updates but I don't see how to replace the RESTful 
>>>> model / feature store API w/o something like Managed Resources?
>>>>
>>>> From where I sit, I think we should just remove the use of restlet in the 
>>>> implementation but keep the API for Solr 9 (master).
>>>>
>>>> @Ishan ~ you mentioned there is a way to get REST API like behavior w/o 
>>>> using JAX-RS / Jersey ... something about annotations? Can you point me to 
>>>> some example code of how that is done please?
>>>>
>>>> Cheers,
>>>> Tim
>>>>
>>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley  wrote:
>>>>>
>>>>> These resources are fundamentally a part of the configSet and can (in 
>>>>> general) affect query results and thus flushing caches (via a reload) is 
>>>>> appropriate.
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Wed, Sep 30, 2020 at 9:06 AM Noble Paul  wrote:
>>>>>>
>>>>>> Well, I believe we should have a mechanism to upload a single file to
>>>>>> a configset.
>>>>>>
>>>>>> >  A single file configset upload would require the user to reloa

Re: restlet dependencies

[Noble Paul]

Well, I believe we should have a mechanism to upload a single file to
a configset.

>  A single file configset upload would require the user to reload the 
> collection, so it isn't better than managed resources.

This is not true

Only config/schema file changes result in core reload.

On Wed, Sep 30, 2020 at 10:23 PM David Smiley  wrote:
>
> Definitely don't remove in 8.x!
>
> >  A single file configset upload would require the user to reload the 
> > collection, so it isn't better than managed resources.
>
> Do you view that as a substantial point in favor of managed-resources?  I 
> view that as a trivial matter, and one I prefer to automagic and potentially 
> premature reload if there are additional edits to be done (e.g. 
> query-elevation or other word lists).
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya 
>  wrote:
>>
>> > * Nobody knows how it works. It's unsupported
>> It is supported and documented: 
>> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>>
>> > * RESTlet dependency
>> > * Cannot be secured using standard permissions
>> > * It's extremely complex for the functionality it offers.
>>
>> I agree. Whatever alternative we build should address these, before we 
>> consider removing managed resources.
>>
>> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya 
>>  wrote:
>>>
>>> The managed resources is the only reasonable way to upload synonyms on the 
>>> fly for users today. A single file configset upload would require the user 
>>> to reload the collection, so it isn't better than managed resources. I 
>>> would not recommend we remove the functionality without first building a 
>>> suitable alternative. I agree that the feature isn't built using proper 
>>> framework or proper APIs, but it is a feature that works well.
>>>
>>> Usually, I support throwing features out even without existence of an 
>>> alternative, but I do that for non essential features. In my mind, ability 
>>> to manage synonyms elegantly is an essential feature for a search engine.
>>>
>>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler,  wrote:
>>>>
>>>> Please don't do this.
>>>>
>>>> In short: remove restlet stuff from master. Pull requests on master are 
>>>> executed with Gradle on GitHub hardware.
>>>>
>>>> Ivy stuff in 8.x is built in more or less persistent servers and there is 
>>>> no issue.
>>>>
>>>> What's the problem?
>>>>
>>>> Uwe
>>>>
>>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya 
>>>> :
>>>>>
>>>>> Can we discuss this with ASF and get an exception for this?
>>>>>
>>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss,  wrote:
>>>>>>
>>>>>> We can't have or redistribute binaries in ASL sources - that's my 
>>>>>> understanding.
>>>>>>
>>>>>> Dawid
>>>>>>
>>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>>>>  wrote:
>>>>>> >
>>>>>> > Can we pull in the jar inside our codebase?
>>>>>> >
>>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss,  
>>>>>> > wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >> We can upgrade if it doesn't break anything... which I can't 
>>>>>> >> guarantee. ;)
>>>>>> >>
>>>>>> >> Dawid
>>>>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>>>
>>>>
>>>> --
>>>> Uwe Schindler
>>>> Achterdiek 19, 28357 Bremen
>>>> https://www.thetaphi.de



-- 
-
Noble Paul

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

Re: restlet dependencies

[Noble Paul]

>It is supported and documented: 
>https://lucene.apache.org/solr/guide/8_6/managed-resources.html

I was referring to how the code works. Not how the feature works

On Wed, Sep 30, 2020 at 7:46 PM Ishan Chattopadhyaya
 wrote:
>
> > * Nobody knows how it works. It's unsupported
> It is supported and documented: 
> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
>
> > * RESTlet dependency
> > * Cannot be secured using standard permissions
> > * It's extremely complex for the functionality it offers.
>
> I agree. Whatever alternative we build should address these, before we 
> consider removing managed resources.
>
> On Wed, Sep 30, 2020 at 2:52 PM Ishan Chattopadhyaya 
>  wrote:
>>
>> The managed resources is the only reasonable way to upload synonyms on the 
>> fly for users today. A single file configset upload would require the user 
>> to reload the collection, so it isn't better than managed resources. I would 
>> not recommend we remove the functionality without first building a suitable 
>> alternative. I agree that the feature isn't built using proper framework or 
>> proper APIs, but it is a feature that works well.
>>
>> Usually, I support throwing features out even without existence of an 
>> alternative, but I do that for non essential features. In my mind, ability 
>> to manage synonyms elegantly is an essential feature for a search engine.
>>
>> On Wed, 30 Sep, 2020, 2:44 pm Uwe Schindler,  wrote:
>>>
>>> Please don't do this.
>>>
>>> In short: remove restlet stuff from master. Pull requests on master are 
>>> executed with Gradle on GitHub hardware.
>>>
>>> Ivy stuff in 8.x is built in more or less persistent servers and there is 
>>> no issue.
>>>
>>> What's the problem?
>>>
>>> Uwe
>>>
>>> Am September 30, 2020 8:59:06 AM UTC schrieb Ishan Chattopadhyaya 
>>> :
>>>>
>>>> Can we discuss this with ASF and get an exception for this?
>>>>
>>>> On Wed, 30 Sep, 2020, 11:57 am Dawid Weiss,  wrote:
>>>>>
>>>>> We can't have or redistribute binaries in ASL sources - that's my 
>>>>> understanding.
>>>>>
>>>>> Dawid
>>>>>
>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>>>  wrote:
>>>>> >
>>>>> > Can we pull in the jar inside our codebase?
>>>>> >
>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss,  
>>>>> > wrote:
>>>>> >>
>>>>> >>
>>>>> >> We can upgrade if it doesn't break anything... which I can't 
>>>>> >> guarantee. ;)
>>>>> >>
>>>>> >> Dawid
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>>
>>>
>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de



-- 
-
Noble Paul

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

Re: restlet dependencies

[Noble Paul]

@Tomas Fernandez Lobbe
@Ishan Chattopadhyaya
Let's support the single file upload feature. Let's automatically make
that configset "untrusted" if any file is uploaded over REST. Those
"untrusted" features are not really important for normal users

On Wed, Sep 30, 2020 at 3:19 PM Noble Paul  wrote:
>
> I think we should just get rid of that feature in the next release. if
> somebody is dependent on that let them stick to 8.6x or 8.7. We should
> not bend over backwards to support some esoteric feature nobody uses
>
> Managed Resources has the following problems
>
> * Nobody knows how it works. It's unsupported
> * RESTlet dependency
> * Cannot be secured using standard permissions
> * It's extremely complex for the functionality it offers.
>
> On Wed, Sep 30, 2020 at 6:02 AM Ishan Chattopadhyaya
>  wrote:
> >
> > Can we pull in the jar inside our codebase?
> >
> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss,  wrote:
> >>
> >>
> >> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
> >>
> >> Dawid
>
>
>
> --
> -
> Noble Paul



-- 
-
Noble Paul

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

Re: restlet dependencies

[Noble Paul]

I think we should just get rid of that feature in the next release. if
somebody is dependent on that let them stick to 8.6x or 8.7. We should
not bend over backwards to support some esoteric feature nobody uses

Managed Resources has the following problems

* Nobody knows how it works. It's unsupported
* RESTlet dependency
* Cannot be secured using standard permissions
* It's extremely complex for the functionality it offers.

On Wed, Sep 30, 2020 at 6:02 AM Ishan Chattopadhyaya
 wrote:
>
> Can we pull in the jar inside our codebase?
>
> On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss,  wrote:
>>
>>
>> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
>>
>> Dawid



-- 
-----
Noble Paul

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

Re: Our test failure rate is unacceptable.

[Noble Paul]

I tried in 8x of course. The ant command is gone from master anyway

On Mon, Sep 21, 2020 at 1:32 AM Erick Erickson  wrote:
>
> Can’t seem to get that to fail on master. Note the reproducible bit was 8x.
>
> > On Sep 19, 2020, at 5:13 PM, Erick Erickson  wrote:
> >
> > ant test  -Dtestcase=TestPackages -Dtests.seed=C29471044D369FD3 
> > -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=et-EE 
> > -Dtests.timezone=Europe/Mariehamn -Dtests.asserts=true 
> > -Dtests.file.encoding=UTF-8
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: restlet dependencies

[Noble Paul]

We should deprecate that feature and remove restlet dependency altogether

On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein  wrote:
>
> Restlet again!!!
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh  
> wrote:
>>
>> Do we have a community blessed alternative to restlet already?
>>
>> On Sep 20, 2020, at 9:40 AM, Noble Paul  wrote:
>>
>> Haha.
>>
>> In fact schema APIs don't use restlet. Only the managed resources use it
>>
>> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya 
>>  wrote:
>>>
>>> If I were talend, I'd immediately start publishing to maven central. If I 
>>> were the developer who built the schema APIs, I would never have used 
>>> restlet to begin with.
>>>
>>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler,  wrote:
>>>>
>>>> I was thinking the same. Because GitHub does not cache the downloaded 
>>>> artifacts like our jenkins servers.
>>>>
>>>> It seems to run it in a new VM or container every time, so it downloads 
>>>> all artifacts. If I were Talend, I'd also block this.
>>>>
>>>> Uwe
>>>>
>>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss 
>>>> :
>>>>>
>>>>> I don't think it's http/https - I believe restlet repository simply
>>>>> bans github servers because of excessive traffic? These URLs work for
>>>>> me locally...
>>>>>
>>>>> Dawid
>>>>>
>>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>>>> LONDON)  wrote:
>>>>>>
>>>>>>
>>>>>>  This sounds vaguely familiar. "http works, https does not work" and 
>>>>>> https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>>>>>>
>>>>>>  From: dev@lucene.apache.org At: 09/18/20 10:01:29
>>>>>>  To: dev@lucene.apache.org
>>>>>>  Subject: Re: restlet dependencies
>>>>>>
>>>>>>  I don't think it is, sadly.
>>>>>>  https://repo1.maven.org/maven2/org/restlet
>>>>>>
>>>>>>  The link you provided (mvnrepository) aggregates from several maven
>>>>>>  repositories.
>>>>>>
>>>>>>
>>>>>>  D.
>>>>>>
>>>>>>  On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>>>>>>   wrote:
>>>>>>>
>>>>>>>
>>>>>>>  Sorry, afk, but I heard (*hearsay*) that restlet is also on maven 
>>>>>>> central
>>>>>>
>>>>>> these days. Can we confirm and switch to that? Sorry, if that's not the 
>>>>>> case.
>>>>>>>
>>>>>>>
>>>>>>>  On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss,  
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>  Just FYI: can't get PR builds on github to work recently because of 
>>>>>>>> this:
>>>>>>>>
>>>>>>>>> Could not resolve all files for configuration
>>>>>>
>>>>>> ':solr:core:compileClasspath'.
>>>>>>>>
>>>>>>>>  350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>>>>>>>  (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>>>>>>>  351 > Could not get resource
>>>>>>>>
>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>>
>>>>>>>>  352 > Could not GET
>>>>>>>>
>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>>>>>> tlet.ext.servlet-2.4.3.jar'.
>>>>>>>>
>>>>>>>>  353 > Connection reset
>>>>>>>>  354 > Could not download org.restlet-2.4.3.jar
>>>>>>>>  (org.restlet.jee:org.restlet:2.4.3)
>>>>>>>>  355 > Could not get resource
>>>>>>>>
>>>>>> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>>>>>> ar'.
>>>>>>>>
>>>>>>>>  356 > Could not GET
>>>>>>>>
>>>>>> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>>>>>> 2.4.3.jar'.
>>>>>>>>
>>>>>>>>  357 > Connection reset
>>>>>>>>
>>>>>>>>  D.
>>>>>>>> 
>>>>>>>>  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
>>>>>>
>>>>>>
>>>>> 
>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>>
>>>>
>>>> --
>>>> Uwe Schindler
>>>> Achterdiek 19, 28357 Bremen
>>>> https://www.thetaphi.de
>>
>>
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
>> http://www.opensourceconnections.com | My Free/Busy
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> This e-mail and all contents, including attachments, is considered to be 
>> Company Confidential unless explicitly stated otherwise, regardless of 
>> whether attachments are marked as such.
>>


-- 
-
Noble Paul

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

Re: restlet dependencies

[Noble Paul]

Haha.

In fact schema APIs don't use restlet. Only the managed resources use it

On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> If I were talend, I'd immediately start publishing to maven central. If I
> were the developer who built the schema APIs, I would never have used
> restlet to begin with.
>
> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler,  wrote:
>
>> I was thinking the same. Because GitHub does not cache the downloaded
>> artifacts like our jenkins servers.
>>
>> It seems to run it in a new VM or container every time, so it downloads
>> all artifacts. If I were Talend, I'd also block this.
>>
>> Uwe
>>
>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>> dawid.we...@gmail.com>:
>>>
>>> I don't think it's http/https - I believe restlet repository simply
>>> bans github servers because of excessive traffic? These URLs work for
>>> me locally...
>>>
>>> Dawid
>>>
>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>>> LONDON)  wrote:
>>>

  This sounds vaguely familiar. "http works, https does not work" and 
 https://issues.apache.org/jira/browse/SOLR-13756 possibly related?

  From: dev@lucene.apache.org At: 09/18/20 10:01:29
  To: dev@lucene.apache.org
  Subject: Re: restlet dependencies

  I don't think it is, sadly.
  https://repo1.maven.org/maven2/org/restlet

  The link you provided (mvnrepository) aggregates from several maven
  repositories.


  D.

  On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
   wrote:

>
>  Sorry, afk, but I heard (*hearsay*) that restlet is also on maven central
>
 these days. Can we confirm and switch to that? Sorry, if that's not the 
 case.

>
>  On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss,  wrote:
>
>>
>>  Just FYI: can't get PR builds on github to work recently because of 
>> this:
>>
>> Could not resolve all files for configuration
>>>
>> ':solr:core:compileClasspath'.

>  350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>>  (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>>  351 > Could not get resource
>>
>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
 tlet.ext.servlet-2.4.3.jar'.

>  352 > Could not GET
>>
>> 'https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
 tlet.ext.servlet-2.4.3.jar'.

>  353 > Connection reset
>>  354 > Could not download org.restlet-2.4.3.jar
>>  (org.restlet.jee:org.restlet:2.4.3)
>>  355 > Could not get resource
>>
>> 'https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
 ar'.

>  356 > Could not GET
>>
>> 'https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
 2.4.3.jar'.

>  357 > Connection reset
>>
>>  D.
>> --
>>  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


 --
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>>
>

Re: Our test failure rate is unacceptable.

[Noble Paul]

It passes for me all the time Erick

Can you please test with the branch
https://github.com/apache/lucene-solr/tree/jira/solr14879


On Sun, Sep 20, 2020 at 7:14 AM Erick Erickson  wrote:
>
> This seems to be a reproducing seed, at least 2/2
>
> ant test  -Dtestcase=TestPackages -Dtests.seed=C29471044D369FD3 
> -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=et-EE 
> -Dtests.timezone=Europe/Mariehamn -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>
> > On Sep 19, 2020, at 6:40 AM, Eric Pugh  
> > wrote:
> >
> > I’ll try and help with testing this feature more, as I have a specific 
> > package that needs this feature.
> >
> > We are somewhat stuck in a weird time, as we’re doing some great stuff, 
> > like the packages, to make core Solr foot print smaller, which means we 
> > need to add more complexity to core Solr, yet at the same time, we don’t 
> > have the (hopefully!) cleaner structure that is being worked on in the 
> > reference_impl_dev to properly support the complexity.
> >
> > Don’t get discouraged!
> >
> >> On Sep 18, 2020, at 11:21 PM, Noble Paul  wrote:
> >>
> >> I shall revert the changes and work on a solution
> >>
> >> On Sat, Sep 19, 2020, 6:54 AM Jason Gerlowski  
> >> wrote:
> >> > I don't think it is along the Apache way to revert somebody's commit 
> >> > without an explicit permission to do so
> >> Interesting, I made the Devil's Advocate argument above with the
> >> Apache Way specifically in mind.
> >>
> >> "Community over Code" comes up most often in terms of navigating
> >> interpersonal conflict and fostering contributors; that's valid and
> >> important.  But broken builds cause concrete "Community harm" as well.
> >> 100%-fails slow down every developer working on Solr for whatever
> >> length of time the project is in that state.  Established committers,
> >> first-PR contributors, Github forks, everyone.  Leaving 100%-fails out
> >> there while waiting for a committer to respond or fix an issue
> >> prolongs that period: slowing down development and turning off new
> >> potential contributors all the while.  So I think there's a concrete
> >> Apache Way argument for reverting early.
> >>
> >> Obviously the revert has to be done diplomatically or it risks
> >> alienating committers and undermining the other Apache Way benefits.
> >> But that's a question of execution not of approach.  There are
> >> tactful, inoffensive ways to roll back a change without implying
> >> negligence, impugning skill-sets, etc.   It's also not a concern
> >> that's specific to reverts - any JIRA comment or dev-list discussion
> >> pointing out issues runs into that.
> >>
> >> All that said, this is a Devil's Advocate argument I'm making here.  I
> >> have no plans to go around reverting other's commits; I was just
> >> curious where others were on this in case it came up again later.
> >>
> >> Best,
> >>
> >> Jason
> >>
> >> On Fri, Sep 18, 2020 at 3:59 PM Tomás Fernández Löbbe
> >>  wrote:
> >> >
> >> > I thought we were talking about reverting your own commits, not someone 
> >> > else’s...
> >> >
> >> > On Fri, Sep 18, 2020 at 12:31 PM Dawid Weiss  
> >> > wrote:
> >> >>
> >> >> I don't think it is along the Apache way to revert somebody's commit
> >> >>
> >> >> without an explicit permission to do so... Not that I would personally
> >> >>
> >> >> mind if somebody did it for me.
> >> >>
> >> >>
> >> >>
> >> >> On Fri, Sep 18, 2020 at 9:06 PM Tomás Fernández Löbbe
> >> >>
> >> >>  wrote:
> >> >>
> >> >> >
> >> >>
> >> >> > Sometimes Jenkins may take hours to take your commit, may fail in the 
> >> >> > middle of your night, may not fail consistently, etc. That's why I 
> >> >> > don't think giving specific timeframes makes sense, but yes, as soon 
> >> >> > as you notice it's failing, it's either fix immediately or revert IMO.
> >> >>
> >> >> >
> >> >>
> >> >> > On Fri, Sep 18, 2020 at 12:03 PM Jason Gerlowski 
> >> >> >  wrote:
> >> >>
> >> >> >>
> >> >>
> >> >> >> > If it’s

Re: [jira] [Commented] (SOLR-14151) Make schema components load from packages

[Noble Paul]

I beated this test for 100 repetitions . No failures. it's frustrating

On Sun, Sep 20, 2020 at 12:33 AM Erick Erickson  wrote:
>
> Yeah, I can't seem to get it to fail on demand either. I can look this 
> evening at some of the Jenkins failures to see if there's a pattern or 
> machine or whatever...
>
> On Sat, Sep 19, 2020, 09:31 Noble Paul  wrote:
>>
>> I'm beasting changes so many times and I can't see the failures happening
>>
>> I'm wondering if we should just disable the
>> TestPackages@testSchemaPlugins() or revert the changes wholesale
>>
>> On Sat, Sep 19, 2020 at 10:44 PM Erick Erickson  
>> wrote:
>> >
>> > I have to take it back a little. Hoss’ rollups show these tests failing 
>> > 100% of the time, but they pass on my machine locally at least some of the 
>> > time…. IDK quite why there’s a difference.
>> >
>> > Noble:
>> >
>> > Let me know if I can help, I can at least beast any fix.
>> >
>> > Erick
>> >
>> > > On Sep 18, 2020, at 2:13 PM, Ishan Chattopadhyaya (Jira) 
>> > >  wrote:
>> > >
>> > >
>> > >[ 
>> > > https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198482#comment-17198482
>> > >  ]
>> > >
>> > > Ishan Chattopadhyaya commented on SOLR-14151:
>> > > -
>> > >
>> > > +1 on reverting all traces of this work immediately, and committing back 
>> > > only when there are no failures. We can request Uwe to enable Jenkins 
>> > > builds on a branch where we iterate on this until we are able to merge 
>> > > to master. Such drastic test failure situation is unacceptable.
>> > >
>> > >> Make schema components load from packages
>> > >> -
>> > >>
>> > >>Key: SOLR-14151
>> > >>URL: https://issues.apache.org/jira/browse/SOLR-14151
>> > >>Project: Solr
>> > >> Issue Type: Sub-task
>> > >>   Reporter: Noble Paul
>> > >>   Assignee: Noble Paul
>> > >>   Priority: Major
>> > >> Labels: packagemanager
>> > >>Fix For: 8.7
>> > >>
>> > >> Time Spent: 12h 50m
>> > >> Remaining Estimate: 0h
>> > >>
>> > >> Example:
>> > >> {code:xml}
>> > >> 
>> > >>
>> > >>  
>> > >>  > > >> generateNumberParts="0" catenateWords="0"
>> > >>  catenateNumbers="0" catenateAll="0"/>
>> > >>  
>> > >>  
>> > >>
>> > >>  
>> > >> {code}
>> > >> * When a package is updated, the entire {{IndexSchema}} object is 
>> > >> refreshed, but the SolrCore object is not reloaded
>> > >> * Any component can be prefixed with the package name
>> > >> * The semantics of loading plugins remain the same as that of the 
>> > >> components in {{solrconfig.xml}}
>> > >> * Plugins can be registered using schema API
>> > >
>> > >
>> > >
>> > > --
>> > > This message was sent by Atlassian Jira
>> > > (v8.3.4#803005)
>> > >
>> > > -
>> > > To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
>> > > For additional commands, e-mail: issues-h...@lucene.apache.org
>> > >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>


-- 
-
Noble Paul

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

Re: [jira] [Commented] (SOLR-14151) Make schema components load from packages

[Noble Paul]

I'm beasting changes so many times and I can't see the failures happening

I'm wondering if we should just disable the
TestPackages@testSchemaPlugins() or revert the changes wholesale

On Sat, Sep 19, 2020 at 10:44 PM Erick Erickson  wrote:
>
> I have to take it back a little. Hoss’ rollups show these tests failing 100% 
> of the time, but they pass on my machine locally at least some of the time…. 
> IDK quite why there’s a difference.
>
> Noble:
>
> Let me know if I can help, I can at least beast any fix.
>
> Erick
>
> > On Sep 18, 2020, at 2:13 PM, Ishan Chattopadhyaya (Jira)  
> > wrote:
> >
> >
> >[ 
> > https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198482#comment-17198482
> >  ]
> >
> > Ishan Chattopadhyaya commented on SOLR-14151:
> > -
> >
> > +1 on reverting all traces of this work immediately, and committing back 
> > only when there are no failures. We can request Uwe to enable Jenkins 
> > builds on a branch where we iterate on this until we are able to merge to 
> > master. Such drastic test failure situation is unacceptable.
> >
> >> Make schema components load from packages
> >> -
> >>
> >>Key: SOLR-14151
> >>URL: https://issues.apache.org/jira/browse/SOLR-14151
> >>Project: Solr
> >> Issue Type: Sub-task
> >>   Reporter: Noble Paul
> >>   Assignee: Noble Paul
> >>   Priority: Major
> >> Labels: packagemanager
> >>Fix For: 8.7
> >>
> >> Time Spent: 12h 50m
> >> Remaining Estimate: 0h
> >>
> >> Example:
> >> {code:xml}
> >> 
> >>
> >>  
> >>   >> generateNumberParts="0" catenateWords="0"
> >>  catenateNumbers="0" catenateAll="0"/>
> >>  
> >>  
> >>
> >>  
> >> {code}
> >> * When a package is updated, the entire {{IndexSchema}} object is 
> >> refreshed, but the SolrCore object is not reloaded
> >> * Any component can be prefixed with the package name
> >> * The semantics of loading plugins remain the same as that of the 
> >> components in {{solrconfig.xml}}
> >> * Plugins can be registered using schema API
> >
> >
> >
> > --
> > This message was sent by Atlassian Jira
> > (v8.3.4#803005)
> >
> > -
> > To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: issues-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: Our test failure rate is unacceptable.

[Noble Paul]

I shall revert the changes and work on a solution

On Sat, Sep 19, 2020, 6:54 AM Jason Gerlowski  wrote:

> > I don't think it is along the Apache way to revert somebody's commit
> without an explicit permission to do so
> Interesting, I made the Devil's Advocate argument above with the
> Apache Way specifically in mind.
>
> "Community over Code" comes up most often in terms of navigating
> interpersonal conflict and fostering contributors; that's valid and
> important.  But broken builds cause concrete "Community harm" as well.
> 100%-fails slow down every developer working on Solr for whatever
> length of time the project is in that state.  Established committers,
> first-PR contributors, Github forks, everyone.  Leaving 100%-fails out
> there while waiting for a committer to respond or fix an issue
> prolongs that period: slowing down development and turning off new
> potential contributors all the while.  So I think there's a concrete
> Apache Way argument for reverting early.
>
> Obviously the revert has to be done diplomatically or it risks
> alienating committers and undermining the other Apache Way benefits.
> But that's a question of execution not of approach.  There are
> tactful, inoffensive ways to roll back a change without implying
> negligence, impugning skill-sets, etc.   It's also not a concern
> that's specific to reverts - any JIRA comment or dev-list discussion
> pointing out issues runs into that.
>
> All that said, this is a Devil's Advocate argument I'm making here.  I
> have no plans to go around reverting other's commits; I was just
> curious where others were on this in case it came up again later.
>
> Best,
>
> Jason
>
> On Fri, Sep 18, 2020 at 3:59 PM Tomás Fernández Löbbe
>  wrote:
> >
> > I thought we were talking about reverting your own commits, not someone
> else’s...
> >
> > On Fri, Sep 18, 2020 at 12:31 PM Dawid Weiss 
> wrote:
> >>
> >> I don't think it is along the Apache way to revert somebody's commit
> >>
> >> without an explicit permission to do so... Not that I would personally
> >>
> >> mind if somebody did it for me.
> >>
> >>
> >>
> >> On Fri, Sep 18, 2020 at 9:06 PM Tomás Fernández Löbbe
> >>
> >>  wrote:
> >>
> >> >
> >>
> >> > Sometimes Jenkins may take hours to take your commit, may fail in the
> middle of your night, may not fail consistently, etc. That's why I don't
> think giving specific timeframes makes sense, but yes, as soon as you
> notice it's failing, it's either fix immediately or revert IMO.
> >>
> >> >
> >>
> >> > On Fri, Sep 18, 2020 at 12:03 PM Jason Gerlowski <
> gerlowsk...@gmail.com> wrote:
> >>
> >> >>
> >>
> >> >> > If it’s inadvertently added, we either fix it within an hour or so
> or revert the offending commit
> >>
> >> >>
> >>
> >> >> > I don't want to set specific time frames,
> >>
> >> >>
> >>
> >> >> To play Devil's Advocate here: why wait even an hour to revert a 100%
> >>
> >> >> test failure?  Reverts are usually trivial to do, unblock others
> >>
> >> >> immediately, and don't interfere with the fix process at all.
> >>
> >> >> Remembering the times I've broken the build myself, reverts even seem
> >>
> >> >> preferable from that position - reverting up front takes all the
> >>
> >> >> time-pressure off of getting out a fix.  Why work under the gun when
> >>
> >> >> you don't have to?
> >>
> >> >>
> >>
> >> >> On Fri, Sep 18, 2020 at 1:14 PM Tomás Fernández Löbbe
> >>
> >> >>  wrote:
> >>
> >> >> >
> >>
> >> >> > I believe these failures are associated to
> https://issues.apache.org/jira/browse/SOLR-14151
> >>
> >> >> >
> >>
> >> >> > • FAILED:  org.apache.solr.pkg.TestPackages.classMethod
> >>
> >> >> > • FAILED:
> org.apache.solr.schema.PreAnalyzedFieldManagedSchemaCloudTest.testAdd2Fields
> >>
> >> >> > • FAILED:
> org.apache.solr.schema.ManagedSchemaRoundRobinCloudTest.testAddFieldsRoundRobin
> >>
> >> >> >
> >>
> >> >> > > IMO if a temporary instability is to be introduced deliberately,
> it should be published on the list. If it’s inadvertently added, we either
> fix it within an hour or so or revert the offending commit
> >>
> >> >> > I don't want to set specific time frames, but sometimes it's
> obviously too much time.
> >>
> >> >> >
> >>
> >> >> > On Fri, Sep 18, 2020 at 8:48 AM Atri Sharma 
> wrote:
> >>
> >> >> >>
> >>
> >> >> >> When I said temporary, I meant 3-4 hours. Definitely not more
> than that.
> >>
> >> >> >>
> >>
> >> >> >> IMO we should just roll back offending commits if they are easily
> identifiable. I agree with you — we all have been guilty of breaking builds
> (mea culpa as well). The bad part here is the longevity of the failures.
> >>
> >> >> >>
> >>
> >> >> >>
> >>
> >> >> >> On Fri, 18 Sep 2020 at 21:05, Erick Erickson <
> erickerick...@gmail.com> wrote:
> >>
> >> >> >>>
> >>
> >> >> >>> bq. IMO if a temporary instability is to be introduced
> deliberately, it should be published on the list
> >>
> >> >> >>>
> >>
> >> >> >>>
> >>
> >> >> >>>
> >>
> >> >> >>> Actually, I disagree. Having 

Re: Placement plugin PR commit - soon

[Noble Paul]

Please switch the API to use annotations before you commit this

On Tue, Sep 15, 2020 at 2:01 PM Ishan Chattopadhyaya
 wrote:
>
> +1. Thanks for the heads up! This is a practice we all should adopt.
>
> On Tue, 15 Sep, 2020, 4:06 am Ilan Ginzburg,  wrote:
>>
>> Advance notice:
>>
>> I plan to commit to master/9.0 coming Wednesday September 16th the 
>> "Placement plugin" PR corresponding to SOLR-14613.
>> This will be the first drop of code for the replacement of the Autoscaling 
>> code that was previously removed from 9.0.
>>
>> This code is disabled by default and requires the user to set a 
>> configuration in ZK's /clusterprops.json to be enabled.
>>
>> Ilan
>>
>>


-- 
-
Noble Paul

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

Re: Solr configuration options

[Noble Paul]

> to stick with solr.xml for current and ongoing feature development and not 
> hold up development based on things that may or may not happen in the future.

Where did I say that? There are so many features built recently using
clusterprops.json. The least we can do is stop piling more into
solr.xml. If you cannot make something better the least you can do is
stop making life more difficult for everyone.

>In order for clusterpropos.json to replace what's currently done with 
>solr.xml, we'd need to introduce a mechanism to make configuration available 
>out of the box

How hard is it to insert a JSON into your ZK ?

The problem with Solr developers is they only have one workflow in
their mind, the way they use it in their org. How many of us
understand the pain of restarting the entire cluster because we wish
to change a single config param for replica placement.

We really do not care if a newcomer will be able to edit an XML file
in every node to use this feature. You know why? We really do not want
anyone to use this feature, Most of us are paid my our respective
organizations and as long as it meets their needs they're totally
happy. Why don't you all go back, and work on your own internal fork
of Solr if that is all that you guys want. Why even pretend that
something is pluggable & offer some value to our users.

The existing autoscaling config was stored in ZK , did users complain
that they have difficulty in storing that file in ZK?

On Thu, Sep 3, 2020 at 7:20 PM Jan Høydahl  wrote:
>
> Let’s not do another magic overlay json file on top of xml with all the 
> confusion it creates.
> +1 to stick with solr.xml for current and ongoing feature development and not 
> hold up development based on things that may or may not happen in the future. 
> Discussing removal of solr.xml is a typical SIP candidate?
>
> Jan
>
> 3. sep. 2020 kl. 10:06 skrev Ilan Ginzburg :
>
> Noble,
>
> In order for clusterpropos.json to replace what's currently done with 
> solr.xml, we'd need to introduce a mechanism to make configuration available 
> out of the box (when Zookeeper is still empty). And if clusterpropos.json is 
> to be used in standalone mode, it also must live somewhere on disk as well 
> (no Zookeeper in standalone mode).
>
> I believe shardHandlerFactoryConfig is in solr.xml for all nodes to know 
> which shard handler to use, not for configuring a different one on each node.
>
> Priming an empty Zookeeper with an initial version of clusterpropos.json on 
> startup is easy (first node up pushes its local copy). But after this 
> happened once, if Solr is upgraded with a new default clusterprops.json, it 
> is hard (to very hard) to update the Zookeeper version, high risk of erasing 
> configuration that the user added or does not want to change.
>
> How about a variant? Keep a local solr.xml file with default configs and 
> support overriding of these configs from Zookeeper's clusterprops.json. This 
> approach does not have the out of the box issue mentioned above, and 
> practically also solves the "updating defaults" issue: if the user cherry 
> picked some solr.xml configuration values and overrode them 
> clusterprops.json, it is then his responsibility to maintain them there. 
> Newly introduced configuration values in solr.xml (due to a new Solr version) 
> are not impacted since they were not overridden.
>
> I believe this approach is not too far from a suggestion you seem to make to 
> hard code default configs to get rid of solr.xml. The difference is that the 
> hard coding is done in solr.xml rather than in some defaultSolrConfig.java 
> class. This makes changing default configuration easy and not requiring 
> recompilation but is otherwise not conceptually different.
>
> Ilan
>
>
> On Thu, Sep 3, 2020 at 7:05 AM Noble Paul  wrote:
>>
>> Let's take a step back and take a look at the history of Solr.
>>
>> Long ago there was only standalone Solr with a single core
>> there were 3 files
>>
>> * solr.xml : everything required for CoreContainer went here
>> * solr.config.xml : per core configurations go here
>> * schema.xml: this is not relevant for this discussion
>>
>> Now we are in the cloud world where everything lives in ZK. This also
>> means there are potentially 1000's of nodes reading configuration from
>> ZK. This is quite a convenient setup. The same configset is being
>> shared by a very large no:of nodes and everyone is happy.
>>
>> But, solr.xml still stands out like a sore thumb. We have no idea what
>> it is for? is it a node specific configuration? or is it something
>> that every single node in the cluster should have in common?
>>
>> e:g: shardHandlerFactoryConfig.
>>
>> Does it ev

Re: [VOTE] Lucene logo contest, third time's a charm

[Noble Paul]

go.
> >>
> >> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
> >>
> >> Please vote for one of the above choices. This vote will close about one 
> >> week from today, Mon, Sept 7, 2020 at 11:59PM.
> >>
> >> Thanks!
> >>
> >> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> >> [first-vote] 
> >> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> >> [second-vote] 
> >> http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e
> >> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: Solr configuration options

[Noble Paul]

figs//solrconfig.xml) allows Solr 
> >>>>>>> >> devs to set reasonable defaults (the file is part of the Solr 
> >>>>>>> >> distribution). Content can be changed by users as they create new 
> >>>>>>> >> Config Sets persisted in Zookeeper.
> >>>>>>> >>
> >>>>>>> >> Zookeeper's /clusterprops.json can be edited through the 
> >>>>>>> >> collection admin API CLUSTERPROP. If users do not set anything 
> >>>>>>> >> there, the file doesn't even exist in Zookeeper therefore `Solr 
> >>>>>>> >> devs cannot use it to set a default cluster config, there's no 
> >>>>>>> >> clusterprops.json file in the Solr distrib like there's a 
> >>>>>>> >> solrconfig.xml.
> >>>>>>> >>
> >>>>>>> >> File solr.xml is used by Solr devs to set some reasonable default 
> >>>>>>> >> configuration (parametrized through property files or system 
> >>>>>>> >> properties). There's no API to change that file, users would have 
> >>>>>>> >> to edit/redeploy the file on each node and restart the Solr JVM on 
> >>>>>>> >> that node for the new config to be taken into account.
> >>>>>>> >>
> >>>>>>> >> Based on the above, my vision (or mental model) of what to use 
> >>>>>>> >> depending on the need:
> >>>>>>> >>
> >>>>>>> >> solrconfig.xml is the only per collection config. IMO it does its 
> >>>>>>> >> job correctly: Solr devs can set defaults, users tailor the 
> >>>>>>> >> content to what they need for new config sets. It's the only 
> >>>>>>> >> option for per collection config anyway.
> >>>>>>> >>
> >>>>>>> >> The real hesitation could be between solr.xml and Zookeeper 
> >>>>>>> >> /clusterprops.json. What should go where?
> >>>>>>> >>
> >>>>>>> >> For user configs (anything the user does to the Solr cluster AFTER 
> >>>>>>> >> it was deployed and started), /clusterprops.json seems to be the 
> >>>>>>> >> obvious choice and offers the right abstractions (global config, 
> >>>>>>> >> no need to worry about individual nodes, all nodes pick up configs 
> >>>>>>> >> and changes to configs dynamically).
> >>>>>>> >>
> >>>>>>> >> For configs that need to be available without requiring user 
> >>>>>>> >> intervention or needed before the connection to ZK is established, 
> >>>>>>> >> there's currently no other choice than using solr.xml. Such 
> >>>>>>> >> configuration obviously include parameters that are needed to 
> >>>>>>> >> connect to ZK (timeouts, credential provider and hopefully one day 
> >>>>>>> >> an option to either use direct ZK interaction code or Curator 
> >>>>>>> >> code), but also configuration of general features that should be 
> >>>>>>> >> the default without requiring users to opt in yet allowing then to 
> >>>>>>> >> easily opt out by editing solr.xml before deploying to their 
> >>>>>>> >> cluster (in the future, this could include which Lucene version to 
> >>>>>>> >> load in Solr for example).
> >>>>>>> >>
> >>>>>>> >> To summarize:
> >>>>>>> >>  • Collection specific config? --> solrconfig.xml
> >>>>>>> >>  • User provided cluster config once SolrCloud is running? --> 
> >>>>>>> >> ZK /clusterprops.json
> >>>>>>> >>  • Solr dev provided cluster config? --> solr.xml
> >>>>>>> >>
> >>>>>>> >> Going forward, some (but only some!) of the config that currently 
> >>>>>>> >> can only live in solr.xml could be made to go to 
> >>>>>>> >> /clusterprops.json or another ZK based config file. This would 
> >>>>>>> >> require adding code to create that ZK file upon initial cluster 
> >>>>>>> >> start (to not force the user to push it) and devise a mechanism 
> >>>>>>> >> (likely a script, could be tricky though) to update that file in 
> >>>>>>> >> ZK when a new release of Solr is deployed and a previous version 
> >>>>>>> >> of that file already exists. Not impossible tasks, but not trivial 
> >>>>>>> >> ones either. Whatever the needs of such an approach are, it might 
> >>>>>>> >> be easier to keep the existing solr.xml as a file and allow users 
> >>>>>>> >> to define overrides in Zookeeper for the configuration parameters 
> >>>>>>> >> from solr.xml that make sense to be overridden in ZK (obviously ZK 
> >>>>>>> >> credentials or connection timeout do not make sense in that 
> >>>>>>> >> context, but defining the shard handler implementation class does 
> >>>>>>> >> since it is likely loaded after a node managed to connect to ZK).
> >>>>>>> >>
> >>>>>>> >> Some config will have to stay in a local Node file system file and 
> >>>>>>> >> only there no matter what: Zookeeper timeout definition or any 
> >>>>>>> >> node configuration that is needed before the node connects to 
> >>>>>>> >> Zookeeper.
> >>>>>>> >>
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > -
> >>>>>>> > 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
> >>>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> http://www.needhamsoftware.com (work)
> >>>>> http://www.the111shift.com (play)
> >>>
> >>>
> >>>
> >>> --
> >>> http://www.needhamsoftware.com (work)
> >>> http://www.the111shift.com (play)
> >
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: Annoying but harmless exceptions due to filepermissions when running tests

[Noble Paul]

The filestore dir is where the packages live. If we move it to another
location, existing installations might fail. So, it's a backward
incompatible change.

What are our options?

Is it possible to have these directories precreated in the distro/code to
ensure that these warnings don't come.

On Thu, Sep 3, 2020, 4:58 AM Erick Erickson  wrote:

> Oh bother. Somehow I thought I’d looked and only a handful of tests
> reported this.
>
> So I looked again and I _wish_ I was able to blame drugs cause you’re
> right, there
> are over a thousand of them.
>
> Never mind...
>
> > On Sep 1, 2020, at 8:55 PM, Chris Hostetter 
> wrote:
> >
> >
> > : Hmmm, that’s kind of an dilemma then. Are you saying that
> > : he test can see that the directory appears writable then tries
> > : to write to it then gets tripped up by the framework?
> > :
> > : Seems to me that a test that tries to write, thinks it can and then
> > : can’t should fail anyway.
> > :
> > : Well, I don’t think there are very many tests that have this problem
> > : anyway, so maybe I can examine them one-by-one and not
> > : introduce new failures...
> >
> > You keep using the phrase "the test" in the context of (trying to)
> create
> > these directories ("userfiles" and "filestore") ... the "test CODE"
> isn't
> > making any choices about trying to write those files -- the choice is
> > being made by the "CoreContainer CODE".
> >
> > These features were added with the explicit implementation choice to
> _TRY_
> > to write the "usersfiles" (and/or "filestore") directory to "solr home"
> IF
> > POSSIBLE, and if so then enable a bunch of features -- if NOT then log a
> > WARNing and don't enable those features.
> >
> > So what you're seeing here isn't an artifact/result of any particular
> > choices "a test" or "the test" makes -- it's a concious choice of the
> > developer who added this feature to solr.  These WARN messages that show
> > up in tests where the solr home dir isn't writable (which is actaully
> the
> > vast majority of tests because of how the test framework works) are the
> > same types of WARN messages that a "real" solr deployment might get if
> > their solr home dir isn't wriable (ie: maybe the use ${solr.data.dir} to
> > point to a diff drive).
> >
> >
> >
> > :
> > : > On Aug 31, 2020, at 1:29 PM, Chris Hostetter <
> hossman_luc...@fucit.org> wrote:
> > : >
> > : >
> > : > Some tests "create" a new solr home dir and copy config files there,
> but
> > : > you'll see this type of WARN logging for any test that just uses the
> test
> > : > configs "in place" because of how the code is designed to _try_ and
> create
> > : > a userfiles directory in the solr home if it's writable.
> > : >
> > : >
> > : > : Date: Sat, 29 Aug 2020 09:25:17 -0400
> > : > : From: Erick Erickson 
> > : > : Reply-To: dev@lucene.apache.org
> > : > : To: dev@lucene.apache.org
> > : > : Subject: Re: Annoying but harmless exceptions due to
> filepermissions when
> > : > : running tests
> > : > :
> > : > : Well, as Uwe and I discussed offline, he’s right and I’m wrong.
> > : > :
> > : > : In CoreContainer [364] there’s code like this:
> > : > :
> > : > : Path userFilesPath = return solrHome.resolve("userfiles"); // TODO
> make configurable on cfg?
> > : > : try {
> > : > :   Files.createDirectories(userFilesPath); // does nothing if
> already exists
> > : > : } catch (Exception e) {
> > : > :   log.warn("Unable to create [{}].  Features requiring this
> directory may fail.", userFilesPath, e);
> > : > : }
> > : > :
> > : > : So I assumed it would happen on most every test, at least in cloud
> mode. But when I tried to make it happen on a different test, there was no
> exception.
> > : > :
> > : > : I’ll have to poke some more to see what’s really happening…
> > : > :
> > : > : Never Mind….
> > : > :
> > : > : > On Aug 29, 2020, at 8:59 AM, Uwe Schindler 
> wrote:
> > : > : >
> > : > : > Hi,
> > : > : >
> > : > : > this is a bug in the test! It should never ever modify files
> outside its sandbox. It should not even modify files in build directory. It
> is fully valid to reject those writes - has nothing to do with users, it's
> just forbidden by the test framework. Modifying this file is harmful, as it
> may affect later tests.
> > : > : >
> > : > : > So the correct way is to copy those files to the solr container
> running inside test's sandbox. That's one of the main advantages of the
> Test sandbox: No write access anywhere outside the test, see policy file.
> > : > : >
> > : > : > Uwe
> > : > : >
> > : > : > -
> > : > : > Uwe Schindler
> > : > : > Achterdiek 19, D-28357 Bremen
> > : > : > https://www.thetaphi.de
> > : > : > eMail: u...@thetaphi.de
> > : > : >
> > : > : >> -Original Message-
> > : > : >> From: Erick Erickson 
> > : > : >> Sent: Saturday, August 29, 2020 2:54 PM
> > : > : >> To: dev@lucene.apache.org
> > : > : >> Subject: Annoying but harmless exceptions due to
> filepermissions when running
> > : > : >> tests
> > : > : >>
> > : > 

Re: [VOTE] Lucene logo contest, here we go again

[Noble Paul]

D (binding)

On Tue, Sep 1, 2020 at 5:15 PM Jan Høydahl  wrote:
>
> D (binding)
>
> Jan
>
> 1. sep. 2020 kl. 02:26 skrev Ryan Ernst :
>
> Dear Lucene and Solr developers!
>
> In February a contest was started to design a new logo for Lucene 
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in 
> some confusion on the rules, as well the request for one additional 
> submission. I would like to call a new vote, now with more explicit 
> instructions on how to vote.
>
> Please read the following rules carefully before submitting your vote.
>
> Who can vote?
>
> Anyone is welcome to cast a vote in support of their favorite submission(s). 
> Note that only PMC member's votes are binding. If you are a PMC member, 
> please indicate with your vote that the vote is binding, to ease collection 
> of votes. In tallying the votes, I will attempt to verify only those marked 
> as binding.
>
> How do I vote?
>
> Votes can be cast simply by replying to this email. It is a ranked-choice 
> vote [rank-choice-voting]. Multiple selections may be made, where the order 
> of preference must be specified. If an entry gets more than half the votes, 
> it is the winner. Otherwise, the entry with the lowest number of votes is 
> removed, and the votes are retallied, taking into account the next preferred 
> entry for those whose first entry was removed. This process repeats until 
> there is a winner.
>
> The entries are broken up by variants, since some entries have multiple color 
> or style variations. The entry identifiers are first a capital letter, 
> followed by a variation id (described with each entry below), if applicable. 
> As an example, if you prefer variant 1 of entry A, followed by variant 2 of 
> entry A, variant 3 of entry C, entry D, and lastly variant 4e of entry B, the 
> following should be in your reply:
>
> (binding)
> vote: A1, A2, C3, D, B4e
>
> Entries
>
> The entries are as follows:
>
> A. Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>
> [A1] 
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [A2] https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the 
> linked entry there are 7 patterns and 7 color palettes. Any vote for B should 
> contain the pattern number followed by the lowercase letter of the color 
> palette. For example, B3e or B1a.
>
> [B] https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>
> C. Submitted by Baris Kazar. This entry has 8 variants.
>
> [C1] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> [C2] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
> [C3] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
> [C4] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
> [C5] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
> [C6] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
> [C7] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
> [C8] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
>
> D. The current Lucene logo.
>
> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>
> Please vote for one of the above choices. This vote will close one week from 
> today, Mon, Sept 7, 2020 at 11:59PM.
>
> Thanks!
>
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> [first-vote] 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>
>


-- 
-
Noble Paul

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

Re: RoadMap?

[Noble Paul]

es/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
>>
>>


-- 
-
Noble Paul

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

Re: Welcome Atri Sharma to the PMC

[Noble Paul]

Welcome Atri!

On Fri, Aug 21, 2020 at 5:08 PM Dawid Weiss  wrote:
>
>
> Congratulations and welcome, Atri.
>
> On Thu, Aug 20, 2020 at 8:16 PM Ishan Chattopadhyaya 
>  wrote:
>>
>> I am pleased to announce that Atri Sharma has accepted the PMC's invitation 
>> to join.
>>
>> Congratulations and welcome, Atri!
>>
>>


-- 
-
Noble Paul

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

Re: 8.7 Release

[Noble Paul]

There are a lot of blockers for 8.7. It's good to plan in advance

On Thu, Aug 20, 2020 at 7:11 PM Ishan Chattopadhyaya
 wrote:
>
> Hi devs,
> A lot of changes are now in 8.7 or in-flight. I'd like to volunteer for a 8.7 
> release in around a month from now (cutting the release branch around 20 
> September) and RC shortly after. I feel this timeline will give all of us 
> ample time to wrap up the release blockers, other changes and improvements.
>
> Does someone have any thoughts, concerns or objections?
> Regards,
> Ishan
>


-- 
-----
Noble Paul

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

Re: Survey on ManagedResources feature

[Noble Paul]

You just needed a standard interface that abstracts out storing files
(ZK/File system)

On Thu, Aug 20, 2020 at 6:02 PM Matthias Krueger  wrote:
>
>
> I don't use ManagedResourceStorage, just the StorageIO interface and its
> implementations. The benefit is ZK AND filesystem support for WRITING
> configuration file updates. Otherwise I would have to come up with
> something like the common interface (StorageIO), its implementations for
> ZK and FS and the dispatching code (ManagedResourceStorage#newStorageIO)
> myself. I guess the LTR plugin had similar reasons to go that route.
>
>
> On 19.08.20 08:49, Noble Paul wrote:
> > So, it's not very different from directly reading a file from ZK?
> >
> > what benefit do you get by using the ManagedResourceStorage?
> >
> > On Sun, Aug 16, 2020 at 7:08 PM Matthias Krueger  wrote:
> >>
> >> In a custom SolrRequestHandler#handleRequest something like this:
> >>
> >> final ManagedResourceStorage.StorageIO storageIO =
> >> ManagedResourceStorage.newStorageIO(core.getCoreDescriptor().getCollectionName(),
> >> resourceLoader, new NamedList<>());
> >>
> >> And then using
> >>
> >> storageIO.openOutputStream(resourceName)
> >>
> >> to store some (well-known) resources.
> >>
> >> Matt
> >>
> >>
> >> On 15.08.20 11:38, Noble Paul wrote:
> >>>> I use MangedResource#StorageIO and its implementations as a convenient 
> >>>> way to abstract away the underlying config storage when creating plugins 
> >>>> that need to support both, SolrCloud and Solr Standalone.
> >>> Can you give us some more details on how you use it?
> >>>
> >>> On Sat, Aug 15, 2020 at 7:32 PM Noble Paul  wrote:
> >>>>> As authentication is plugged into the SolrDispatchFilter I would assume 
> >>>>> that you would need to be authenticated to read/write Managed Resources
> >>>> I'm talking about the authorization plugins
> >>>>
> >>>> On Fri, Aug 14, 2020 at 10:20 PM Matthias Krueger  wrote:
> >>>>> As authentication is plugged into the SolrDispatchFilter I would assume 
> >>>>> that you would need to be authenticated to read/write Managed Resources 
> >>>>> but no authorization is checked (i.e. any authenticated user can 
> >>>>> read/write them), correct?
> >>>>>
> >>>>> Anyway, I came across Managed Resources in at least two scenarios:
> >>>>>
> >>>>> The LTR plugin is using them for updating model/features.
> >>>>> I use MangedResource#StorageIO and its implementations as a convenient 
> >>>>> way to abstract away the underlying config storage when creating 
> >>>>> plugins that need to support both, SolrCloud and Solr Standalone.
> >>>>>
> >>>>> IMO an abstraction that allows distributing configuration (ML models, 
> >>>>> configuration snippets, external file fields...) that exceeds the 
> >>>>> typical ZK size limits to SolrCloud while also supporting Solr 
> >>>>> Standalone would be nice to have.
> >>>>>
> >>>>> Matt
> >>>>>
> >>>>>
> >>>>> On 12.08.20 02:08, Noble Paul wrote:
> >>>>>
> >>>>> The end point is served by restlet. So, your rules are not going to be 
> >>>>> honored. The rules work only if it is served by a Solr request handler
> >>>>>
> >>>>> On Wed, Aug 12, 2020, 12:46 AM Jason Gerlowski  
> >>>>> wrote:
> >>>>>> Hey Noble,
> >>>>>>
> >>>>>> Can you explain what you mean when you say it's not secured?  Just for
> >>>>>> those of us who haven't been following the discussion so far?  On the
> >>>>>> surface of things users taking advantage of our RuleBasedAuth plugin
> >>>>>> can secure this API like they can any other HTTP API.  Or are you
> >>>>>> talking about some other security aspect here?
> >>>>>>
> >>>>>> Jason
> >>>>>>
> >>>>>> On Tue, Aug 11, 2020 at 9:55 AM Noble Paul  
> >>>>>> wrote:
> >>>>>>> Hi all,
> >>>>>>> The end-point for Managed resources is not secured. So it needs to be
> >>&g

Re: Survey on ManagedResources feature

[Noble Paul]

So, it's not very different from directly reading a file from ZK?

what benefit do you get by using the ManagedResourceStorage?

On Sun, Aug 16, 2020 at 7:08 PM Matthias Krueger  wrote:
>
>
> In a custom SolrRequestHandler#handleRequest something like this:
>
> final ManagedResourceStorage.StorageIO storageIO =
> ManagedResourceStorage.newStorageIO(core.getCoreDescriptor().getCollectionName(),
> resourceLoader, new NamedList<>());
>
> And then using
>
> storageIO.openOutputStream(resourceName)
>
> to store some (well-known) resources.
>
> Matt
>
>
> On 15.08.20 11:38, Noble Paul wrote:
> >> I use MangedResource#StorageIO and its implementations as a convenient way 
> >> to abstract away the underlying config storage when creating plugins that 
> >> need to support both, SolrCloud and Solr Standalone.
> > Can you give us some more details on how you use it?
> >
> > On Sat, Aug 15, 2020 at 7:32 PM Noble Paul  wrote:
> >>> As authentication is plugged into the SolrDispatchFilter I would assume 
> >>> that you would need to be authenticated to read/write Managed Resources
> >> I'm talking about the authorization plugins
> >>
> >> On Fri, Aug 14, 2020 at 10:20 PM Matthias Krueger  wrote:
> >>>
> >>> As authentication is plugged into the SolrDispatchFilter I would assume 
> >>> that you would need to be authenticated to read/write Managed Resources 
> >>> but no authorization is checked (i.e. any authenticated user can 
> >>> read/write them), correct?
> >>>
> >>> Anyway, I came across Managed Resources in at least two scenarios:
> >>>
> >>> The LTR plugin is using them for updating model/features.
> >>> I use MangedResource#StorageIO and its implementations as a convenient 
> >>> way to abstract away the underlying config storage when creating plugins 
> >>> that need to support both, SolrCloud and Solr Standalone.
> >>>
> >>> IMO an abstraction that allows distributing configuration (ML models, 
> >>> configuration snippets, external file fields...) that exceeds the typical 
> >>> ZK size limits to SolrCloud while also supporting Solr Standalone would 
> >>> be nice to have.
> >>>
> >>> Matt
> >>>
> >>>
> >>> On 12.08.20 02:08, Noble Paul wrote:
> >>>
> >>> The end point is served by restlet. So, your rules are not going to be 
> >>> honored. The rules work only if it is served by a Solr request handler
> >>>
> >>> On Wed, Aug 12, 2020, 12:46 AM Jason Gerlowski  
> >>> wrote:
> >>>> Hey Noble,
> >>>>
> >>>> Can you explain what you mean when you say it's not secured?  Just for
> >>>> those of us who haven't been following the discussion so far?  On the
> >>>> surface of things users taking advantage of our RuleBasedAuth plugin
> >>>> can secure this API like they can any other HTTP API.  Or are you
> >>>> talking about some other security aspect here?
> >>>>
> >>>> Jason
> >>>>
> >>>> On Tue, Aug 11, 2020 at 9:55 AM Noble Paul  wrote:
> >>>>> Hi all,
> >>>>> The end-point for Managed resources is not secured. So it needs to be
> >>>>> fixed/eliminated.
> >>>>>
> >>>>> I would like to know what is the level of adoption for that feature
> >>>>> and if it is a critical feature for users.
> >>>>>
> >>>>> Another possibility is to offer a replacement for the feature using a
> >>>>> different API
> >>>>>
> >>>>> Your feedback will help us decide on what a potential solution should be
> >>>>>
> >>>>> --
> >>>>> -
> >>>>> Noble Paul
> >>
> >>
> >> --
> >> -
> >> Noble Paul
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: Welcome Namgyu Kim to the PMC

[Noble Paul]

Welcome Namgyu!

On Sat, Aug 15, 2020 at 12:34 AM Christine Poerschke (BLOOMBERG/
LONDON)  wrote:
>
> Welcome Namgyu!
>
> From: dev@lucene.apache.org At: 08/07/20 02:39:56
> To: dev@lucene.apache.org
> Subject: Re: Welcome Namgyu Kim to the PMC
>
> Congrats  Namgyu!
>
> -Yonik
>
>
> On Sun, Aug 2, 2020 at 7:19 PM Ishan Chattopadhyaya 
>  wrote:
>>
>> I am pleased to announce that Namgyu Kim has accepted the PMC's invitation 
>> to join.
>>
>> Congratulations and welcome, Namgyu!
>
>


-- 
-
Noble Paul

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

Re: Survey on ManagedResources feature

[Noble Paul]

>I use MangedResource#StorageIO and its implementations as a convenient way to 
>abstract away the underlying config storage when creating plugins that need to 
>support both, SolrCloud and Solr Standalone.

Can you give us some more details on how you use it?

On Sat, Aug 15, 2020 at 7:32 PM Noble Paul  wrote:
>
> >As authentication is plugged into the SolrDispatchFilter I would assume that 
> >you would need to be authenticated to read/write Managed Resources
>
> I'm talking about the authorization plugins
>
> On Fri, Aug 14, 2020 at 10:20 PM Matthias Krueger  wrote:
> >
> >
> > As authentication is plugged into the SolrDispatchFilter I would assume 
> > that you would need to be authenticated to read/write Managed Resources but 
> > no authorization is checked (i.e. any authenticated user can read/write 
> > them), correct?
> >
> > Anyway, I came across Managed Resources in at least two scenarios:
> >
> > The LTR plugin is using them for updating model/features.
> > I use MangedResource#StorageIO and its implementations as a convenient way 
> > to abstract away the underlying config storage when creating plugins that 
> > need to support both, SolrCloud and Solr Standalone.
> >
> > IMO an abstraction that allows distributing configuration (ML models, 
> > configuration snippets, external file fields...) that exceeds the typical 
> > ZK size limits to SolrCloud while also supporting Solr Standalone would be 
> > nice to have.
> >
> > Matt
> >
> >
> > On 12.08.20 02:08, Noble Paul wrote:
> >
> > The end point is served by restlet. So, your rules are not going to be 
> > honored. The rules work only if it is served by a Solr request handler
> >
> > On Wed, Aug 12, 2020, 12:46 AM Jason Gerlowski  
> > wrote:
> >>
> >> Hey Noble,
> >>
> >> Can you explain what you mean when you say it's not secured?  Just for
> >> those of us who haven't been following the discussion so far?  On the
> >> surface of things users taking advantage of our RuleBasedAuth plugin
> >> can secure this API like they can any other HTTP API.  Or are you
> >> talking about some other security aspect here?
> >>
> >> Jason
> >>
> >> On Tue, Aug 11, 2020 at 9:55 AM Noble Paul  wrote:
> >> >
> >> > Hi all,
> >> > The end-point for Managed resources is not secured. So it needs to be
> >> > fixed/eliminated.
> >> >
> >> > I would like to know what is the level of adoption for that feature
> >> > and if it is a critical feature for users.
> >> >
> >> > Another possibility is to offer a replacement for the feature using a
> >> > different API
> >> >
> >> > Your feedback will help us decide on what a potential solution should be
> >> >
> >> > --
> >> > -
> >> > Noble Paul
>
>
>
> --
> -
> Noble Paul



-- 
-
Noble Paul

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

Re: Welcome Gus Heck to the PMC

[Noble Paul]

Welcome Gus!

On Sat, Aug 15, 2020 at 12:36 AM Christine Poerschke (BLOOMBERG/
LONDON)  wrote:
>
> Welcome Gus!
>
> From: dev@lucene.apache.org At: 08/07/20 02:38:58
> To: dev@lucene.apache.org
> Subject: Re: Welcome Gus Heck to the PMC
>
> Congrats Gus!
>
> -Yonik
>
> On Sun, Aug 2, 2020 at 7:21 PM Ishan Chattopadhyaya 
>  wrote:
>>
>> I am pleased to announce that Gus Heck has accepted the PMC's invitation to 
>> join.
>>
>> Congratulations and welcome, Gus!
>
>


-- 
-
Noble Paul

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

Re: Welcome Munendra SN to the PMC

[Noble Paul]

Welcome Munendra

On Sat, Aug 15, 2020 at 12:37 AM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> Welcome Munendra!
>
> From: dev@lucene.apache.org At: 08/07/20 02:38:27
> To: dev@lucene.apache.org
> Subject: Re: Welcome Munendra SN to the PMC
>
> Congrats Munendra!
>
> -Yonik
>
>
> On Sun, Aug 2, 2020 at 7:20 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> I am pleased to announce that Munendra SN has accepted the PMC's
>> invitation to join.
>>
>> Congratulations and welcome, Munendra!
>>
>
>

-- 
-
Noble Paul

Re: Survey on ManagedResources feature

[Noble Paul]

>As authentication is plugged into the SolrDispatchFilter I would assume that 
>you would need to be authenticated to read/write Managed Resources

I'm talking about the authorization plugins

On Fri, Aug 14, 2020 at 10:20 PM Matthias Krueger  wrote:
>
>
> As authentication is plugged into the SolrDispatchFilter I would assume that 
> you would need to be authenticated to read/write Managed Resources but no 
> authorization is checked (i.e. any authenticated user can read/write them), 
> correct?
>
> Anyway, I came across Managed Resources in at least two scenarios:
>
> The LTR plugin is using them for updating model/features.
> I use MangedResource#StorageIO and its implementations as a convenient way to 
> abstract away the underlying config storage when creating plugins that need 
> to support both, SolrCloud and Solr Standalone.
>
> IMO an abstraction that allows distributing configuration (ML models, 
> configuration snippets, external file fields...) that exceeds the typical ZK 
> size limits to SolrCloud while also supporting Solr Standalone would be nice 
> to have.
>
> Matt
>
>
> On 12.08.20 02:08, Noble Paul wrote:
>
> The end point is served by restlet. So, your rules are not going to be 
> honored. The rules work only if it is served by a Solr request handler
>
> On Wed, Aug 12, 2020, 12:46 AM Jason Gerlowski  wrote:
>>
>> Hey Noble,
>>
>> Can you explain what you mean when you say it's not secured?  Just for
>> those of us who haven't been following the discussion so far?  On the
>> surface of things users taking advantage of our RuleBasedAuth plugin
>> can secure this API like they can any other HTTP API.  Or are you
>> talking about some other security aspect here?
>>
>> Jason
>>
>> On Tue, Aug 11, 2020 at 9:55 AM Noble Paul  wrote:
>> >
>> > Hi all,
>> > The end-point for Managed resources is not secured. So it needs to be
>> > fixed/eliminated.
>> >
>> > I would like to know what is the level of adoption for that feature
>> > and if it is a critical feature for users.
>> >
>> > Another possibility is to offer a replacement for the feature using a
>> > different API
>> >
>> > Your feedback will help us decide on what a potential solution should be
>> >
>> > --
>> > -
>> > Noble Paul



-- 
-
Noble Paul

-
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.1 RC2

[Noble Paul]

SUCCESS! [1:07:08.626970]
Ubuntu 20.04.1 LTS

On Wed, Aug 12, 2020 at 4:49 PM Atri Sharma  wrote:
>
> +1 (non binding).
>
> SUCCESS! [1:03:32.13920]
>
> On Wed, Aug 12, 2020 at 3:24 AM Gus Heck  wrote:
> >
> > SUCCESS! [0:54:03.106188]
> >
> > And installed the tarball as a 4 node cluster, created a collection and 
> > added a document - success :)
> >
> > +1
> >
> > On Tue, Aug 11, 2020 at 12:13 PM Timothy Potter  
> > wrote:
> >>
> >> Thanks Houston.
> >>
> >> SUCCESS! [1:34:35.219332]
> >>
> >> +1
> >>
> >> On Mon, Aug 10, 2020 at 1:02 PM Houston Putman  
> >> wrote:
> >>>
> >>> Please vote for release candidate 2 for Lucene/Solr 8.6.1
> >>>
> >>> The artifacts can be downloaded from:
> >>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC2-rev6e11a1c3f0599f1c918bc69c4f51928d23160e99
> >>>
> >>> 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.1-RC2-rev6e11a1c3f0599f1c918bc69c4f51928d23160e99
> >>>
> >>> The vote will be open for at least 72 hours i.e. until 2020-08-13 20:00 
> >>> UTC.
> >>>
> >>> [ ] +1  approve
> >>> [ ] +0  no opinion
> >>> [ ] -1  disapprove (and reason why)
> >>>
> >>> Here is my +1
> >
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
>
> --
> Regards,
>
> Atri
> Apache Concerted
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: Survey on ManagedResources feature

[Noble Paul]

The end point is served by restlet. So, your rules are not going to be
honored. The rules work only if it is served by a Solr request handler

On Wed, Aug 12, 2020, 12:46 AM Jason Gerlowski 
wrote:

> Hey Noble,
>
> Can you explain what you mean when you say it's not secured?  Just for
> those of us who haven't been following the discussion so far?  On the
> surface of things users taking advantage of our RuleBasedAuth plugin
> can secure this API like they can any other HTTP API.  Or are you
> talking about some other security aspect here?
>
> Jason
>
> On Tue, Aug 11, 2020 at 9:55 AM Noble Paul  wrote:
> >
> > Hi all,
> > The end-point for Managed resources is not secured. So it needs to be
> > fixed/eliminated.
> >
> > I would like to know what is the level of adoption for that feature
> > and if it is a critical feature for users.
> >
> > Another possibility is to offer a replacement for the feature using a
> > different API
> >
> > Your feedback will help us decide on what a potential solution should be
> >
> > --
> > -
> > Noble Paul
>

Survey on ManagedResources feature

[Noble Paul]

Hi all,
The end-point for Managed resources is not secured. So it needs to be
fixed/eliminated.

I would like to know what is the level of adoption for that feature
and if it is a critical feature for users.

Another possibility is to offer a replacement for the feature using a
different API

Your feedback will help us decide on what a potential solution should be

-- 
-
Noble Paul

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

Re: Missing class for tests

[Noble Paul]

I believe that's lost for good . We probably will have decompile and  add it

On Sat, Aug 8, 2020 at 7:42 AM Gus Heck  wrote:
>
> This test looks like an excellent Idea by the way. It's going to catch many 
> things that break back compat on plugins which is great, but we need a way to 
> regenerate the binary files it's loading. Such regeneration should probably 
> be a build target, and a comment in the test class regarding how to do that 
> (and pointing out the significance of doing so)
>
> -Gus
>
> On Fri, Aug 7, 2020 at 5:25 PM Gus Heck  wrote:
>>
>> Does anyone have (and can check in) the code for this class? I've got a 
>> failure loading this class but I can't troubleshoot it because apparently 
>> only a binary file is checked in...
>>
>> NS2-MacBook-Pro:lucene-solr gus$ grep -r "MyTextField" *
>> solr/core/src/test/org/apache/solr/pkg/TestPackages.java:  "
>> 'class':'schemapkg:my.pkg.MyTextField',\n" +
>> Binary file solr/core/src/test-files/runtimecode/schema-plugins.jar.bin 
>> matches
>>
>> -Gus
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)



-- 
-
Noble Paul

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

Re: Welcome Gus Heck to the PMC

[Noble Paul]

Welcome Gus!

On Mon, Aug 3, 2020 at 1:10 PM Koji Sekiguchi
 wrote:
>
> Welcome, Gus!
>
> Koji
>
> On 2020/08/03 8:20, Ishan Chattopadhyaya wrote:
> > I am pleased to announce that Gus Heck has accepted the PMC's invitation to 
> > join.
> >
> > Congratulations and welcome, Gus!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-----
Noble Paul

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

Re: Welcome Namgyu Kim to the PMC

[Noble Paul]

Welcome Namgyu!

On Mon, Aug 3, 2020 at 5:16 PM Adrien Grand  wrote:
>
> Welcome!
>
> On Mon, Aug 3, 2020 at 5:12 AM Koji Sekiguchi  
> wrote:
>>
>> Welcome, Namgyu!
>>
>> Koji
>>
>> On 2020/08/03 8:18, Ishan Chattopadhyaya wrote:
>> > I am pleased to announce that Namgyu Kim has accepted the PMC's invitation 
>> > to join.
>> >
>> > Congratulations and welcome, Namgyu!
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> Adrien



-- 
-
Noble Paul

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

Re: Welcome Munendra SN to the PMC

[Noble Paul]

Welcome Munendra!

On Mon, Aug 3, 2020 at 1:11 PM Koji Sekiguchi
 wrote:
>
> Welcome, Munendra!
>
> Koji
>
> On 2020/08/03 8:19, Ishan Chattopadhyaya wrote:
> > I am pleased to announce that Munendra SN has accepted the PMC's invitation 
> > to join.
> >
> > Congratulations and welcome, Munendra!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-----
Noble Paul

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

Re: SolrClient and making requests asynchronously

[Noble Paul]

I would also wish to deprecate all the public APIs which uses concrete
classes and move over to interfaces.

The objectives are.
* We should be able to use POJOs that help with strong typing
* We should be able to easily switch between JSON/javabin/XML or even
well known protocols like protobuf

On Sat, Aug 1, 2020 at 12:02 PM Noble Paul  wrote:
>
> Thanks David for bringing this up.
>
> I want us to stop using concrete classes. We should exclusively use
> interfaces in our public APIs.
>
> We should stop using NamedList and start using this interface
>
> https://github.com/apache/lucene-solr/blob/b91b461632b19c9488926a9302126a2158df3298/solr/solrj/src/java/org/apache/solr/common/util/SimpleMap.java
>
> NamedList will implement this interface too
>
> The SolrRequest is an abstract class and it has a huge surface area.
> We must create a simple small interface for this as will
>
>
>
>
> On Sat, Aug 1, 2020 at 6:25 AM David Smiley  wrote:
> >
> > Hello devs,
> >
> > I'd like to have an API design discussion here on the dev list concerning 
> > adding asynchronous request semantics to SolrClient.  I think the 
> > SolrClient APIs require great peer-review consideration and so I'm having 
> > this discussion here instead of a JIRA issue.
> >
> > Background: Sometimes, a SolrJ user (including Solr itself) may wish to 
> > issue a request but not block/wait for the response because it can do other 
> > useful work before eventually needing the results.  For example, maybe the 
> > user has multiple requests to send to Solr that can be done in parallel and 
> > _then_ process the results.  This is in fact what Solr needs internally for 
> > during distributed-search (see HttpShardHandler) and during 
> > distributed-indexing (see ConcurrentUpdateHttp2SolrClient).
> >
> > Why?:  Greater efficiency.  This can be accomplished easily in a generic 
> > fashion with threads (e.g. 
> > CompletableFuture.supplyAsync(Supplier,Executor)) with use of the 
> > SolrClient concurrently. However, this can result in lots of threads and 
> > context switching.  I really like Cao Dat's explanation in the description 
> > here:  https://issues.apache.org/jira/browse/SOLR-14354 Thanks to HTTP/2, 
> > there is a new approach in which the underlying HTTP client can handle the 
> > asynchronous nature more efficiently with minimal threads.  Complete 
> > plumbing of this implies that SolrClient (and/or its derivatives) need a 
> > similar async mechanism.  Disclaimer:  I haven't measured any of this but 
> > am piggybacking off of Cao's's insights on SOLR-14354
> >
> > Where?:  An async API _could_ go only on some SolrClient classes that 
> > natively support it, avoiding changing SolrClient itself.  Maybe this is 
> > what should occur first before "graduating" the method to SolrClient where 
> > we devise a default approach, although I would prefer just putting it on 
> > SolrClient.  The default approach might be configured to throw 
> > UnsupportedOperationException, or perhaps might simply use an Executor to 
> > get it done in an obvious way (assuming we can get ahold of an Executor 
> > somewhere?).  If you're writing a delegating SolrClient (which I've done in 
> > the past), you might want to take-care to delegate this method.
> > Another aspect of "Where" is whether SolrRequest should additionally have 
> > an API alternative to "process" which is currently synchronous and calls 
> > out to SolrClient.request(this).
> >
> > What?:  What should this API look like?  This is my primary interest right 
> > now and the meat of the discussion.
> >
> > SolrClient's primary signature that actually does the work (synchronously) 
> > is this:
> >
> > public abstract NamedList 
> > request(@SuppressWarnings({"rawtypes"})final SolrRequest request, String 
> > collection)
> > throws SolrServerException, IOException;
> >
> > I don't like the "collection" there as it's redundant with either the 
> > configured SolrClient default or a setting in SolrRequest, but I digress 
> > from the important matter at hand.
> >
> > In SOLR-14354, recently committed by Cao Dat destined for Solr 8.7, there 
> > is a new (undocumented) method on Http2SolrClient (*not* SolrClient):
> >
> > public Cancellable asyncRequest(@SuppressWarnings({"rawtypes"}) SolrRequest 
> > solrRequest, String collection, AsyncListener> 
> > asyncListener) {
> >
> > So firstly, it's only on Http2SolrClient, which means if you're using 
> > CloudHttp2SolrClient (which does no

Re: SolrClient and making requests asynchronously

[Noble Paul]

ethod that *returns* a CompletableFuture, and which 
> merely takes the SolrRequest parameter and nothing else.  Alternatively the 
> client could supply a CompletableFuture parameter that Solr will call 
> complete() on etc. but that seems a bit less natural to the notion of a 
> method that returns it's results, albeit with a wrapper.  Proposal:
>
> public CompletableFuture> requestAsync(SolrRequest 
> request);
>
> BTW I'm trying to avoid implementation details here.  My objective is to 
> devise a user-friendly API, and my hope is that the eventual implementation 
> is reasonable.
>
> I hope I haven't bored you all to tears and that you find this public 
> discussion useful.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley



-- 
-
Noble Paul

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

Re: Welcome Mike Drob to the PMC

[Noble Paul]

Welcome Mike!

On Thu, Jul 30, 2020 at 12:33 AM Erik Hatcher  wrote:
>
> Oh yeah!   Welcome, Mike!
>
> > On Jul 24, 2020, at 3:55 PM, Anshum Gupta  wrote:
> >
> > I am pleased to announce that Mike Drob has accepted the PMC's invitation 
> > to join.
> >
> > Congratulations and welcome, Mike!
> >
> > --
> > Anshum Gupta
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
-
Noble Paul

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

Re: [VOTE] Release Lucene/Solr 8.6.1 RC1

[Noble Paul]

success SUCCESS! [1:03:21.786536]
Ubuntu 20.04 LTS


On Fri, Jul 31, 2020 at 7:34 AM Houston Putman  wrote:
>
> Due to the weekend the vote will be open until 2020-08-03 22:00 UTC. That's 
> 96 hours, and two business days.
>
> I can leave the vote open for longer if people want an additional business 
> day, but will end it on Monday otherwise.
>
> - Houston
>
>
>
> On Thu, Jul 30, 2020 at 5:07 PM Houston Putman  
> wrote:
>>
>> Please vote for release candidate 1 for Lucene/Solr 8.6.1
>>
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC1-reva32a3ac4e43f629df71e5ae30a3330be94b095f2
>>
>> 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.1-RC1-reva32a3ac4e43f629df71e5ae30a3330be94b095f2
>>
>> The vote will be open for at least 72 hours i.e. until 2020-08-02 22:00 UTC.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1



-- 
-
Noble Paul

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

Re: 8.6.1 Release

[Noble Paul]

It's OK,
It can wait until 8.7

On Fri, Jul 31, 2020 at 1:02 AM Houston Putman  wrote:
>
> I started the process last night. Is there a reason why you want this to make 
> it into 8.6.1 and not 8.7?
>
> - Houston
>
> On Thu, Jul 30, 2020 at 8:13 AM Noble Paul  wrote:
>>
>> Can I cherry-pick SOLR-14634: Limit the HTTP security headers to
>> "/solr" end point ?
>>
>> if the build is not already made?
>>
>> On Thu, Jul 30, 2020 at 4:14 AM David Smiley  wrote:
>> >
>> > I have a PR up: https://github.com/apache/lucene-solr/pull/1706 reviews 
>> > welcome; I won't merge to a release branch without one.
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley
>> >
>> >
>> > On Wed, Jul 29, 2020 at 10:43 AM Houston Putman  
>> > wrote:
>> >>
>> >> Thanks Jan and David.
>> >>
>> >> I think that's the last issue. So after you commit it I'll begin the 
>> >> release process.
>> >>
>> >> - Houston
>> >>
>> >> On Wed, Jul 29, 2020 at 10:29 AM David Smiley  wrote:
>> >>>
>> >>> https://issues.apache.org/jira/browse/LUCENE-9443
>> >>> This regression on the highlighter is trivial; just revert a commit to a 
>> >>> file and maybe suppress a warning.  I'll get this into 8.6.1 today.
>> >>>
>> >>> ~ David Smiley
>> >>> Apache Lucene/Solr Search Developer
>> >>> http://www.linkedin.com/in/davidwsmiley
>> >>>
>> >>>
>> >>> On Wed, Jul 29, 2020 at 6:04 AM Jan Høydahl  
>> >>> wrote:
>> >>>>
>> >>>> Merged!
>> >>>>
>> >>>> 28. jul. 2020 kl. 23:22 skrev Houston Putman :
>> >>>>
>> >>>> +1 to the change.
>> >>>>
>> >>>> I think the last issue remaining is Jan's Zookeeper client port fix. 
>> >>>> After that is merged I will start with the release.
>> >>>>
>> >>>> - Houston
>> >>>>
>> >>>> On Tue, Jul 28, 2020 at 5:12 PM Gus Heck  wrote:
>> >>>>>
>> >>>>> Ishan suggested I also supply the slight clarification to ref guide 
>> >>>>> build docs to 8_6 https://github.com/apache/lucene-solr/pull/1704 if 
>> >>>>> you want to include it.
>> >>>>>
>> >>>>> On Mon, Jul 27, 2020 at 9:25 PM Houston Putman 
>> >>>>>  wrote:
>> >>>>>>
>> >>>>>> Both of those look good to include!
>> >>>>>>
>> >>>>>> Ill keep an eye out for when they get resolved.
>> >>>>>>
>> >>>>>> - Houston
>> >>>>>>
>> >>>>>> On Mon, Jul 27, 2020 at 9:16 PM Ishan Chattopadhyaya 
>> >>>>>>  wrote:
>> >>>>>>>
>> >>>>>>> Can we include SOLR-11611 for 8.6.1? The patch should be simple to 
>> >>>>>>> test out (with someone having a Windows machine and VM) and seems 
>> >>>>>>> like a good one to fix.
>> >>>>>>> I marked it as a 8.6.1 bug, but please feel free to unmark it (or I 
>> >>>>>>> can do so, if you tell me to) if you feel otherwise.
>> >>>>>>>
>> >>>>>>> On Tue, Jul 28, 2020 at 5:40 AM Jan Høydahl  
>> >>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>> Came back from holiday and fixed 
>> >>>>>>>> https://issues.apache.org/jira/browse/SOLR-14671
>> >>>>>>>> Can we include it in 8.6.1?
>> >>>>>>>>
>> >>>>>>>> Jan
>> >>>>>>>>
>> >>>>>>>> 27. jul. 2020 kl. 22:56 skrev Houston Putman 
>> >>>>>>>> :
>> >>>>>>>>
>> >>>>>>>> Added upgrade notes for the autoscaling stuff.
>> >>>>>>>>
>> >>>>>>>> Will begin the release process tomorrow when my GPG Keys will be 
>> >>>>>>>> refreshed in all of the apache

Re: Welcome Tomoko Uchida to the PMC

[Noble Paul]

Congratulations and welcome, Tomoko!

On Mon, Jul 27, 2020 at 12:09 PM Tomoko Uchida
 wrote:
>
> > How would you prefer to be called?
>
> Call me Tomoko, or Uchida-san (Japanese style), either way you like!
>
> > Omedetou Uchida-san! :-)
>
> Arigatou!
>
> Tomoko
>
>
> 2020年7月27日(月) 10:38 Ishan Chattopadhyaya :
>>
>> Omedetou Uchida-san! :-)
>>
>> On Mon, Jul 27, 2020 at 7:02 AM Christian Moen  wrote:
>>>
>>> Congrats, Uchida-san.
>>>
>>> How would you prefer to be called?
>>>
>>> Thanks.
>>>
>>>
>>> On Mon, Jul 27, 2020 at 9:41 AM Tomoko Uchida 
>>>  wrote:
>>>>
>>>> Thank you all,
>>>>
>>>> Martin, let me just correct this...
>>>>
>>>> > ウェルコム  ウーキーダー
>>>>
>>>> ウェルカム　ウチダ　// there's no PROLONGED SOUND MARK! :)
>>>>
>>>> And if you're interested, here is my name written in four notations:
>>>> Uchida Tomoko (in Roma-ji)
>>>> ウチダ トモコ (in Katakana)
>>>> うちだ ともこ (in Hiragana)
>>>> 打田 智子 (in Kanji)
>>>>
>>>>
>>>>
>>>> 2020年7月27日(月) 4:28 Dawid Weiss :
>>>>>
>>>>> Congratulations and welcome, Tomoko!
>>>>>
>>>>>
>>>>> Dawid
>>>>>
>>>>> On Fri, Jul 24, 2020 at 7:03 PM Christine Poerschke (BLOOMBERG/
>>>>> LONDON)  wrote:
>>>>> >
>>>>> > Welcome Tomoko!
>>>>> >
>>>>> > From: dev@lucene.apache.org At: 07/04/20 08:27:28
>>>>> > To: dev@lucene.apache.org
>>>>> > Subject: Re: Welcome Tomoko Uchida to the PMC
>>>>> >
>>>>> > Thank you Adrien and the whole PMCs, it's a great honour for me!
>>>>> >
>>>>> > Tomoko
>>>>> >
>>>>> >
>>>>> > 2020年7月4日(土) 15:28 Christian Moen :
>>>>> >>
>>>>> >> Congrats, Tomoko-san!
>>>>> >>
>>>>> >> On Sat, Jul 4, 2020 at 15:26 Adrien Grand  wrote:
>>>>> >>>
>>>>> >>> I am pleased to announce that Tomoko Uchida has accepted the PMC's 
>>>>> >>> invitation to join.
>>>>> >>>
>>>>> >>> Welcome Tomoko!
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> Adrien
>>>>> >
>>>>> >
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>>


-- 
-
Noble Paul

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

Re: Welcome Michael Sokolov to the PMC

[Noble Paul]

Congratulations and welcome, Mike!

On Sat, Jul 25, 2020 at 3:07 AM Christine Poerschke (BLOOMBERG/
LONDON)  wrote:
>
> Welcome Mike!
>
> From: dev@lucene.apache.org At: 07/03/20 13:15:05
> To: dev@lucene.apache.org
> Subject: Re: Welcome Michael Sokolov to the PMC
>
> Thanks Adrien, and to the whole PMC
>
> Mike
>
> On Fri, Jul 3, 2020, 7:57 AM Adrien Grand  wrote:
>>
>> I am pleased to announce that Michael Sokolov has accepted the PMC's 
>> invitation to join.
>>
>> Welcome Michael!
>>
>> --
>> Adrien
>
>


-- 
-
Noble Paul

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

Re: 8.6.1 Release

[Noble Paul]

gt;>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> > If we agree that this warrants a patch release, I volunteer 
>>>>>>>>>>>>>>>>> > to do the release.
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> > I do think a patch release is reasonable even if users have 
>>>>>>>>>>>>>>>>> > to take an action when upgrading from 8.6.0. I imagine most 
>>>>>>>>>>>>>>>>> > users haven't upgraded to 8.6.0 yet, so if we make the 
>>>>>>>>>>>>>>>>> > patch now we will make life easier for everyone that 
>>>>>>>>>>>>>>>>> > upgrades between now and when 8.7 is released.
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> > On Wed, Jul 22, 2020 at 12:50 PM Atri Sharma 
>>>>>>>>>>>>>>>>> >  wrote:
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >> Ignore this, I misread your email.
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >> On Wed, Jul 22, 2020 at 9:11 PM Atri Sharma 
>>>>>>>>>>>>>>>>> >>  wrote:
>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>> >> > Should we not revert the change so that users upgrading 
>>>>>>>>>>>>>>>>> >> > from 8.6 to
>>>>>>>>>>>>>>>>> >> > 8.6.1 get the earlier default policy?
>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>> >> > On Wed, Jul 22, 2020 at 9:09 PM Houston Putman 
>>>>>>>>>>>>>>>>> >> >  wrote:
>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>> >> > > +1
>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>> >> > > Question about the change. Since this patch added a 
>>>>>>>>>>>>>>>>> >> > > default autoscaling policy, if users upgrade to 8.6 
>>>>>>>>>>>>>>>>> >> > > and then 8.6.1, does the default autoscaling policy 
>>>>>>>>>>>>>>>>> >> > > stay once they have upgraded? If so we probably want 
>>>>>>>>>>>>>>>>> >> > > to include instructions in the release notes on how to 
>>>>>>>>>>>>>>>>> >> > > fix this issue once upgrading.
>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>> >> > > - Houston
>>>>>>>>>>>>>>>>> >> > >
>>>>>>>>>>>>>>>>> >> > > On Wed, Jul 22, 2020 at 1:53 AM Ishan Chattopadhyaya 
>>>>>>>>>>>>>>>>> >> > >  wrote:
>>>>>>>>>>>>>>>>> >> > >>
>>>>>>>>>>>>>>>>> >> > >> Hi,
>>>>>>>>>>>>>>>>> >> > >> There was a performance regression identified in 
>>>>>>>>>>>>>>>>> >> > >> 8.6.0 release due to SOLR-12845. I think it is 
>>>>>>>>>>>>>>>>> >> > >> serious enough to warrant an immediate bug fix 
>>>>>>>>>>>>>>>>> >> > >> release.
>>>>>>>>>>>>>>>>> >> > >>
>>>>>>>>>>>>>>>>> >> > >> I propose a 8.6.1 release. Unfortunately, I'll be 
>>>>>>>>>>>>>>>>> >> > >> unable to volunteer for this release owning to some 
>>>>>>>>>>>>>>>>> >> > >> other commitments, however Andrzej mentioned in Slack 
>>>>>>>>>>>>>>>>> >> > >> that he might be able to volunteer for this post 27th.
>>>>>>>>>>>>>>>>> >> > >>
>>>>>>>>>>>>>>>>> >> > >> Are there any thoughts/concerns regarding this?
>>>>>>>>>>>>>>>>> >> > >> Regards,
>>>>>>>>>>>>>>>>> >> > >> Ishan
>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>> >> > --
>>>>>>>>>>>>>>>>> >> > Regards,
>>>>>>>>>>>>>>>>> >> >
>>>>>>>>>>>>>>>>> >> > Atri
>>>>>>>>>>>>>>>>> >> > Apache Concerted
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >> --
>>>>>>>>>>>>>>>>> >> Regards,
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >> Atri
>>>>>>>>>>>>>>>>> >> Apache Concerted
>>>>>>>>>>>>>>>>> >>
>>>>>>>>>>>>>>>>> >> -
>>>>>>>>>>>>>>>>> >> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> http://www.needhamsoftware.com (work)
>>>>>>>>>>>> http://www.the111shift.com (play)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> http://www.needhamsoftware.com (work)
>>>>>>>>>> http://www.the111shift.com (play)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://www.needhamsoftware.com (work)
>>>>>>>>> http://www.the111shift.com (play)
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.needhamsoftware.com (work)
>>>>> http://www.the111shift.com (play)
>>>>
>>>>


-- 
-
Noble Paul

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

Re: [ANNOUNCE] Apache Solr 8.6.0 released

[Noble Paul]

ude powerful
> > > > full-text
> > > > > > search, hit highlighting, faceted search, dynamic clustering,
> > database
> > > > > > integration, rich document handling, and geospatial search. Solr is
> > > > highly
> > > > > > scalable, providing fault tolerant distributed search and
> > indexing, and
> > > > > > powers the search and navigation features of many of the world's
> > > > largest
> > > > > > internet sites.
> > > > > >
> > > > > >
> > > > > > Solr 8.6.0 is available for immediate download at:
> > > > > >
> > > > > >
> > > > > >   <https://lucene.apache.org/solr/downloads.html>
> > > > > >
> > > > > >
> > > > > > ### Solr 8.6.0 Release Highlights:
> > > > > >
> > > > > >
> > > > > >  * Cross-Collection Join Queries: Join queries can now work
> > > > > > cross-collection, even when shared or when spanning nodes.
> > > > > >
> > > > > >  * Search: Performance improvement for some types of queries when
> > exact
> > > > > > hit count isn't needed by using BlockMax WAND algorithm.
> > > > > >
> > > > > >  * Streaming Expression: Percentiles and standard deviation
> > > > aggregations
> > > > > > added to stats, facet and time series.  Streaming expressions
> > added to
> > > > > > /export handler.  Drill Streaming Expression for efficient and
> > accurate
> > > > > > high cardinality aggregation.
> > > > > >
> > > > > >  * Package manager: Support for cluster (CoreContainer) level
> > plugins.
> > > > > >
> > > > > >  * Health Check: HealthCheckHandler can now require that all cores
> > are
> > > > > > healthy before returning OK.
> > > > > >
> > > > > >  * Zookeeper read API: A read API at /api/cluster/zk/* to fetch
> > raw ZK
> > > > > > data and view contents of a ZK directory.
> > > > > >
> > > > > >  * Admin UI: New panel with security info in admin UI's dashboard.
> > > > > >
> > > > > >  * Query DSL: Support for {param:ref} and {bool: {excludeTags:""}}
> > > > > >
> > > > > >  * Ref Guide: Major redesign of Solr's documentation.
> > > > > >
> > > > > >
> > > > > > Please read CHANGES.txt for a full list of new features and
> > changes:
> > > > > >
> > > > > >
> > > > > >   <https://lucene.apache.org/solr/8_6_0/changes/Changes.html>
> > > > > >
> > > > > >
> > > > > > Solr 8.6.0 also includes features, optimizations  and bugfixes in
> > the
> > > > > > corresponding Apache Lucene release:
> > > > > >
> > > > > >
> > > > > >   <https://lucene.apache.org/core/8_6_0/changes/Changes.html>
> > > > > >
> > > > > >
> > > > > > Note: The Apache Software Foundation uses an extensive mirroring
> > > > network
> > > > > > for
> > > > > >
> > > > > > distributing releases. It is possible that the mirror you are
> > using may
> > > > > > not have
> > > > > >
> > > > > > replicated the release yet. If that is the case, please try another
> > > > mirror.
> > > > > >
> > > > > > This also applies to Maven access.
> > > > > >
> > > >
> >



-- 
-
Noble Paul

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

Re: Gradle cutover timing

[Noble Paul]

+1

On Fri, Jul 17, 2020 at 1:32 AM Uwe Schindler  wrote:
>
> Are we done with full artifact build and deployment on Maven?
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: David Smiley 
> Sent: Thursday, July 16, 2020 5:19 PM
> To: Solr/Lucene Dev 
> Subject: Re: Gradle cutover timing
>
>
>
> +1
>
>
> ~ David
>
>
>
>
>
> On Thu, Jul 16, 2020 at 9:30 AM Erick Erickson  
> wrote:
>
> Solr is changing very rapidly, from the reference impl to moving DIH, 
> ExtractingRequestHandler, et. al. to packages etc. This is going to make 
> maintaining both the Gradle and Ant builds for trunk increasingly complicated.
>
> Maintaining both has always been an interim solution until the Gradle build 
> settles out and it’s pretty well settled. No doubt the first time we make a 
> release from Gradle only there’ll be some things that bubble up, we can deal 
> with those as necessary.
>
> So I propose that it’s time to remove Ant build support from trunk.
>
> Comments?
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org



-- 
-
Noble Paul

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

Re: [Data Import Handler] proposal: make FileListEntityProcessor streaming

[Noble Paul]

The project will go live anytime from now. It means a user can use it
on any release newer than Solr 8.6 . Even if you provide a fix in the
current 8.x branch, it will not be available before Solr 8.7 release.
OTOH, DIH plugin will have bug fix releases independent of Solr
releases and every user will be able to upgrade their plugin without
upgrading their Solr.

So, please give PRs to both the external plugin and to Solr

On Fri, Jul 10, 2020 at 2:58 AM Marco Bolis  wrote:
>
> I see.
> How is the transition going to work Eric?
> I understand the community supported project is going to take over from Solr 
> 9.0, is that correct? Is DIH code on the Lucene side going to freeze soon?
> Thank you for the heads up.
>
> Regards,
> Marco
>
>
> Il giorno gio 9 lug 2020 alle ore 18:49 Eric Pugh 
>  ha scritto:
>>
>> Another thought….
>>
>> Since DIH is moving to a community supported 
>> (https://github.com/rohitbemax/dataimporthandler) plugin for Solr, maybe you 
>> want to focus your efforts on that project?
>>
>> One of the reasons for moving DIH into it’s own plugin it to open the door 
>> to more contributions from the community, and this is a good example!
>>
>>
>>
>> On Jul 9, 2020, at 12:09 PM, Erick Erickson  wrote:
>>
>> If you’ve created a JIRA login, there should be a button on the JIRA about 
>> “attach files”. It’s perfectly OK to attach a diff file to the JIRA. It’s 
>> preferred to just label it SOLR-#.patch. Successive versions of the 
>> patch should have the exact same name, the old ones are grayed out making it 
>> easy to know what the most recent one is without losing the old versions. No 
>> big deal though.
>>
>> If you’re familiar with GIT and have your own fork somewhere, it’s just the 
>> usual process of creating a Pull Request from your GitHub repo. If you 
>> mention the JIRA when you create the PR by starting the title with 
>> “SOLR-#: any comments you want to make”, it’ll automagically be linked 
>> to the JIRA you created. I’ve personally found this a bit confusing because 
>> the title you edit is not the first screen when you hit the “create PR” 
>> button. If the automagic linking doesn’t work, just paste a link to the PR 
>> in the comments.
>>
>> Don’t stress over it, if making a PR is bothersome, just attach a diff file. 
>> Either one is fine. Code reviews are easier with a PR, but depending on the 
>> size of the patch the utility of easy reviews may be only marginally 
>> beneficial.
>>
>> Best,
>> Erick
>>
>> On Jul 9, 2020, at 11:23 AM, Marco Bolis  wrote:
>>
>> Thanks for the answers.
>>
>> Excuse me, I'm new to this: how am I supposed to attach the patch / PR to 
>> the issue?
>> Is it ok to add a diff as attachment?
>> Should I open the PR and link to it from the issue?
>>
>> Thank you very much, regards,
>> Marco
>>
>> Il giorno gio 9 lug 2020 alle ore 17:06 Erick Erickson 
>>  ha scritto:
>> Marco:
>>
>> Thanks for volunteering your fix!
>>
>> The best way is to raise a JIRA, see: 
>> https://cwiki.apache.org/confluence/display/solr/HowToContribute#HowToContribute-JIRAtips(ourissue/bugtracker)
>>  and attach a patch or pull request. From there we can discuss/give 
>> feedback/add to the repo, etc.
>>
>> Best,
>> Erick
>>
>> On Jul 9, 2020, at 9:56 AM, Marco Bolis  wrote:
>>
>> Hello,
>>
>> I just wrote a patch to make FileListEntityProcessor work by streaming, 
>> using Java 8 Stream and NIO2, instead of buffering the entire file list in 
>> memory.
>> I had to do it because I had a very large list of files (upwards of 1M) and 
>> kept going OOM.
>>
>> I wish I could contribute this patch, if it is deemed useful.
>>
>> Regards,
>> Marco
>>
>>
>>
>> -
>> 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
>>
>>
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
>> http://www.opensourceconnections.com | My Free/Busy
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> This e-mail and all contents, including attachments, is considered to be 
>> Company Confidential unless explicitly stated otherwise, regardless of 
>> whether attachments are marked as such.
>>


-- 
-
Noble Paul

-
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.0 RC1

[Noble Paul]

SUCCESS! [1:07:35.754307]

with Java 8

+1

On Wed, Jul 8, 2020 at 9:20 PM Noble Paul  wrote:
>
> it worked Uwe.
> But there was a test failure
>   [junit4] Tests with failures [seed: D6C8B0CC504808B4]:
>[junit4]   -
> org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore
> (suite)
> I believe it's just an isolated case of failure
>
> On Wed, Jul 8, 2020 at 7:49 PM Uwe Schindler  wrote:
> >
> > Hi,
> >
> >
> >
> > Policeman Jenkins Smoke tester was happy with your release (I tested 
> > already yesterday in the evening after your svn commit):
> >
> > https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/33/console
> >
> >
> >
> > SUCCESS! [1:23:18.912909]
> >
> >
> >
> > (Java 8 and Java 9)
> >
> >
> >
> > I will do some further checks by hand later today – as this is your first 
> > release. Will give my +1 later.
> >
> >
> >
> > Uwe
> >
> >
> >
> > -
> >
> > Uwe Schindler
> >
> > Achterdiek 19, D-28357 Bremen
> >
> > https://www.thetaphi.de
> >
> > eMail: u...@thetaphi.de
> >
> >
> >
> > From: Bruno Roustant 
> > Sent: Wednesday, July 8, 2020 10:56 AM
> > To: Solr/Lucene Dev 
> > Subject: [VOTE] Release Lucene/Solr 8.6.0 RC1
> >
> >
> >
> > Please vote for release candidate 1 for Lucene/Solr 8.6.0
> >
> > The artifacts can be downloaded from:
> >
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc
> >
> > 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.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc
> >
> > The vote will be open for at least 72 hours i.e. until 2020-07-11 09:00 UTC.
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > Here is my +1
>
>
>
> --
> -
> Noble Paul



-- 
-
Noble Paul

-
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.0 RC1

[Noble Paul]

it worked Uwe.
But there was a test failure
  [junit4] Tests with failures [seed: D6C8B0CC504808B4]:
   [junit4]   -
org.apache.solr.cloud.api.collections.TestHdfsCloudBackupRestore
(suite)
I believe it's just an isolated case of failure

On Wed, Jul 8, 2020 at 7:49 PM Uwe Schindler  wrote:
>
> Hi,
>
>
>
> Policeman Jenkins Smoke tester was happy with your release (I tested already 
> yesterday in the evening after your svn commit):
>
> https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/33/console
>
>
>
> SUCCESS! [1:23:18.912909]
>
>
>
> (Java 8 and Java 9)
>
>
>
> I will do some further checks by hand later today – as this is your first 
> release. Will give my +1 later.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Bruno Roustant 
> Sent: Wednesday, July 8, 2020 10:56 AM
> To: Solr/Lucene Dev 
> Subject: [VOTE] Release Lucene/Solr 8.6.0 RC1
>
>
>
> Please vote for release candidate 1 for Lucene/Solr 8.6.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc
>
> 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.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc
>
> The vote will be open for at least 72 hours i.e. until 2020-07-11 09:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1



-- 
-
Noble Paul

-
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.0 RC1

[Noble Paul]

Is this just me ?

python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc
dev-tools/scripts/smokeTestRelease.py:1320: SyntaxWarning: "is not"
with a literal. Did you mean "!="?
  if p.returncode is not 0:
Revision: a9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc

On Wed, Jul 8, 2020 at 6:56 PM Bruno Roustant  wrote:
>
> Please vote for release candidate 1 for Lucene/Solr 8.6.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc
>
> 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.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc
>
> The vote will be open for at least 72 hours i.e. until 2020-07-11 09:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1



-- 
-
Noble Paul

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

Re: 8.6 release

[Noble Paul]

It was not urgent. I think we are too late for any new addition. I
shall add it to the next release

On Tue, Jul 7, 2020 at 11:12 PM Noble Paul  wrote:
>
> I would like to commit
> https://issues.apache.org/jira/browse/SOLR-14634 as well please
>
> On Tue, Jul 7, 2020 at 6:04 PM Bruno Roustant  
> wrote:
> >
> > Thank you for taking care of the unresolved issues. Now it's clean and I'll 
> > start the RC process today (with the help of the Great Release Wizard).
> >
> > For those who want to have a look at the draft release notes (or edit them):
> > Lucene: 
> > https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=158865929=e7da54c5-8e1c-4228-b9f7-ff03ab882080=shareui=1594107478794
> > Solr: 
> > https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=158865919=9cd1341c-bf4d-4714-b71b-08a685053f4d=shareui=1594039624215
> >
> > Le lun. 6 juil. 2020 à 20:58, Eric Pugh  a 
> > écrit :
> >>
> >> I just resolved SOLR-14422.
> >>
> >> On Jul 6, 2020, at 1:36 PM, Tomás Fernández Löbbe  
> >> wrote:
> >>
> >> Just resolved SOLR-14590.
> >>
> >> On Mon, Jul 6, 2020 at 4:22 AM Ishan Chattopadhyaya 
> >>  wrote:
> >>>
> >>> I'll take a look today, Bruno. Thanks.
> >>>
> >>> On Mon, 6 Jul, 2020, 4:32 pm Bruno Roustant,  
> >>> wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> 8.6 RC is planned tomorrow but there are still 9 Jira issues unresolved 
> >>>> for 8.6 (+ private ones?)
> >>>>
> >>>> Please review and update their status.
> >>>>
> >>>> 3 blockers
> >>>> SOLR-14599 Introduce cluster level plugins through packages
> >>>> SOLR-14593 Package store API to disable file upload over HTTP
> >>>> SOLR-14580 CloudSolrClient cannot be initialized using 'zkHosts' builder
> >>>>
> >>>> Other
> >>>> SOLR-14590 Add support for FeatureField in Solr
> >>>> SOLR-14516 NPE during Realtime GET
> >>>> SOLR-14422 Solr 8.5 Admin UI shows Angular placeholders on first load / 
> >>>> refresh
> >>>> SOLR-14398 package store PUT should be idempotent
> >>>> SOLR-14311 Shared schema should not have access to core level classes
> >>>> LUCENE-9356 Add tests for corruptions caused by byte flips
> >>>>
> >>>> Le dim. 5 juil. 2020 à 08:10, David Smiley  a 
> >>>> écrit :
> >>>>>
> >>>>> Pertaining to the highlighter performance regression: 
> >>>>> https://issues.apache.org/jira/browse/SOLR-14628
> >>>>> It's a simple change in a default setting, that is furthermore 
> >>>>> consistent with how the behavior was prior to Solr 8.5
> >>>>>
> >>>>> I'm hoping this can make it into the release?  See the PR.
> >>>>>
> >>>>> ~ David
> >>>>>
> >>>>>
> >>>>> On Wed, Jun 24, 2020 at 3:05 PM David Smiley  
> >>>>> wrote:
> >>>>>>
> >>>>>> Thanks starting this discussion, Cassandra.
> >>>>>>
> >>>>>> I reviewed the issues I was involved with and I don't quite see 
> >>>>>> something worth noting.
> >>>>>>
> >>>>>> I plan to add a note about a change in defaults within 
> >>>>>> UnifiedHighlighter that could be a significant perf regression.  This 
> >>>>>> wasn't introduced in 8.6 but introduced in 8.5 and it's significant 
> >>>>>> enough to bring attention to.  I could add it in 8.5's section but 
> >>>>>> then add a short pointer to it in 8.6.
> >>>>>>
> >>>>>> ~ David
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Jun 24, 2020 at 2:52 PM Cassandra Targett 
> >>>>>>  wrote:
> >>>>>>>
> >>>>>>> I started looking at the Ref Guide for 8.6 to get it ready, and 
> >>>>>>> notice there are no Upgrade Notes in `solr-upgrade-notes.adoc` for 
> >>>>>>> 8.6. Is it really true that none are needed at all?
> >>>>>>>
> >>>>>>> I’ll add what I usually do about new features/changes that maybe 
> >>>>>>> wouldn’t normal

Re: 8.6 release

[Noble Paul]

;>>>
>>>>>>>> The release wizard python script should be sufficient for everything. 
>>>>>>>> If you run into any issues with it, let me know, I used it for 8.5.2 
>>>>>>>> and think I understand it pretty well.
>>>>>>>>
>>>>>>>> On Tue, Jun 16, 2020 at 8:31 AM Bruno Roustant 
>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It’s been a while since we released Lucene/Solr 8.5.
>>>>>>>>> I’d like to volunteer to be a release manager for an 8.6 release. If 
>>>>>>>>> there's agreement, then I plan to cut the release branch two weeks 
>>>>>>>>> today, on June 30th, and then to build the first RC two days later.
>>>>>>>>>
>>>>>>>>> This will be my first time as release manager so I'll probably need 
>>>>>>>>> some guidance. Currently I have two resource links on this subject:
>>>>>>>>> https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo
>>>>>>>>> https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#releasewizardpy
>>>>>>>>> If you have more, please share with me.
>>>>>>>>>
>>>>>>>>> Bruno
>>
>>
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
>> http://www.opensourceconnections.com | My Free/Busy
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> This e-mail and all contents, including attachments, is considered to be 
>> Company Confidential unless explicitly stated otherwise, regardless of 
>> whether attachments are marked as such.
>>


-- 
-
Noble Paul

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

Re: RoadMap?

[Noble Paul]

I think the logical thing to do today is completely rip out all
autoscaling code as it exists today.
Let's deprecate that in 8.7 and build something for "assign-strategy".
Austoscaling , if required, should not be a part of Solr



On Fri, Jul 3, 2020 at 5:48 PM Jan Høydahl  wrote:
>
> +1
>
> Why don’t we make a Roadmap wiki page as Cassandra suggests, and indicate 
> what major things needs to happen when.
> Perhaps if we can get the Solr TLP and git-split ball rolling as a pre-9.0 
> task, then perhaps 8.8 could be the last joint release (6.6, 7.7, 8.8 hehe)?
> That would enable Lucene to ship 9.0 without waiting for a ton of 
> alpha-quality Solr features, and Solr could have its own Roadmap wiki.
>
> Jan
>
> 3. jul. 2020 kl. 09:19 skrev Dawid Weiss :
>
>
>> I totally expect some things to bubble up when we try to release with 
>> Gradle, the tarball being one. I don’t think that’s a very big issue, but if 
>> you have lots of “not very big” issues they do add up.
>
>
> Adding a tarball is literally 3-5 lines of code (you add a task that builds a 
> tarball or a zip file from the outputs of solr/packaging toDir task)... The 
> bigger issue with gradle is that somebody has to step up and try to identify 
> any other issues and/or missing bits when trying to do a full release cycle.
>
> D.
>
>


-- 
-
Noble Paul

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

Re: Welcome Ilan Ginzburg as Lucene/Solr committer

[Noble Paul]

I've been to Grenoble once. It is indeed a beautiful city.


On Mon, Jun 22, 2020 at 11:45 PM Ilan Ginzburg  wrote:
>
> Thank you, merci, תודה for the trust and the welcome, Noble and everybody!
>
> I’m based in France near Grenoble, a flat city high tech hub surrounded by 
> mountains.
>
> For the past 7 years I’ve been working on Search at Salesforce. Currently 
> focusing on SolrCloud scaling.
> I also work on making Solr nodes stateless, separating compute from storage 
> to better fit Public Cloud environments (see
> Activate '18, Activate '19, SOLR-13101 WIP).
>
> Past employers include EMC/Documentum, HP Labs Palo Alto, Intel. Earlier 
> still I created the Apple 2 game Saracen (old timers here might remember?).
>
> Other activities include a lot of paragliding, cycling, hiking, drumming 
> (here during COVID) and a few stints working as a photographer.
>
> I hold a MA in business administration and a PhD in computer science 
> (parallel computing).
>
> I’m extremely happy to join the Lucene/Solr community, the future looks 
> exciting!
>
> Ilan
>
> On Mon 22 Jun 2020 at 15:22, Joel Bernstein  wrote:
>>
>> Welcome Ilan!
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>>
>> On Mon, Jun 22, 2020 at 9:11 AM Michael McCandless 
>>  wrote:
>>>
>>> Welcome Ilan!
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>>
>>> On Sun, Jun 21, 2020 at 5:44 AM Noble Paul  wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Please join me in welcoming Ilan Ginzburg as the latest Lucene/Solr 
>>>> committer.
>>>> Ilan, it's tradition for you to introduce yourself with a brief bio.
>>>>
>>>> Congratulations and Welcome!
>>>> Noble



-- 
-
Noble Paul

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

Welcome Ilan Ginzburg as Lucene/Solr committer

[Noble Paul]

Hi all,

Please join me in welcoming Ilan Ginzburg as the latest Lucene/Solr
committer.
Ilan, it's tradition for you to introduce yourself with a brief bio.

Congratulations and Welcome!
Noble