Re: Doubling down on our mistakes?

[Andrzej Białecki]

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

Re: [VOTE] Release Lucene/Solr 8.8.0 RC1

[Andrzej Białecki]

+1 (binding)

SUCCESS! [1:31:27.365392]


> On 20 Jan 2021, at 08:39, Atri Sharma  wrote:
> 
> +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
> 


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

Re: [JENKINS] Lucene » Lucene-Solr-Check-master - Build # 698 - Failure!

[Andrzej Białecki]

This is frequently failing for me too, seed 4B403C84E8713580 seems to always 
reproduce it on my local machine.

> On 3 Nov 2020, at 14:14, Dawid Weiss  wrote:
> 
> These randomized test failures reproduce for me in this test.
> 
> Dawid
> 
> On Tue, Nov 3, 2020 at 8:30 AM Apache Jenkins Server
>  wrote:
>> 
>> Build: 
>> https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Check-master/698/
>> 
>> 1 tests failed.
>> FAILED:  org.apache.solr.TestRandomDVFaceting.testRandomFaceting
>> 
>> Error Message:
>> java.lang.AssertionError: mismatch: 'LJAC'!='EKYL' @ 
>> facet_counts/facet_fields/id/[2]
>> 
>> Stack Trace:
>> java.lang.AssertionError: mismatch: 'LJAC'!='EKYL' @ 
>> facet_counts/facet_fields/id/[2]
>>at 
>> __randomizedtesting.SeedInfo.seed([B758812B355044AA:BA30A1FE60A98C15]:0)
>>at org.junit.Assert.fail(Assert.java:89)
>>at 
>> org.apache.solr.TestRandomDVFaceting.doFacetTests(TestRandomDVFaceting.java:292)
>>at 
>> org.apache.solr.TestRandomDVFaceting.doFacetTests(TestRandomDVFaceting.java:175)
>>at 
>> org.apache.solr.TestRandomDVFaceting.testRandomFaceting(TestRandomDVFaceting.java:158)
>>at 
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
>> Method)
>>at 
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>at 
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1754)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:942)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:978)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
>>at 
>> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>>at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>>at 
>> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>>at 
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>>at 
>> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>>at 
>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>>at 
>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>>at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>>at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>>at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:370)
>>at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:819)
>>at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:470)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:951)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:836)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:887)
>>at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:898)
>>at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>>at 
>> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>>at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>>at 
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>>at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>>at 
>> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
>>at 
>> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>>at 
>> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>>at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>>at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>>at 
>> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
>>at 
>> 

Re: Please set: git config --global pull.rebase true

[Andrzej Białecki]

> On 20 Oct 2020, at 09:33, Dawid Weiss  wrote:
> 
> > [...] in a public repo and may lead to bizarre conflicts and lost local 
> > work   
> 
> Just to clarify - it's hard to lose a local commit, even if somebody changes 
> the remote reference. I agree it is almost equally hard to find it once it's 
> dangling without any named branch or tag (extra knowledge of git is 
> required). Most of the time you can recover it though - looking at git reflog 
> is the first step to try.


Yes, that’s technically true … and now multiply this exercise by the number of 
devs across the globe, each with some local changes :) I went through this 
process once on an active project with a team of dozen people in different 
timezones, and it wasn’t pleasant.

—

Andrzej Białecki

Re: Please set: git config --global pull.rebase true

[Andrzej Białecki]

+100

IMHO the three greatest evils of git workflow, to be avoided at all cost, are:

* pulling without rebasing, as you explained (and then pushing the resulting 
spaghetti to the repo). Who cares that you made 10 interim local commits and 10 
reverts, and you merged from trunk a dozen times on the way before finally 
pushing your changes? Nobody is interested in this and in the resulting eyesore.

* ditto, merging feature branches with the main branches without squashing (and 
then pushing the resulting spaghetti to the repo)

* and the greatest of all evils, a forced push, which should NEVER be used on a 
public repo. IIRC it’s disabled on lucene-solr repo? I hope it still is, and it 
needs to be disabled once the Solr repo is separated. Forced push forcibly 
rewrites the history in a public repo and may lead to bizarre conflicts and 
lost local work (not to mention the revisionist aspects).

—

Andrzej Białecki

> On 19 Oct 2020, at 23:17, David Smiley  wrote:
> 
> I ask you all to do the following:
> 
> git config --global pull.rebase true
> 
> Perhaps you have already set it as such (this retrieves the current setting, 
> possibly a default):
> 
>  git config pull.rebase 
>  -> true
>  
> *What*:  As the setting implies, this has to do with what happens on a 
> "pull", but in practice it shows up in a typical workflow on a "push" because 
> some "pushes" need to "pull".  When pushes do a pull, it's because the remote 
> branch (e.g. master or branch_8x) has advanced beyond the point that you had 
> committed from.  Git will either (A) generate a merge commit between the 
> latest head and your commit (the default behavior) generating a bifurcation 
> in the history, or (b) it will rebase your commit(s) on top of the new head 
> (what I propose) thus producing a linear history.  In either case, there may 
> be a conflict which you'll have to resolve.
> 
> *Why?*:  To make our history easier to understand as seen via "git log" and 
> in our IDEs and online.  I don't know about you all, but I find those visual 
> branch bifurcations to be a distracting annoyance that is more obfuscating 
> than linear history.  I don't think that merge commits are altogether bad, 
> I'd just prefer that they happen in exceptional circumstances instead of 
> common ones.
> 
> *Why not?:* In full disclosure, I'm aware this is one of those debates like 
> tabs vs spaces.  Some will argue that the merge commit is a better reflection 
> of the reality of what happened.  While I agree, it has an obfuscation cost 
> on everyone looking at the history.  I think it _sometimes_ makes sense for a 
> merge commit, like maybe if the branch was a long lived big feature.  The 
> setting I propose does not prevent someone from deliberately choosing a merge 
> commit when they consciously want one, it's aimed at the common scenario 
> during a push.
> 
> If I can get broad agreement here, I can update 
> https://cwiki.apache.org/confluence/display/LUCENE/Commit+Process+Guidelines#CommitProcessGuidelines-LinearHistoryinGit
>  
> <https://cwiki.apache.org/confluence/display/LUCENE/Commit+Process+Guidelines#CommitProcessGuidelines-LinearHistoryinGit>
>  to recommend the setting above and remove the [PENDING DISCUSSION].
> 
> Thankfully, this appears to occur only rarely.  It happened today on 
> branch_8x (I'm looking at you Eric Pugh :-) and a worse one there September 
> 29th by Noble.  I say "worse" because the branch bifurcation was 2 weeks long 
> for that one.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> <http://www.linkedin.com/in/davidwsmiley>

Re: 8.7 Release

[Andrzej Białecki]

Thanks, this is now merged. There’s another one that I just filed: SOLR-14948. 
This is a bug in the autoscaling code that prevents using the maxOps override 
in ComputePlanAction. It’s a straightforward change (wrong numeric type was 
cast) so I’d like to merge this too.

> On 19 Oct 2020, at 11:59, Atri Sharma  wrote:
> 
> ab,
> 
> Please proceed to commit to 8x and 8_.
> 
> On Mon, Oct 19, 2020 at 3:24 PM Andrzej Białecki  wrote:
>> 
>> Atri,
>> 
>> I’d like to add a notice in 8.7.0 (no code change) to CHANGES.txt about the 
>> deprecation of the spinning disk detection (LUCENE-9576 and SOLR-14930).
>> 
>> 
>> On 19 Oct 2020, at 05:55, David Smiley  wrote:
>> 
>> Given how recent branch_8_7 was cut, I don't think a RC should be released 
>> Monday.  At least one extra day would be prudent.  Just my 2-cents.
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>> 
>> 
>> On Sun, Oct 18, 2020 at 4:11 PM Adrien Grand  wrote:
>>> 
>>> 1. This is failing 8.7 builds, e.g. 
>>> https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.7/3/console, 
>>> so yes we should backport to 8.7.
>>> By the way I don't understand why you created a branch_8_x branch in 
>>> addition to branch_8x, was it a mistake? The release wizard doesn't seem to 
>>> be recommending something like that?
>>> 
>>> 2. Yes this is actually the point of cutting a branch, this helps reduce 
>>> chances of introducing blockers while we're working on addressing the 
>>> existing blockers.
>>> 
>>> On Sun, Oct 18, 2020 at 9:50 PM Atri Sharma  wrote:
>>>> 
>>>> BTw, guidance needed:
>>>> 
>>>> 1. The doc fixes I need to do for this, should I be backporting them to 
>>>> branch_8_7, or apply them to branch_8_x and cut a new branch?
>>>> 
>>>> 2. I still see blocker issues on 8.7 (thanks Ishan!) — is it valid to be 
>>>> cutting a branch before those are resolved?
>>>> 
>>>> Atri
>>>> 
>>>> On Mon, 19 Oct 2020 at 01:14, Atri Sharma  wrote:
>>>>> 
>>>>> Let me take a look tomorrow morning — must be something I broke in the 
>>>>> cherry pick.
>>>>> 
>>>>> On Mon, 19 Oct 2020 at 00:58, David Smiley  wrote:
>>>>>> 
>>>>>> I don't know.  I searched for "missing description: 
>>>>>> org.apache.solr.util.circuitbreaker" in my email (covering our builds), 
>>>>>> and this started happening October 16th (2 days ago) on 8.x (not master).
>>>>>> 
>>>>>> ~ David Smiley
>>>>>> Apache Lucene/Solr Search Developer
>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>> 
>>>>>> 
>>>>>> On Sun, Oct 18, 2020 at 2:34 PM Atri Sharma  wrote:
>>>>>>> 
>>>>>>> Surprisingly it doesn’t fail for me? Local caching?
>>>>>>> 
>>>>>>> On Sun, 18 Oct 2020 at 23:08, David Smiley  wrote:
>>>>>>>> 
>>>>>>>> BTW on branch_8x, I see that "ant precommit" fails:
>>>>>>>> 
>>>>>>>> -documentation-lint:
>>>>>>>>[jtidy] Checking for broken html (such as invalid tags)...
>>>>>>>>   [delete] Deleting directory 
>>>>>>>> /Users/dsmiley/DevSearch/lucene-solr_8x/lucene/build/jtidy_tmp
>>>>>>>> [echo] Checking for broken links...
>>>>>>>> [exec]
>>>>>>>> [exec] Crawl/parse...
>>>>>>>> [exec]
>>>>>>>> [exec] Verify...
>>>>>>>> [echo] Checking for malformed docs...
>>>>>>>> [exec]
>>>>>>>> [exec] 
>>>>>>>> /Users/dsmiley/DevSearch/lucene-solr_8x/solr/build/docs/solr-core/overview-summary.html
>>>>>>>> [exec]   missing description: org.apache.solr.util.circuitbreaker
>>>>>>>> [exec]
>>>>>>>> [exec] Missing javadocs were found!
>>>>>>>> 
>>>>>>>> That package is missing a "package-info.java".  It's been this way for 
>>>>>>>> a while... I wonder why it hasn't been noticed by others yet?
>>>>>>>&g

Re: 8.7 Release

[Andrzej Białecki]

Atri,

I’d like to add a notice in 8.7.0 (no code change) to CHANGES.txt about the 
deprecation of the spinning disk detection (LUCENE-9576 and SOLR-14930).


> On 19 Oct 2020, at 05:55, David Smiley  wrote:
> 
> Given how recent branch_8_7 was cut, I don't think a RC should be released 
> Monday.  At least one extra day would be prudent.  Just my 2-cents.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Sun, Oct 18, 2020 at 4:11 PM Adrien Grand  > wrote:
> 1. This is failing 8.7 builds, e.g. 
> https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.7/3/console 
> , 
> so yes we should backport to 8.7.
> By the way I don't understand why you created a branch_8_x branch in addition 
> to branch_8x, was it a mistake? The release wizard doesn't seem to be 
> recommending something like that?
> 
> 2. Yes this is actually the point of cutting a branch, this helps reduce 
> chances of introducing blockers while we're working on addressing the 
> existing blockers.
> 
> On Sun, Oct 18, 2020 at 9:50 PM Atri Sharma  > wrote:
> BTw, guidance needed:
> 
> 1. The doc fixes I need to do for this, should I be backporting them to 
> branch_8_7, or apply them to branch_8_x and cut a new branch?
> 
> 2. I still see blocker issues on 8.7 (thanks Ishan!) — is it valid to be 
> cutting a branch before those are resolved?
> 
> Atri
> 
> On Mon, 19 Oct 2020 at 01:14, Atri Sharma  > wrote:
> Let me take a look tomorrow morning — must be something I broke in the cherry 
> pick.
> 
> On Mon, 19 Oct 2020 at 00:58, David Smiley  > wrote:
> I don't know.  I searched for "missing description: 
> org.apache.solr.util.circuitbreaker" in my email (covering our builds), and 
> this started happening October 16th (2 days ago) on 8.x (not master).
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Sun, Oct 18, 2020 at 2:34 PM Atri Sharma  > wrote:
> Surprisingly it doesn’t fail for me? Local caching?
> 
> On Sun, 18 Oct 2020 at 23:08, David Smiley  > wrote:
> BTW on branch_8x, I see that "ant precommit" fails:
> 
> -documentation-lint:
> [jtidy] Checking for broken html (such as invalid tags)...
>[delete] Deleting directory 
> /Users/dsmiley/DevSearch/lucene-solr_8x/lucene/build/jtidy_tmp
>  [echo] Checking for broken links...
>  [exec] 
>  [exec] Crawl/parse...
>  [exec] 
>  [exec] Verify...
>  [echo] Checking for malformed docs...
>  [exec] 
>  [exec] 
> /Users/dsmiley/DevSearch/lucene-solr_8x/solr/build/docs/solr-core/overview-summary.html
>  [exec]   missing description: org.apache.solr.util.circuitbreaker
>  [exec] 
>  [exec] Missing javadocs were found!
> 
> That package is missing a "package-info.java".  It's been this way for a 
> while... I wonder why it hasn't been noticed by others yet?
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Tue, Oct 13, 2020 at 12:06 PM Atri Sharma  > wrote:
> I will start the first build candidate on upcoming Monday. This is my
> first release so fingers crossed :)
> 
> On Tue, Oct 13, 2020 at 7:01 PM Adrien Grand  > wrote:
> >
> > Thanks Atri. Do you know when you will start the first build candidate as 
> > well? We had been doing some planning around Ishan's initial suggestion of 
> > cutting the branch on September 20th, so as this is getting delayed I'm 
> > trying to get a sense of whether the release would likely be out in the 
> > next two weeks.
> >
> > On Tue, Oct 13, 2020 at 12:10 PM Atri Sharma  > > wrote:
> >>
> >> Adrien,
> >>
> >> Sorry for the delay in response.
> >>
> >> I will cut the branch this Friday morning (IST).
> >>
> >> Atri
> >>
> >> On Tue, 13 Oct 2020 at 05:43, Houston Putman  >> > wrote:
> >>>
> >>> Adrien, I plan on merging SOLR-14907 to master and 8x tomorrow. If you 
> >>> would mind waiting to cut 8.7 until then, I would appreciate it.
> >>>
> >>> - Houston
> >>>
> >>> On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand  >>> > wrote:
> 
>  Shall we move forward with 8.7 now that 8.6.3 is out?
> 
>  On Tue, Sep 22, 2020 at 9:32 PM Atri Sharma   > wrote:
> >
> > I plan to cut the branch on 30th September.
> >
> > On Wed, 23 Sep 2020 at 00:51, Cassandra Targett  > > wrote:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> 

Re: JIRAs with user facing changes

[Andrzej Białecki]

+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

Re: [VOTE] Release Lucene/Solr 8.6.3 RC1

[Andrzej Białecki]

+1

SUCCESS! [1:40:38.242493]


> On 4 Oct 2020, at 03:53, 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

Re: 8.6.3 Release

[Andrzej Białecki]

I’d like to fix & backport SOLR-14850 & SOLR-14835.

> On 23 Sep 2020, at 16:06, Jason Gerlowski  wrote:
> 
> Hi all,
> 
> I ran into a query-parsing bug recently in SOLR-14859 that caused
> problems for some of my usecases.  I wanted to volunteer as RM for an
> 8.6.3 to get a bugfix release out for users that aren't ready for some
> of the bigger changes in 8.7
> 
> I was thinking of cutting the branch in a week's time to give others a
> chance to backport any bug-fixes they might want included, with an RC
> to follow shortly.  Does anyone have any concerns with that plan, or
> have anything they'd like to fix or backport before an 8.6.3 goes out?
> 
> 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

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

[Andrzej Białecki]

A1, D (binding)

> On 1 Sep 2020, at 02:26, Ryan Ernst  wrote:
> 
> 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


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

Re: Performance testing is necessary now

[Andrzej Białecki]

> On 12 Aug 2020, at 07:06, Ishan Chattopadhyaya  
> wrote:
> 

> > Whatever we do or not do is imperfect.  I hope some "mandate" doesn't stop 
> > progress. 
> > We don't go changing code just for the heck of it; we do it for a variety 
> > of matters.
> 
> We sometimes do: https://issues.apache.org/jira/browse/SOLR-12845 
> <https://issues.apache.org/jira/browse/SOLR-12845>.

This is just silly … I didn’t make this change just for the heck of it, we’ve 
had long discussions on Slack about this, so let’s stop being facetious, it 
doesn’t help. I am sorry it resulted in a regression, the scale of which wasn’t 
apparent in my manual tests, nor in unit tests.

> I don't want to stop progress, but I want to avoid situations where someone 
> commits an issue (e.g. SOLR-12845), it causes a massive regression 
> (SOLR-14665), and others have to come and fix the situation 
> (https://issues.apache.org/jira/browse/SOLR-14706 
> <https://issues.apache.org/jira/browse/SOLR-14706> and releases) with very 
> little help or support from the original committer. Just because there was no 
> mandate in place, hours and hours of effort has already been wasted on that 
> issue, let aside the users who are suffering as well. 

To clarify, immediately after the problem was identified I volunteered to fix 
the problem and do a release a week later after our conversation. The reason 
for the delay was that I was away and in no position to immediately test the 
fix and do a release. In the meantime Houston volunteered to do it instead. 
Anyone interested can check the facts in Slack archives. So let’s not suggest I 
was uncooperative just for the heck of it, or because I didn’t care, ok?

—

Andrzej Białecki

Re: [lucene-solr] branch branch_8x updated: SOLR-14066: Deprecate DIH

[Andrzej Białecki]

This breaks branch_8x for me - Java 8 doesn’t recognise the “since” attribute 
in @Deprecated.

> On 2 Jul 2020, at 13:10, is...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> ishan pushed a commit to branch branch_8x
> in repository https://gitbox.apache.org/repos/asf/lucene-solr.git
> 
> 
> The following commit(s) were added to refs/heads/branch_8x by this push:
> new 755d31c  SOLR-14066: Deprecate DIH
> 755d31c is described below
> 
> commit 755d31c4933a5b9bb8e39e5e9fb50b17934ff336
> Author: Ishan Chattopadhyaya 
> AuthorDate: Thu Jul 2 16:38:31 2020 +0530
> 
>SOLR-14066: Deprecate DIH
> ---
> solr/CHANGES.txt | 7 +--
> solr/contrib/dataimporthandler-extras/src/java/overview.html | 2 +-
> solr/contrib/dataimporthandler/README.txt| 9 +
> .../org/apache/solr/handler/dataimport/DataImportHandler.java| 3 +++
> solr/contrib/dataimporthandler/src/java/overview.html| 2 +-
> solr/example/example-DIH/README.txt  | 2 ++
> solr/solr-ref-guide/src/dataimport-screen.adoc   | 2 ++
> solr/solr-ref-guide/src/solr-upgrade-notes.adoc  | 3 +++
> ...-structured-data-store-data-with-the-data-import-handler.adoc | 2 ++
> solr/webapp/web/css/angular/dataimport.css   | 3 ++-
> solr/webapp/web/partials/dataimport.html | 1 +
> 11 files changed, 31 insertions(+), 5 deletions(-)
> 
> diff --git a/solr/CHANGES.txt b/solr/CHANGES.txt
> index 59d1972..a0bdcd4 100644
> --- a/solr/CHANGES.txt
> +++ b/solr/CHANGES.txt
> @@ -351,6 +351,9 @@ Other Changes
> 
> * SOLR-14022: Deprecate CDCR (Joel Bernstein, Ishan Chattopadhyaya)
> 
> +* SOLR-14066: Data Import Handler is deprecated. It is scheduled to be 
> removed as of 9.0 and a community supported
> +  package for the same may now be used instead. (Ishan Chattopadhyaya, 
> janhoy)
> +
> ==  8.5.2 ==
> 
> Consult the LUCENE_CHANGES.txt file for additional, low level, changes in 
> this release.
> @@ -6941,8 +6944,8 @@ Other Changes
>   (David Smiley)
> 
> * SOLR-8842: security rules made more foolproof by asking the requesthandler  
> about the well known
> -  permission name.
>  The APIs are also modified to ue 'index' as the unique identifier instead of 
> name.
> -  Name is an optional attribute
>  now and only to be used when specifying well-known permissions (noble)
> +  permission name.  The APIs are also modified to ue 'index' as the unique 
> identifier instead of name.
> +  Name is an optional attribute  now and only to be used when specifying 
> well-known permissions (noble)
> 
> * SOLR-5616: Simplifies grouping code to use ResponseBuilder.needDocList() to 
> determine if it needs to
>   generate a doc list for grouped results. (Steven Bower, Keith Laban, Dennis 
> Gove)
> diff --git a/solr/contrib/dataimporthandler-extras/src/java/overview.html 
> b/solr/contrib/dataimporthandler-extras/src/java/overview.html
> index a60a25e..5a55432 100644
> --- a/solr/contrib/dataimporthandler-extras/src/java/overview.html
> +++ b/solr/contrib/dataimporthandler-extras/src/java/overview.html
> @@ -16,6 +16,6 @@
> -->
> 
> 
> -Apache Solr Search Server: DataImportHandler Extras contrib
> +Apache Solr Search Server: DataImportHandler Extras contrib. This contrib 
> module is deprecated as of 8.6
> 
> 
> diff --git a/solr/contrib/dataimporthandler/README.txt 
> b/solr/contrib/dataimporthandler/README.txt
> index c969872..1d78b93 100644
> --- a/solr/contrib/dataimporthandler/README.txt
> +++ b/solr/contrib/dataimporthandler/README.txt
> @@ -14,3 +14,12 @@ running Solr you set the following system properties:
>   -Duser.language=xx -Duser.country=YY -Duser.timezone=ZZZ
> 
> where xx, YY, and ZZZ are consistent with any database server's configuration.
> +
> +Deprecation notice
> +--
> +This contrib module is deprecated as of v8.6, scheduled for removal in Solr 
> 9.0.
> +The reason is that DIH is no longer being maintained in a manner we feel is 
> necessary in order to keep it
> +healthy and secure. Also it was not designed to work with SolrCloud and does 
> not meet current performance requirements.
> +
> +The project hopes that the community will take over maintenance of DIH as a 
> 3rd party package (See SOLR-14066 for more details). Please reach out to us 
> at the dev@ mailing list if you want to help.
> +
> diff --git 
> a/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java
>  
> b/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java
> index 9fb8b04..a1fbcc2 100644
> --- 
> a/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java
> +++ 
> b/solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/DataImportHandler.java
> @@ -63,8 

Re: RoadMap?

[Andrzej Białecki]

Autoscaling is another big item, but I think we have to put it into 9x, it’s a 
critical (and critically broken) functionality. We’re making some progress with 
Ilan and Noble so I’m cautiously optimistic.

> On 2 Jul 2020, at 18:58, Gus Heck  wrote:
> 
> Should we have one?
> 
> With 9x having java 11 and gradle migrations on the dev side, and about to 
> have a significant round of deprecations/removals and migrations to plugin 
> for things such as CDCR, DIH etc (see 
> https://issues.apache.org/jira/browse/SOLR-13442 
>  and 
> https://issues.apache.org/jira/browse/SOLR-14022 
> ) some of which may(?) need 
> a replacement (i.e. CDCR?) or ways ot easily re-enable (i.e. streaming) 
> before 9x is able to be released. Plus there's been talk of a revamped UI...
> 
> I'm worried that there is a danger that 9x will continue to diverge and pick 
> up major changes, but always have something big in progress and never be able 
> to release.
> 
> Perhaps we should attempt to put a box around the things that need to happen 
> for 9x, and begin targeting any larger projects that come up at 10x? Among 
> other things the gradle work probably can't be complete until someone has 
> gone through a release using it. (I don't think we build the tarballs in 
> gradle yet for example, unless that got added recently)
> 
> -Gus
> 
> -- 
> http://www.needhamsoftware.com  (work)
> http://www.the111shift.com  (play)

Re: 8.6 release

[Andrzej Białecki]

I wold like to include SOLR-14537 in 8.6 (it’s already tagged), the patch is 
ready and I’m just waiting for Joel to finish performance testing.

> On 27 Jun 2020, at 04:59, Tomás Fernández Löbbe  wrote:
> 
> I tagged SOLR-14590 for 8.6, The PR is ready for review and I plan to merge 
> it soon 
> 
> On Fri, Jun 26, 2020 at 12:54 PM Andrzej Białecki  <mailto:a...@getopt.org>> wrote:
> Jan,
> 
> I just removed SOLR-14182 from 8.6, this needs proper back-compat shims and 
> testing, and I don’t have enough time to get it done properly for 8.6.
> 
>> On 26 Jun 2020, at 13:37, Jan Høydahl > <mailto:jan@cominvent.com>> wrote:
>> 
>> Unresolved Solr issues tagged with 8.6:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%208.6
>>  
>> <https://issues.apache.org/jira/issues/?jql=project%20=%20SOLR%20AND%20resolution%20=%20Unresolved%20AND%20fixVersion%20=%208.6>
>>  
>> 
>> SOLR-14593   Package store API to disable file upload over HTTP  
>> Blocker 
>> SOLR-14580   CloudSolrClient cannot be initialized using 'zkHosts' builder   
>> Blocker 
>> SOLR-14516   NPE during Realtime GET 
>> Major   
>> SOLR-14502   increase bin/solr's post kill sleep 
>> Minor   
>> SOLR-14398   package store PUT should be idempotent  
>> Trivial 
>> SOLR-14311   Shared schema should not have access to core level classes  
>> Major   
>> SOLR-14182   Move metric reporters config from solr.xml to ZK cluster 
>> properties Major   
>> SOLR-14066   Deprecate DIH   
>> Blocker 
>> SOLR-14022   Deprecate CDCR from Solr in 8.x 
>> Blocker 
>> 
>> Plus two private JIRA issues.
>> 
>> Jan
>> 
>>> 26. jun. 2020 kl. 12:06 skrev Bruno Roustant >> <mailto:bruno.roust...@gmail.com>>:
>>> 
>>> So the plan is to cut the release branch on next Tuesday June 30th. If you 
>>> anticipate a problem with the date, please reply.
>>> 
>>> Is there any JIRA issue that must be committed before the release is made 
>>> and that has not already the appropriate "Fix Version"?
>>> 
>>> Currently there 3 unresolved issues flagged as Fix Version = 8.6:
>>> Add tests for corruptions caused by byte flips LUCENE-9356 
>>> <https://issues.apache.org/jira/browse/LUCENE-9356>
>>> Fix linefiledocs compression or replace in tests LUCENE-9191
>>>  <https://issues.apache.org/jira/browse/LUCENE-9191>Can we merge small 
>>> segments during refresh, for faster searching? LUCENE-8962 
>>> <https://issues.apache.org/jira/browse/LUCENE-8962>
>>> 
>>> 
>>> Le mer. 24 juin 2020 à 21:05, David Smiley >> <mailto:david.w.smi...@gmail.com>> a écrit :
>>> 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 >> <mailto:casstarg...@gmail.com>> 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 
>>> normally make the old Upgrade Notes section, I just find it surprising that 
>>> there weren’t any devs who thought any of the 100 or so Solr changes 
>>> warrant any user caveats.
>>> On Jun 17, 2020, 12:27 PM -0500, Tomás Fernández Löbbe 
>>> mailto:tomasflo...@gmail.com>>, wrote:
>>>> +1. Thanks Bruno
>>>> 
>>>> On Wed, Jun 17, 2020 at 6:22 AM Mike Drob >>> <mailto:md...@apache.org>> wrote:
>>>> +1
>>>> 
>>>> The release wizard python script should be sufficient for everything. If 
>

Re: 8.6 release

[Andrzej Białecki]

Jan,

I just removed SOLR-14182 from 8.6, this needs proper back-compat shims and 
testing, and I don’t have enough time to get it done properly for 8.6.

> On 26 Jun 2020, at 13:37, Jan Høydahl  wrote:
> 
> Unresolved Solr issues tagged with 8.6:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%208.6
>  
> 
>  
> 
> SOLR-14593   Package store API to disable file upload over HTTP   
>Blocker 
> SOLR-14580   CloudSolrClient cannot be initialized using 'zkHosts' builder
>Blocker 
> SOLR-14516   NPE during Realtime GET  
>Major   
> SOLR-14502   increase bin/solr's post kill sleep  
>Minor   
> SOLR-14398   package store PUT should be idempotent   
>Trivial 
> SOLR-14311   Shared schema should not have access to core level classes   
>Major   
> SOLR-14182   Move metric reporters config from solr.xml to ZK cluster 
> properties Major   
> SOLR-14066   Deprecate DIH
>Blocker 
> SOLR-14022   Deprecate CDCR from Solr in 8.x  
>Blocker 
> 
> Plus two private JIRA issues.
> 
> Jan
> 
>> 26. jun. 2020 kl. 12:06 skrev Bruno Roustant > >:
>> 
>> So the plan is to cut the release branch on next Tuesday June 30th. If you 
>> anticipate a problem with the date, please reply.
>> 
>> Is there any JIRA issue that must be committed before the release is made 
>> and that has not already the appropriate "Fix Version"?
>> 
>> Currently there 3 unresolved issues flagged as Fix Version = 8.6:
>> Add tests for corruptions caused by byte flips LUCENE-9356 
>> 
>> Fix linefiledocs compression or replace in tests LUCENE-9191
>>  Can we merge small 
>> segments during refresh, for faster searching? LUCENE-8962 
>> 
>> 
>> 
>> Le mer. 24 juin 2020 à 21:05, David Smiley > > a écrit :
>> 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 
>> normally make the old Upgrade Notes section, I just find it surprising that 
>> there weren’t any devs who thought any of the 100 or so Solr changes warrant 
>> any user caveats.
>> On Jun 17, 2020, 12:27 PM -0500, Tomás Fernández Löbbe 
>> mailto:tomasflo...@gmail.com>>, wrote:
>>> +1. Thanks Bruno
>>> 
>>> On Wed, Jun 17, 2020 at 6:22 AM Mike Drob >> > wrote:
>>> +1
>>> 
>>> 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
> 

Re: [VOTE] Lucene logo contest

[Andrzej Białecki]

IMHO this vote is invalid because it doesn’t include all submissions linked to 
that issue. Specifically, it doesn’t include the red / orange variants 
submitted by Dustin Haver (which I personally prefer over the sickly green ones 
… ;) )

I propose to restart the VOTE to include all submissions.

> On 17 Jun 2020, at 17:04, Adrien Grand  wrote:
> 
> A. (PMC) I like that it retains the same idea as our current logo with a more 
> modern look.
> 
> On Wed, Jun 17, 2020 at 4:58 PM Andi Vajda  > wrote:
> 
> C. (current logo)
> 
> Andi.. (pmc)
> 
>> On Jun 15, 2020, at 15:08, Ryan Ernst > > wrote:
>> 
>> 
>> Dear Lucene and Solr developers!
>> 
>> In February a contest was started to design a new logo for Lucene [1]. That 
>> contest concluded, and I am now (admittedly a little late!) calling a vote.
>> 
>> The entries are labeled as follows:
>> 
>> A. Submitted by Dustin Haver [2]
>> 
>> B. Submitted by Stamatis Zampetakis [3] Note that 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, like B1 or B3. If a B variant wins, 
>> we will have a followup vote on the color palette.
>> 
>> C. The current Lucene logo [4]
>> 
>> Please vote for one of the three (or nine depending on your perspective!) 
>> above choices. Note that anyone in the Lucene+Solr community is invited to 
>> express their opinion, though only Lucene+Solr PMC cast binding votes 
>> (indicate non-binding votes in your reply, please). This vote will close one 
>> week from today, Mon, June 22, 2020.
>> 
>> Thanks!
>> 
>> [1] https://issues.apache.org/jira/browse/LUCENE-9221 
>> 
>> [2] 
>> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
>>  
>> 
>> [3] 
>> https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf 
>> 
>> [4] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png 
>> 
> 
> 
> -- 
> Adrien

Re: [VOTE] Release Lucene/Solr 8.5.2 RC1

[Andrzej Białecki]

+1

SUCCESS! [1:59:25.055394]

(this slow smoke test time comes from a combination of running this on a 
relatively wimpy replacement MacBook and a slow network).

> On 23 May 2020, at 09:39, Shalin Shekhar Mangar  
> wrote:
> 
> +1
> 
> SUCCESS! [0:47:23.934909]
> 
> On Wed, May 20, 2020 at 11:28 PM Mike Drob  > wrote:
> Devs,
> 
> Please vote for release candidate 1 for Lucene/Solr 8.5.2
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.2-RC1-rev384dadd9141cec3f848d8c416315dc2384749814
>  
> 
> 
> 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.5.2-RC1-rev384dadd9141cec3f848d8c416315dc2384749814
>  
> 
> 
> The vote will be open until 2020-05-26 18:00 UTC (extended deadline due to 
> multiple holidays in the next 72 hours)
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1 (non-binding)
> 
> Mike
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.

Re: [VOTE] Solr to become a top-level Apache project (TLP)

[Andrzej Białecki]

+1 (binding)

> On 18 May 2020, at 10:46, Dawid Weiss  wrote:
> 
> I am closing this vote, thank you for participating.
> 
> 46 votes have been posted: 35 from PMC members, 8 from committers and
> 3 from user community.
> 
> From this total 8 people voted -1 and 38 people voted +1. Vote
> distribution among PMC members (binding votes):
> 
> [+1]: 31
> [-1]: 4
> 
> The vote has passed. I will follow-up on the process from here on in a
> separate email.
> 
> Dawid
> 
> All collected votes in a spreadsheet:
> https://docs.google.com/spreadsheets/d/1ZmR3C2EgA57QIeJJ3ejKCTUkHdG1lqPOU29heqybkKs/edit?usp=sharing
> 
> And in plain text:
> 
> +1
> 
> PMC Ishan Chattopadhyaya (ichattopadhy...@gmail.com)
> PMC Doron Cohen (cdor...@gmail.com)
> PMC Shai Erera (ser...@gmail.com)
> PMC Ryan Ernst (r...@iernst.net)
> COMMITTER Jim Ferenczi (jim.feren...@gmail.com)
> PMC Otis Gospodnetic (otis.gospodne...@gmail.com)
> PMC Dennis Gove (dpg...@gmail.com)
> PMC Adrien Grand (jpou...@gmail.com)
> PMC Martijn v Groningen (martijn.v.gronin...@gmail.com)
> PMC Mark Harwood (mharw...@apache.org)
> PMC Erik Hatcher (erik.hatc...@gmail.com)
> PMC Shawn Heisey (apa...@elyograg.org)
> PMC Jan Høydahl (jan@cominvent.com)
> COMMITTER Namgyu Kim (kng0...@gmail.com)
> PMC Nicholas Knize (nkn...@gmail.com)
> PMC Shalin Shekhar Mangar (shalinman...@gmail.com)
> PMC Michael McCandless (luc...@mikemccandless.com)
> PMC Christian Moen (c...@atilika.com)
> -- Gora Mohanty (g...@mimirtech.com)
> PMC Robert Muir (rcm...@gmail.com)
> PMC Nhat Nguyen (nhat.ngu...@elastic.co.invalid)
> PMC Kevin Risden (kris...@apache.org)
> PMC Steven A Rowe (sar...@gmail.com)
> PMC Uwe Schindler (u...@thetaphi.de)
> PMC Koji Sekiguchi (koji.sekigu...@rondhuit.com)
> COMMITTER Atri Sharma (a...@apache.org)
> -- Lucky Sharma (goku0...@gmail.com)
> PMC David Smiley (david.w.smi...@gmail.com)
> COMMITTER Michael Sokolov (msoko...@gmail.com)
> PMC Tommaso Teofili (tommaso.teof...@gmail.com)
> PMC Varun Thacker (va...@vthacker.in)
> COMMITTER Tomoko Uchida (tomoko.uchida.1...@gmail.com)
> PMC Andi Vajda (o...@ovaltofu.org)
> PMC Ignacio Vera (iver...@gmail.com)
> PMC Dawid Weiss (dawid.we...@gmail.com)
> PMC Simon Willnauer (simon.willna...@gmail.com)
> PMC Alan Woodward (romseyg...@gmail.com)
> PMC Karl Wright (daddy...@gmail.com)
> 
> -1
> 
> PMC Joel Bernstein (joels...@gmail.com)
> COMMITTER Mike Drob (md...@apache.org)
> PMC Jason Gerlowski (gerlowsk...@gmail.com)
> PMC Anshum Gupta (ans...@anshumgupta.net)
> COMMITTER Gus Heck (gus.h...@gmail.com)
> COMMITTER Chris Hostetter (hossman_luc...@fucit.org)
> PMC Tomás Fernández Löbbe (tomasflo...@gmail.com)
> -- Kevin Watters (kwatt...@kmwllc.com)
> 
> -
> 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

SIP-8 Autoscaling policy engine V2

[Andrzej Białecki]

Hi,

I created SIP-8 to further discuss the design of the new autoscaling policy 
engine. Please take a look at the draft, which explains the background and the 
reasons for this initiative.

Contributions are welcome - especially if you have experience running large 
clusters please share your user story in the User Stories section, these will 
be later compiled into prioritized requirements.

https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2

—

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

Re: [VOTE] Release Lucene/Solr 7.7.3 RC1

[Andrzej Białecki]

That previous error must have been a glitch, maybe network error?

Anyway, +1 now:

SUCCESS! [1:18:32.928557]

> On 22 Apr 2020, at 00:43, Michael Sokolov  wrote:
> 
> +1
> 
> SUCCESS! [0:55:50.289256]
> 
> On Tue, Apr 21, 2020 at 2:48 PM Atri Sharma  wrote:
>> 
>> +1
>> 
>> SUCCESS! [0:44:583254]
>> 
>> On Wed, 22 Apr 2020 at 00:16, Gus Heck  wrote:
>>> 
>>> +1 (linux ubuntu 18.04)
>>> 
>>> SUCCESS! [0:43:51.661530]
>>> 
>>> On Tue, Apr 21, 2020 at 12:44 PM Houston Putman  
>>> wrote:
>>>> 
>>>> +1
>>>> 
>>>> 
>>>> SUCCESS! [1:23:37.392736]
>>>> 
>>>> I also ran the multi-valued field performance test on 7.7.2 and 7.7.3 
>>>> (rc1) to make sure that the backport of SOLR-14013 was successful. 
>>>> Definitely looks like it was.
>>>> 
>>>> 
>>>> Indexing test
>>>> 
>>>> 7.7.2 0m0.558s
>>>> 
>>>> 7.7.3 0m0.926s
>>>> 
>>>> 
>>>> Sharded Query test
>>>> 
>>>> 7.7.2 0m16.932s
>>>> 
>>>> 7.7.3 0m0.281s
>>>> 
>>>> 
>>>> Non-Distrib Query JavaBin test
>>>> 
>>>> 7.7.2 0m16.933s
>>>> 
>>>> 7.7.3 0m0.099s
>>>> 
>>>> 
>>>> Non-Distrib Query JSON test
>>>> 
>>>> 7.7.2 0m0.074s
>>>> 
>>>> 7.7.3 0m0.056s
>>>> 
>>>> 
>>>> - Houston
>>>> 
>>>> 
>>>> On Tue, Apr 21, 2020 at 12:36 PM Nhat Nguyen 
>>>>  wrote:
>>>>> 
>>>>> +1
>>>>> 
>>>>> SUCCESS! [0:48:12.629243]
>>>>> 
>>>>> On Tue, Apr 21, 2020 at 12:29 PM Michael McCandless 
>>>>>  wrote:
>>>>>> 
>>>>>> +1
>>>>>> 
>>>>>> SUCCESS! [0:36:47.309043]
>>>>>> 
>>>>>> Mike McCandless
>>>>>> 
>>>>>> http://blog.mikemccandless.com
>>>>>> 
>>>>>> 
>>>>>> On Tue, Apr 21, 2020 at 12:22 PM Kevin Risden  wrote:
>>>>>>> 
>>>>>>> +1 SUCCESS! [1:38:36.140929]
>>>>>>> 
>>>>>>> Kevin Risden
>>>>>>> 
>>>>>>> On Tue, Apr 21, 2020 at 10:09 AM Ignacio Vera  wrote:
>>>>>>>> 
>>>>>>>> No issues here
>>>>>>>> 
>>>>>>>> +1 SUCCESS! [1:20:57.847225]
>>>>>>>> 
>>>>>>>> On Tue, Apr 21, 2020 at 3:33 PM Jan Høydahl  
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> SUCCESS! [1:05:02.194590]
>>>>>>>>> No issues
>>>>>>>>> 
>>>>>>>>> +1 (did not additional manual checking than running the smoketester)
>>>>>>>>> 
>>>>>>>>> Jan
>>>>>>>>> 
>>>>>>>>>> 21. apr. 2020 kl. 12:27 skrev Andrzej Białecki :
>>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> I’m getting the following error, looks like the checksum doesn’t 
>>>>>>>>>> match the file:
>>>>>>>>>> 
>>>>>>>>>> Test Solr...
>>>>>>>>>> test basics...
>>>>>>>>>> check changes HTML...
>>>>>>>>>> download solr-7.7.3-src.tgz...
>>>>>>>>>>   56.9 MB in 586.29 sec (0.1 MB/sec)
>>>>>>>>>>   verify sha512 digest
>>>>>>>>>> Traceback (most recent call last):
>>>>>>>>>> File "dev-tools/scripts/smokeTestRelease.py", line 1518, in 
>>>>>>>>>>   main()
>>>>>>>>>> File "dev-tools/scripts/smokeTestRelease.py", line 1448, in main
>>>>>>>>>>   smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
>>>>>>>>>> c.is_signed, c.local_keys, ' '.join(c.test_args))
>>>>>>>>>> File "dev-tools/scripts/smoke

Re: [VOTE] Release Lucene/Solr 7.7.3 RC1

[Andrzej Białecki]

Hi,

I’m getting the following error, looks like the checksum doesn’t match the file:

Test Solr...
  test basics...
  check changes HTML...
  download solr-7.7.3-src.tgz...
56.9 MB in 586.29 sec (0.1 MB/sec)
verify sha512 digest
Traceback (most recent call last):
  File "dev-tools/scripts/smokeTestRelease.py", line 1518, in 
main()
  File "dev-tools/scripts/smokeTestRelease.py", line 1448, in main
smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, 
c.local_keys, ' '.join(c.test_args))
  File "dev-tools/scripts/smokeTestRelease.py", line 1504, in smokeTest
checkSigs('solr', solrPath, version, tmpDir, isSigned, keysFile)
  File "dev-tools/scripts/smokeTestRelease.py", line 366, in checkSigs
verifyDigests(artifact, urlString, tmpDir)
  File "dev-tools/scripts/smokeTestRelease.py", line 556, in verifyDigests
raise RuntimeError('SHA512 digest mismatch for %s: expected %s but got %s' 
% (artifact, sha512Expected, sha512Actual))
RuntimeError: SHA512 digest mismatch for solr-7.7.3-src.tgz: expected 
549ab2c35ecfba4610921f0951b3b78595da2bcb6e36da2f2a06828a64a01e656c8d424b4ba8d559b638ab62d871827f004f5f02b8e1eed3b9a0e0cbfd31e8ac
 but got 
57a34207b6c742eae42cf5a0a15eb773d545902314c593c6f10794e6854e2c9ea6b252e9761da9ed5e13915882d6eddba87971495ff88c2cb643f523b6aaff77



> On 21 Apr 2020, at 11:36, Noble Paul  wrote:
> 
> sorry, the direct command is
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.7.3-RC1-rev1a0d2a901dfec93676b0fe8be425101ceb754b85/
> 
> On Tue, Apr 21, 2020 at 6:15 PM Noble Paul  wrote:
>> 
>> Please vote for release candidate ? for Lucene/Solr 7.7.3
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.7.3-RC1-rev1a0d2a901dfec93676b0fe8be425101ceb754b85
>> 
>> You can run the smoke tester directly with this command:
>> 
>> python3 -u dev-tools/scripts/smokeTestRelease.py
>> /tmp/releases/7.7.3/lucene-solr-7.7.3-RC1-rev1a0d2a901dfec93676b0fe8be425101ceb754b85
>> 
>> 
>> Here's my +1
>> 
>> SUCCESS! [1:48:02.520060]
>> 
>> --
>> -
>> Noble Paul
> 
> 
> 
> -- 
> -
> 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

Re: 8.5 release

[Andrzej Białecki]

Ok - in the meantime I added it to branch_8x / 8.6.0, so if there’s an RC2 I’ll 
move the CHANGES entry accordingly.

> On 13 Mar 2020, at 14:45, Alan Woodward  wrote:
> 
> Hi Andrzej, sorry to miss this - I’ve just started a vote on RC1 but if that 
> doesn’t pass then we can get this bug fix in.
> 
>> On 12 Mar 2020, at 17:18, Andrzej Białecki > <mailto:a...@getopt.org>> wrote:
>> 
>> Hi Alan,
>> 
>> Is there still time to merge a fix for SOLR-13264? It’s a bug that makes it 
>> impossible to customise this trigger, you can only config a trigger with its 
>> default operations.
>> 
>>> On 12 Mar 2020, at 17:24, Alan Woodward >> <mailto:romseyg...@gmail.com>> wrote:
>>> 
>>> While I wait for the smoke tester to finish, I’ve been working on release 
>>> notes.  The ReleaseTodo still refers to the old wiki, and release notes are 
>>> on CWiki now, so I’m flying slightly blind.  Looking at what was done for 
>>> the previous release, I’ve created a draft note for lucene which can be 
>>> inspected and edited here:
>>> 
>>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
>>>  
>>> <https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586>
>>> 
>>> For Solr, the 8.4 release note on CWiki points to a section on 
>>> https://lucene.apache.org/solr/news.html 
>>> <https://lucene.apache.org/solr/news.html>  but it’s not entirely clear 
>>> where this section has come from or where it should be drafted.  Can 
>>> anybody enlighten me?
>>> 
>>>> On 11 Mar 2020, at 09:20, Alan Woodward >>> <mailto:romseyg...@gmail.com>> wrote:
>>>> 
>>>> Sure, go ahead
>>>> 
>>>>> On 10 Mar 2020, at 19:22, David Smiley >>>> <mailto:david.w.smi...@gmail.com>> wrote:
>>>>> 
>>>>> Can I assume it's no big deal to post a solr-ref-guide documentation 
>>>>> improvement on the release branch irrespective of whenever you precisely 
>>>>> do the RC?
>>>>> 
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley 
>>>>> <http://www.linkedin.com/in/davidwsmiley>
>>>>> 
>>>>> On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein >>>> <mailto:joels...@gmail.com>> wrote:
>>>>> I just updated solr/CHANGES.txt as I missed something. If you've already 
>>>>> created the RC then it will be there in case of a respin.
>>>>> 
>>>>> 
>>>>> 
>>>>> Joel Bernstein
>>>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>>>>> 
>>>>> 
>>>>> On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera >>>> <mailto:iver...@gmail.com>> wrote:
>>>>> done. Thank you!
>>>>> 
>>>>> On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward >>>> <mailto:romseyg...@gmail.com>> wrote:
>>>>> Go ahead, I’ll start the release build once it’s in.
>>>>> 
>>>>>> On 10 Mar 2020, at 07:26, Ignacio Vera >>>>> <mailto:iver...@gmail.com>> wrote:
>>>>>> 
>>>>>> Hi Alanm
>>>>>> 
>>>>>> Is it  possible to backport 
>>>>>> https://issues.apache.org/jira/browse/LUCENE-9263 
>>>>>> <https://issues.apache.org/jira/browse/LUCENE-9263> for the 8.5 release, 
>>>>>> I push it tester day and CI is happy.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein >>>>> <mailto:joels...@gmail.com>> wrote:
>>>>>> 
>>>>>> Finished the backport for 
>>>>>> https://issues.apache.org/jira/browse/SOLR-14073 
>>>>>> <https://issues.apache.org/jira/browse/SOLR-14073>.
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> 
>>>>>> Joel Bernstein
>>>>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>>>>>> 
>>>>>> 
>>>>>> On Mon, Mar 9, 2020 at 8:44 AM Joel Be

Re: 8.5 release

[Andrzej Białecki]

Hi Alan,

Is there still time to merge a fix for SOLR-13264? It’s a bug that makes it 
impossible to customise this trigger, you can only config a trigger with its 
default operations.

> On 12 Mar 2020, at 17:24, Alan Woodward  wrote:
> 
> While I wait for the smoke tester to finish, I’ve been working on release 
> notes.  The ReleaseTodo still refers to the old wiki, and release notes are 
> on CWiki now, so I’m flying slightly blind.  Looking at what was done for the 
> previous release, I’ve created a draft note for lucene which can be inspected 
> and edited here:
> 
> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
>  
> 
> 
> For Solr, the 8.4 release note on CWiki points to a section on 
> https://lucene.apache.org/solr/news.html 
>   but it’s not entirely clear where 
> this section has come from or where it should be drafted.  Can anybody 
> enlighten me?
> 
>> On 11 Mar 2020, at 09:20, Alan Woodward > > wrote:
>> 
>> Sure, go ahead
>> 
>>> On 10 Mar 2020, at 19:22, David Smiley >> > wrote:
>>> 
>>> Can I assume it's no big deal to post a solr-ref-guide documentation 
>>> improvement on the release branch irrespective of whenever you precisely do 
>>> the RC?
>>> 
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley 
>>> 
>>> 
>>> On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein >> > wrote:
>>> I just updated solr/CHANGES.txt as I missed something. If you've already 
>>> created the RC then it will be there in case of a respin.
>>> 
>>> 
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/ 
>>> 
>>> 
>>> On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera >> > wrote:
>>> done. Thank you!
>>> 
>>> On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward >> > wrote:
>>> Go ahead, I’ll start the release build once it’s in.
>>> 
 On 10 Mar 2020, at 07:26, Ignacio Vera >>> > wrote:
 
 Hi Alanm
 
 Is it  possible to backport 
 https://issues.apache.org/jira/browse/LUCENE-9263 
  for the 8.5 release, I 
 push it tester day and CI is happy.
 
 Thanks,
 
 On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein >>> > wrote:
 
 Finished the backport for https://issues.apache.org/jira/browse/SOLR-14073 
 .
 
 Thanks!
 
 
 Joel Bernstein
 http://joelsolr.blogspot.com/ 
 
 
 On Mon, Mar 9, 2020 at 8:44 AM Joel Bernstein >>> > wrote:
 Ok, I'll do the backport today. Thanks!
 
 Joel Bernstein
 http://joelsolr.blogspot.com/ 
 
 
 On Mon, Mar 9, 2020 at 6:21 AM Alan Woodward >>> > wrote:
 Thanks Uwe!
 
> On 7 Mar 2020, at 10:06, Uwe Schindler  > wrote:
> 
> Hi,
>  
> FYI, I cleaned, renamed, and changed the Jenkins Jobs, so the 8.5 branch 
> is in the loop on ASF Jenkins and Policeman Jenkins.
>  
> Uwe
>  
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de 
> eMail: u...@thetaphi.de 
>  
> From: Alan Woodward mailto:romseyg...@gmail.com>> 
> Sent: Wednesday, March 4, 2020 5:35 PM
> To: dev@lucene.apache.org 
> Subject: Re: 8.5 release
>  
> I’ve created a branch for the 8.5 release (`branch_8_5`) and pushed it to 
> the apache repository.  We’re now at feature freeze, so only bug fixes 
> should be pushed to the branch.
>  
> I can see from 
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20priority%20%3D%20Blocker%20AND%20fixVersion%20%3D%208.5%20ORDER%20BY%20priority%20DESC
>  
> 
>  that we have 4 tickets marked as Blockers for this release.  I plan to 
> build a first release candidate next Monday, which gives us a few days to 
> resolve these.  If that’s not going to be long enough, please let me know.
>  
> Uwe, Steve, can one of you start the Jenkins 

SIP-4: Solr Resource Management API - please review

[Andrzej Białecki]

Hi Solr devs,

I would appreciate feedback on the proposed design and implementation of the 
Resource Management API - please see SIP-4 [1] for details.

After several reviews I think that it’s more or less ready to commit (master 
only) but it’s a sizeable change and I’d hate to miss some obvious design flaw 
:)

Also, note that a chunk of the PR is a refactoring of the SolrMetricsContext 
that was required to support this API (now the “scope” is a part of the context 
instead of being kept separately).

Please leave code-related comments in PR #1100 [2], and other feedback in Jira 
SOLR-13579. Thank you!


[1] 
https://cwiki.apache.org/confluence/display/SOLR/SIP-4+Resource+management+framework
[2] https://github.com/apache/lucene-solr/pull/1100

—

Andrzej Białecki


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

Re: Odd error in testing

[Andrzej Białecki]

The metrics history API can generate graphs and then indeed it uses the 
built-in support in RRD4j for this, which in turn uses AWT.

The DejaVuSansMono.ttf font is packaged inside rrd4j-*.jar so it doesn’t have 
to exist in the filesystem.

> On 23 Jan 2020, at 11:38, Jan Høydahl  wrote:
> 
> Appears that rrd4j always tries to look for a font in the static 
> initialization of RrdGraphConstants: 
> https://github.com/rrd4j/rrd4j/blob/master/src/main/java/org/rrd4j/graph/RrdGraphConstants.java#L297
>  
> 
>  It is looking for DejaVuSansMono.ttf.
> 
> The MetricsHistoryIntegrationTest attempts a «get Grahp» in line 174, which 
> then instantiates RrdGraphDef.
> 
> Should probably factor out the graph test as a separate test, which is only 
> run on systems with fonts installed.
> 
> Jan
> 
>> 23. jan. 2020 kl. 09:28 skrev Shalin Shekhar Mangar > >:
>> 
>> I saw this as well on a Ubuntu Linux box running openjdk 11.0.6. The 
>> failures were 100% reproducible.
>> 
>> I followed https://github.com/AdoptOpenJDK/openjdk-build/issues/682 
>>  and see that a 
>> suggestion is to install fontconfig package. Unfortunately this box is 
>> running an old version and I must upgrade to install fontconfig so I'll try 
>> that later. Putting this here just in case someone runs into it again.
>> 
>> java -version
>> openjdk version "11.0.6" 2020-01-14
>> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
>> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)
>> 
>> On Tue, Dec 11, 2018 at 11:45 PM David Smiley > > wrote:
>> I wonder why RRD4J is doing any AWT stuff at all. I thought we were just 
>> using it to *hold* data, not to visualize. ab?
>> 
>> On Sun, Dec 9, 2018 at 3:27 AM Erick Erickson > > wrote:
>> I reformatted the entire disk on my old machine and installed Mojave
>> fresh then ran tests.
>> 
>> MetricsHistoryIntegrationTest.testGet fails on my old (reformatted,
>> freshly installed Mojave) with the bits below. It does _not_ fail on
>> any other machine.
>> 
>> Weird bits about:
>> 
>> Caused by: java.lang.RuntimeException: java.io.IOException: Problem
>> reading font data.
>> 
>> Unfortunately it doesn't really say _which_ font.
>> 
>> Anyone seen this before? I've seen a couple of references on the web
>> to permissions in the tmp dir and downloading a particular font, but
>> those have been fruitless. The tmp dir has the same permissions on
>> both machines and the machine that succeeds doesn't even have the
>> dejavu fonts suggested by StackOverflow.
>> 
>> Any clues?
>> 
>>  [junit4]> Caused by: java.lang.RuntimeException:
>> java.io.IOException: Problem reading font data.
>>[junit4]> at
>> org.rrd4j.graph.RrdGraphConstants$FontConstructor.getFont(RrdGraphConstants.java:287)
>>[junit4]> at
>> org.rrd4j.graph.RrdGraphConstants.(RrdGraphConstants.java:304)
>>[junit4]> ... 11 more
>>[junit4]> Caused by: java.io.IOException: Problem reading font data.
>>[junit4]> at java.awt.Font.createFont0(Font.java:1000)
>>[junit4]> at java.awt.Font.createFont(Font.java:877)
>>[junit4]> at
>> org.rrd4j.graph.RrdGraphConstants$FontConstructor.getFont(RrdGraphConstants.java:283)
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> 
>> 
>> -- 
>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley 
>>  | Book: 
>> http://www.solrenterprisesearchserver.com 
>> 
>> 
>> -- 
>> Regards,
>> Shalin Shekhar Mangar.
> 

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Andrzej Białecki]

+1

SUCCESS! [1:34:39.788377]

> On 17 Dec 2019, at 21:13, Anshum Gupta  wrote:
> 
> +1
> 
> SUCCESS! [1:21:44.176149]
> 
> On Tue, Dec 17, 2019 at 10:23 AM Adrien Grand  > wrote:
> Please vote for release candidate 1 for Lucene/Solr 8.4.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>  
> 
> 
> 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.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>  
> 
> 
> The vote will be open for at least 3 working days, i.e. until 2019-12-20 
> 19:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> -- 
> Adrien
> 
> 
> -- 
> Anshum Gupta

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

[Andrzej Białecki]

Done.

> On 12 Dec 2019, at 18:23, Adrien Grand  wrote:
> 
> Thank you Andrzej. I noticed my initial suggestion for the RC date falls on 
> Saturday, so I'll build on Monday instead. This will give some more CI cycles 
> to the recent changes that have been merged.
> 
> On Thu, Dec 12, 2019 at 6:14 PM Andrzej Białecki  <mailto:a...@getopt.org>> wrote:
> Adrien,
> Jenkins discovered a bug in my recent fix for SOLR-13975 (see 
> https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/591/ 
> <https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/591/>), I’m testing 
> a fix and should be able to commit it in an hour or so. I’d like to merge it 
> to branch_8_4.
> 
>> On 12 Dec 2019, at 15:35, Adrien Grand > <mailto:jpou...@gmail.com>> wrote:
>> 
>> Thanks Uwe!
>> 
>> On Thu, Dec 12, 2019 at 3:33 PM Uwe Schindler > <mailto:u...@thetaphi.de>> wrote:
>> I enabled the Jenkins jobs on Policeman Jenkins.
>> 
>>  
>> 
>> Uwe
>> 
>>  
>> 
>> -
>> 
>> Uwe Schindler
>> 
>> Achterdiek 19, D-28357 Bremen
>> 
>> https://www.thetaphi.de <https://www.thetaphi.de/>
>> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>>  
>> 
>> From: Adrien Grand mailto:jpou...@gmail.com>> 
>> Sent: Thursday, December 12, 2019 9:56 AM
>> To: Lucene Dev mailto:dev@lucene.apache.org>>
>> Subject: New branch and feature freeze for Lucene/Solr 8.4.0
>> 
>>  
>> 
>> NOTICE:
>> 
>> Branch branch_8_4 has been cut and versions updated to 8.5 on stable branch.
>> 
>> Please observe the normal rules:
>> 
>> * No new features may be committed to the branch.
>> * Documentation patches, build patches and serious bug fixes may be
>>   committed to the branch. However, you should submit all patches you
>>   want to commit to Jira first to give others the chance to review
>>   and possibly vote against the patch. Keep in mind that it is our
>>   main intention to keep the branch as stable as possible.
>> * All patches that are intended for the branch should first be committed
>>   to the unstable branch, merged into the stable branch, and then into
>>   the current release branch.
>> * Normal unstable and stable branch development may continue as usual.
>>   However, if you plan to commit a big change to the unstable branch
>>   while the branch feature freeze is in effect, think twice: can't the
>>   addition wait a couple more days? Merges of bug fixes into the branch
>>   may become more difficult.
>> * Only Jira issues with Fix version 8.4 and priority "Blocker" will delay
>>   a release candidate build.
>> 
>>  
>> 
>> --
>> 
>> Adrien
>> 
>> 
>> 
>> -- 
>> Adrien
> 
> 
> 
> -- 
> Adrien

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

[Andrzej Białecki]

Adrien,
Jenkins discovered a bug in my recent fix for SOLR-13975 (see 
https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/591/ 
), I’m testing a 
fix and should be able to commit it in an hour or so. I’d like to merge it to 
branch_8_4.

> On 12 Dec 2019, at 15:35, Adrien Grand  wrote:
> 
> Thanks Uwe!
> 
> On Thu, Dec 12, 2019 at 3:33 PM Uwe Schindler  > wrote:
> I enabled the Jenkins jobs on Policeman Jenkins.
> 
>  
> 
> Uwe
> 
>  
> 
> -
> 
> Uwe Schindler
> 
> Achterdiek 19, D-28357 Bremen
> 
> https://www.thetaphi.de 
> eMail: u...@thetaphi.de 
>  
> 
> From: Adrien Grand mailto:jpou...@gmail.com>> 
> Sent: Thursday, December 12, 2019 9:56 AM
> To: Lucene Dev mailto:dev@lucene.apache.org>>
> Subject: New branch and feature freeze for Lucene/Solr 8.4.0
> 
>  
> 
> NOTICE:
> 
> Branch branch_8_4 has been cut and versions updated to 8.5 on stable branch.
> 
> Please observe the normal rules:
> 
> * No new features may be committed to the branch.
> * Documentation patches, build patches and serious bug fixes may be
>   committed to the branch. However, you should submit all patches you
>   want to commit to Jira first to give others the chance to review
>   and possibly vote against the patch. Keep in mind that it is our
>   main intention to keep the branch as stable as possible.
> * All patches that are intended for the branch should first be committed
>   to the unstable branch, merged into the stable branch, and then into
>   the current release branch.
> * Normal unstable and stable branch development may continue as usual.
>   However, if you plan to commit a big change to the unstable branch
>   while the branch feature freeze is in effect, think twice: can't the
>   addition wait a couple more days? Merges of bug fixes into the branch
>   may become more difficult.
> * Only Jira issues with Fix version 8.4 and priority "Blocker" will delay
>   a release candidate build.
> 
>  
> 
> --
> 
> Adrien
> 
> 
> 
> -- 
> Adrien

Re: Blockers for 8.4

[Andrzej Białecki]

I’m going to fix SOLR-13563 before Thursday.

> On 10 Dec 2019, at 09:25, Adrien Grand  wrote:
> 
> Hello,
> 
> There seem to be multiple blockers for 8.4. I downgraded SOLR-13563 
> , which has already gone 
> through several releases without being considered a blocker. Please review 
> the list of remaining blockers: 
> https://issues.apache.org/jira/browse/SOLR-14013?jql=(project%3D%22Lucene%20-%20Core%22%20%20OR%20project%20%3DSolr%20)%20and%20priority%20%3DBlocker%20and%20status%3DOpen%20and%20(fixVersion%20%3D8.4%20OR%20fixVersion%20is%20EMPTY%20)
>  
> 
> 
> It looks like SOLR-13978  
> might need a hand if we want it to be merged by the end of the week. Is 
> anyone able to help Ishan and Robert there?
> 
> -- 
> Adrien

Re: [VOTE] Release Lucene/Solr 8.3.1 RC2

[Andrzej Białecki]

+1

SUCCESS! [2:02:34.486964]

> On 2 Dec 2019, at 13:40, Tommaso Teofili  wrote:
> 
> +1 
> SUCCESS! [1:30:05.298235]
> 
> On Fri, 29 Nov 2019 at 16:20, MUNENDRA S N  > wrote:
> 
> +1
> 
> SUCCESS! [1:28:14.138771]
> 
> 
> 
> On Fri, Nov 29, 2019 at 8:12 PM Jan Høydahl  > wrote:
> +1
> 
> SUCCESS! [1:52:34.599842]
> 
> I still think https://issues.apache.org/jira/browse/SOLR-13977 
>  is important and should be 
> mentioned in release email.
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
>> 29. nov. 2019 kl. 10:07 skrev Ishan Chattopadhyaya 
>> mailto:ichattopadhy...@gmail.com>>:
>> 
>> Please vote for release candidate 2 for Lucene/Solr 8.3.1
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f
>>  
>> 
>> 
>> 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.3.1-RC2-reva3d456fba2cd1b9892defbcf46a0eb4d4bb4d01f
>>  
>> 
>> 
>> The vote will be open for at least 72 hours from now.
>> 
>> [x] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> Here is my +1
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> 
>> 
> 

Re: Do we want to pursue an LTS designation?

[Andrzej Białecki]

I agree with the removal of LTS designation - there’s no formal commitment from 
the community to support this or that release for that long.

Even though in practice bug fixes are often backported to older branches that 
are still widely used, there’s no actual contract to do so, and implying there 
is one is misleading.

> On 13 Nov 2019, at 22:46, Chris Hostetter  wrote:
> 
> 
> : The term LTS is used loosely and we actually do not promise anything. What 
> we say is
> : 
> : > 7.7.x Version in the previous major release for bugfixes only (LTS)
>   ...
> 
> : Being the one coining the LTS phrasing I am not opposed to changing it 
> : to something else. But through the years we have used that term I have 
> : not seen a lot of such requests.
> 
> I didn't realize you had put that up on the site -- it does seem very 
> missleading to me as the "LT" in "LTS" is suppose to mean "Long Term" but 
> we do not -- in practice or intent -- have any plans as a project to 
> support "7.7.x" in particular any longer then we would any other arbitrary 
> "latest" minor release.
> 
> Nor did we ever give users who initially installed 7.7.0 when it came out 
> any reason to think it would be "supported" (and get bug fixes) for a 
> "longer term" then a hypothetical 7.8.0 that might have come out a day 
> after they installed some 7.7.x, and replace it's row on that page that 
> you've labeled "LTS".
> 
> We may not have ever gotten questions about it, but that may just be 
> because people have very specific assumptions about what it means, and 
> never thought to ask questions to verify those assumptions.
> 
> I think, given how the project *actually* supports releases, I think we 
> should remove references to "LTS" from that page, and leave the other 
> description "Version in the previous major release for bugfixes only" as 
> it stands -- or perhaps tighten it up even more: "Version in the previous 
> major release that may get bug fixs"
> 
> 
> -Hoss
> http://www.lucidworks.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Missing top level javadocs

[Andrzej Białecki]

+1, I think it’s an excellent idea. The check should also verify that the 
comment not only exists but also that it’s not empty - eg. there’s an IntelliJ 
template that creates an empty top-level javadoc.

> On 4 Nov 2019, at 16:40, Bram Van Dam  wrote:
> 
> David Smiley mentioned this in the "SolrCloud is sick" thread. Instead
> of hijacking that, I figured I'd start another thread.
> 
> On 03/11/2019 05:32, David Smiley wrote:
>>  requiring javadocs on all top level classes.  I think more javadocs 
>> and
>> code comments would be very helpful -- especially for the major
>> classes.
> 
> This sounds like something that's actionable.
> 
> I'm not sure if there are any guidelines regarding documentation on the
> Solr project, but on my team there's a rule that says all classes must
> have a top-level javadoc that explains the "why" of the class. "Why does
> it exist/what's it for?"
> 
> Excluding contrib, solrj and tests, there are some 400 source files with
> classes with missing top level Javadoc. This includes some files with
> undocumented nested "public static" classes -- couldn't find an obvious
> way to exclude those using checkstyle.
> 
> Here's a "top ten most frequently modified files with missing Javadoc"
> below. This is an arbitrary metric, the "most referenced classes" might
> be more useful, but that was harder to hack together with shell foo.
> 
> solr/core/src/java/org/apache/solr/core/CoreContainer.java
> solr/core/src/java/org/apache/solr/handler/admin/CollectionsHandler.java
> solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java
> solr/core/src/java/org/apache/solr/handler/StreamHandler.java
> solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
> solr/core/src/java/org/apache/solr/handler/component/RealTimeGetComponent.java
> solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java
> solr/core/src/java/org/apache/solr/search/JoinQParserPlugin.java
> solr/core/src/java/org/apache/solr/handler/component/HttpShardHandlerFactory.java
> solr/core/src/java/org/apache/solr/handler/SolrConfigHandler.java
> 
> If there's any interest in this, I could write a patch to include
> something like this in the build (ant or gradle, whatever).
> 
> - Bram
> 
> Following checkstyle configuration detects classes with missing Javadoc:
> 
> check.xml:
> ==
> 
>   "-//Checkstyle//DTD Checkstyle Configuration 1.3//EN"
>  "https://checkstyle.org/dtds/configuration_1_3.dtd;>
> 
> 
>   
>   
>   
> 
> 
> Bit of shell foo to list offending files:
> =
> 
> java -jar checkstyle-8.26-all.jar -c config.xml solr/ | cut -d ' ' -f 2
> | sed "s:.*/lucene-solr/::g" | cut -d ':' -f 1 | sort | uniq
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: 8.3 release

[Andrzej Białecki]

Done - merged to 8_3 and 8x. Thanks!

> On 24 Oct 2019, at 13:05, Ishan Chattopadhyaya  
> wrote:
> 
> There was a regression with the SOLR-13677 fix, which Andrzej is
> fixing in a few hours. Will spin RC2 after that is done.
> Thanks,
> Ishan
> 
> On Tue, Oct 22, 2019 at 3:35 AM Ishan Chattopadhyaya
>  wrote:
>> 
>> Sure, Cassandra. Sounds good.
>> 
>> On Tue, Oct 22, 2019 at 1:00 AM Cassandra Targett  
>> wrote:
>>> 
>>> On Oct 19, 2019, 1:32 PM -0500, Ishan Chattopadhyaya 
>>> , wrote:
>>> 
>>> Thanks a lot Andrzej and Shalin.
>>> I'll try to build the RC on Monday. FYI, upon Jan's advice, I'll be using 
>>> his release wizard tool. Also, I'll need to dig into the simultaneous 
>>> refguide release situation. So, i might need help with both along the way.
>>> 
>>> 
>>> The new Ref Guide how-to-publish docs aren’t ready yet - I have them in a 
>>> local branch - and we have done no work yet on any Jenkins builds to 
>>> publish things, so for 8.3 why don’t I follow the process manually for you 
>>> for this release:
>>> 
>>> When you get the RC up, I’ll put the 8.3 docs uploaded to the site with the 
>>> DRAFT watermark (I see the VOTE thread, so I’ll do that now, and reply to 
>>> the thread with the URL).
>>> When you publish the artifacts, I’ll replace the DRAFT watermark with the 
>>> final version.
>>> You will be able to include a link to the HTML docs in your Solr release 
>>> announcement.
>>> 
>>> Between now and then, I also need to send a note to the user list informing 
>>> users of the no-more-PDF change (I have a draft of this ready to go also).
>>> 
>>> Sound reasonable?
>>> 
>>> Cassandra
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: 8.3 release

[Andrzej Białecki]

t;>> I'll revert the package store commits related to SOLR-13821 in the 
>>>>>>>>>> 8.3
>>>>>>>>>> branch. It is supposed to be used by the (SOLR-13822) and it is not a
>>>>>>>>>> part of the 8.3 release.
>>>>>>>>>> --Noble
>>>>>>>>>> 
>>>>>>>>>> On Tue, Oct 15, 2019 at 5:22 AM Adrien Grand >>>>>>>>> <mailto:jpou...@gmail.com>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Ishan,
>>>>>>>>>>> 
>>>>>>>>>>> The release is no longer blocked on LUCENE-8920.
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Oct 10, 2019 at 6:18 PM Ishan Chattopadhyaya
>>>>>>>>>>> mailto:ichattopadhy...@gmail.com>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> +1, Ignacio. Please feel free to do the needful, I'll wait until 
>>>>>>>>>>>> this is resolved.
>>>>>>>>>>>> 
>>>>>>>>>>>> +1, Jan. Sure, I think we should get it in!
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, 10 Oct, 2019, 5:45 PM Đạt Cao Mạnh, 
>>>>>>>>>>>> mailto:caomanhdat...@gmail.com>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Hi Ishan,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I pushed the fix to branch_8_3.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Thu, Oct 10, 2019 at 11:27 AM Jan Høydahl 
>>>>>>>>>>>>> mailto:jan@cominvent.com>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Ishan, I'd like to get 
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/SOLR-13665 
>>>>>>>>>>>>>> <https://issues.apache.org/jira/browse/SOLR-13665> included, 
>>>>>>>>>>>>>> since without it Solr won't work with SSL against Zookeeper.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 10. okt. 2019 kl. 11:45 skrev Ignacio Vera >>>>>>>>>>>>> <mailto:iver...@gmail.com>>:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi Ishan,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks for taking care of the release. We have a blocker in 
>>>>>>>>>>>>>> Lucene (see https://issues.apache.org/jira/browse/LUCENE-8920 
>>>>>>>>>>>>>> <https://issues.apache.org/jira/browse/LUCENE-8920>). I remember 
>>>>>>>>>>>>>> that was an issue for the 8.2.0 release and it was reverted and 
>>>>>>>>>>>>>> naked as a blocker for this release. Maybe we should completely 
>>>>>>>>>>>>>> reverted until we have a better solution? let see what Mike 
>>>>>>>>>>>>>> thinks about it.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Ignacio
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Wed, Oct 9, 2019 at 4:51 PM Uwe Schindler >>>>>>>>>>>>> <mailto:u...@thetaphi.de>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I also had a customer complaining about this. I have the 
>>>>>>>>>>>>>>> feeling it also happens from time to time during inter node 
>>>>>>>>>>>>>>> comm, which uses solrj, too.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Uwe
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Am October 9, 2019 1:38:00 PM UTC schrieb Ishan Chattopadhyaya 
>>>>>>>>>>>>>>> mailto:ichattopadhy...@gmail.com>>:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> +1, Dat! Please go ahead.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki, 
>>>>>>>>>>>>>>>> mailto:a...@getopt.org>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> It’s marked as Minor in Jira, but after reading the 
>>>>>>>>>>>>>>>>> description it sounds scary - IMHO it should be at least well 
>>>>>>>>>>>>>>>>> investigated before 8.3 in order to determine whether it 
>>>>>>>>>>>>>>>>> causes real damage (apart from looking scary and filling the 
>>>>>>>>>>>>>>>>> logs).
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> +1 from me.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh 
>>>>>>>>>>>>>>>>> mailto:caomanhdat...@gmail.com>> 
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Hi Ishan, guys
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I want to include the fix for 
>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/SOLR-13293 
>>>>>>>>>>>>>>>>> <https://issues.apache.org/jira/browse/SOLR-13293> in this 
>>>>>>>>>>>>>>>>> release. Hoping that is ok!
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler 
>>>>>>>>>>>>>>>>> mailto:u...@thetaphi.de>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> ASF Jenkins Jobs also reconfigured.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I left the 8.2 Refguide job in the queue (I cloned it), not 
>>>>>>>>>>>>>>>>>> sure if that one is still needed. All other jobs are 8.3 now.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Uwe
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>>>>>>>>>>>>> https://www.thetaphi.de <https://www.thetaphi.de/>
>>>>>>>>>>>>>>>>>> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>  
> 
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.

Re: 8.3 release

[Andrzej Białecki]

Hi Ishan,

Me too, me too :) I’d like to merge a bug fix for SOLR-13828.

> On 9 Oct 2019, at 15:38, Ishan Chattopadhyaya  
> wrote:
> 
> +1, Dat! Please go ahead.
> 
> On Wed, 9 Oct, 2019, 2:33 PM Andrzej Białecki,  <mailto:a...@getopt.org>> wrote:
> It’s marked as Minor in Jira, but after reading the description it sounds 
> scary - IMHO it should be at least well investigated before 8.3 in order to 
> determine whether it causes real damage (apart from looking scary and filling 
> the logs).
> 
> +1 from me.
> 
>> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh > <mailto:caomanhdat...@gmail.com>> wrote:
>> 
>> Hi Ishan, guys
>> 
>> I want to include the fix for 
>> https://issues.apache.org/jira/browse/SOLR-13293 
>> <https://issues.apache.org/jira/browse/SOLR-13293> in this release. Hoping 
>> that is ok!
>> 
>> Thanks!
>> 
>> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler > <mailto:u...@thetaphi.de>> wrote:
>> ASF Jenkins Jobs also reconfigured.
>> 
>> I left the 8.2 Refguide job in the queue (I cloned it), not sure if that one 
>> is still needed. All other jobs are 8.3 now.
>> 
>> Uwe
>> 
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de <https://www.thetaphi.de/>
>> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>> 
>> > -Original Message-
>> > From: Uwe Schindler mailto:u...@thetaphi.de>>
>> > Sent: Tuesday, October 8, 2019 4:49 PM
>> > To: dev@lucene.apache.org <mailto:dev@lucene.apache.org>
>> > Subject: RE: 8.3 release
>> > 
>> > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
>> > 
>> > Uwe
>> > 
>> > -
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > https://www.thetaphi.de <https://www.thetaphi.de/>
>> > eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>> > 
>> > > -Original Message-
>> > > From: Ishan Chattopadhyaya > > > <mailto:ichattopadhy...@gmail.com>>
>> > > Sent: Tuesday, October 8, 2019 4:32 PM
>> > > To: Lucene Dev mailto:dev@lucene.apache.org>>; 
>> > > Uwe Schindler
>> > > mailto:uschind...@apache.org>>; Steve Rowe 
>> > > mailto:sar...@gmail.com>>
>> > > Subject: Re: 8.3 release
>> > >
>> > > I've cut the 8.3 branch. Please feel free to push in any bug fix. For
>> > > any feature, please let me know to see how we can accommodate it
>> > > safely.
>> > > I'm planning to get myself familiarized with what I need to do for the
>> > > ref guide release (simultaneously with the binary release). So, most
>> > > likely, I'll be able to build artifacts in another week's time.
>> > > @Uwe Schindler / @Steve Rowe  would it be possible to please create a
>> > > Jenkins branch for 8.3?
>> > > Thanks,
>> > > Ishan
>> > >
>> > > On Mon, Oct 7, 2019 at 4:17 PM Ishan Chattopadhyaya
>> > > mailto:ichattopadhy...@gmail.com>> wrote:
>> > > >
>> > > > I'll cut the branch in 12-24 hours from now. If someone has anything
>> > > > to put into branch_8x now, please feel free.
>> > > > If someone has a non-bugfix issue that they want to push in to 8.3
>> > > > after the branch cut, but you're sure it will not disrupt the
>> > > > stability of the release, please let me know and we can discuss on a
>> > > > case-by-case basis.
>> > > >
>> > > > On Wed, Oct 2, 2019 at 8:50 PM Mikhail Khludnev > > > > <mailto:m...@apache.org>>
>> > > wrote:
>> > > > >
>> > > > > Excuse me. I have to recall this message regarding SOLR-13764.
>> > > > >
>> > > > > On Mon, Sep 30, 2019 at 10:56 PM Mikhail Khludnev
>> > > mailto:gge...@gmail.com>> wrote:
>> > > > >>
>> > > > >> Ishan, thanks for update.
>> > > > >> May I propose to hold it for this week, beside of the severe issues 
>> > > > >> you
>> > > mentioned, I'd like to drop pretty neat JSON Query parser for Interval
>> > > Queries https://issues.apache.org/jira/browse/SOLR-13764 
>> > > <https://issues.apache.org/jira/browse/SOLR-13764> this week.
>> > > > >>
>> > > > >> пн, 

Re: 8.3 release

[Andrzej Białecki]

It’s marked as Minor in Jira, but after reading the description it sounds scary 
- IMHO it should be at least well investigated before 8.3 in order to determine 
whether it causes real damage (apart from looking scary and filling the logs).

+1 from me.

> On 9 Oct 2019, at 10:48, Đạt Cao Mạnh  wrote:
> 
> Hi Ishan, guys
> 
> I want to include the fix for 
> https://issues.apache.org/jira/browse/SOLR-13293 
>  in this release. Hoping 
> that is ok!
> 
> Thanks!
> 
> On Tue, Oct 8, 2019 at 4:02 PM Uwe Schindler  > wrote:
> ASF Jenkins Jobs also reconfigured.
> 
> I left the 8.2 Refguide job in the queue (I cloned it), not sure if that one 
> is still needed. All other jobs are 8.3 now.
> 
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de 
> eMail: u...@thetaphi.de 
> 
> > -Original Message-
> > From: Uwe Schindler mailto:u...@thetaphi.de>>
> > Sent: Tuesday, October 8, 2019 4:49 PM
> > To: dev@lucene.apache.org 
> > Subject: RE: 8.3 release
> > 
> > Policeman Jenkins builds and tests 8.3 for Windows and Linux.
> > 
> > Uwe
> > 
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de 
> > eMail: u...@thetaphi.de 
> > 
> > > -Original Message-
> > > From: Ishan Chattopadhyaya  > > >
> > > Sent: Tuesday, October 8, 2019 4:32 PM
> > > To: Lucene Dev mailto:dev@lucene.apache.org>>; 
> > > Uwe Schindler
> > > mailto:uschind...@apache.org>>; Steve Rowe 
> > > mailto:sar...@gmail.com>>
> > > Subject: Re: 8.3 release
> > >
> > > I've cut the 8.3 branch. Please feel free to push in any bug fix. For
> > > any feature, please let me know to see how we can accommodate it
> > > safely.
> > > I'm planning to get myself familiarized with what I need to do for the
> > > ref guide release (simultaneously with the binary release). So, most
> > > likely, I'll be able to build artifacts in another week's time.
> > > @Uwe Schindler / @Steve Rowe  would it be possible to please create a
> > > Jenkins branch for 8.3?
> > > Thanks,
> > > Ishan
> > >
> > > On Mon, Oct 7, 2019 at 4:17 PM Ishan Chattopadhyaya
> > > mailto:ichattopadhy...@gmail.com>> wrote:
> > > >
> > > > I'll cut the branch in 12-24 hours from now. If someone has anything
> > > > to put into branch_8x now, please feel free.
> > > > If someone has a non-bugfix issue that they want to push in to 8.3
> > > > after the branch cut, but you're sure it will not disrupt the
> > > > stability of the release, please let me know and we can discuss on a
> > > > case-by-case basis.
> > > >
> > > > On Wed, Oct 2, 2019 at 8:50 PM Mikhail Khludnev  > > > >
> > > wrote:
> > > > >
> > > > > Excuse me. I have to recall this message regarding SOLR-13764.
> > > > >
> > > > > On Mon, Sep 30, 2019 at 10:56 PM Mikhail Khludnev
> > > mailto:gge...@gmail.com>> wrote:
> > > > >>
> > > > >> Ishan, thanks for update.
> > > > >> May I propose to hold it for this week, beside of the severe issues 
> > > > >> you
> > > mentioned, I'd like to drop pretty neat JSON Query parser for Interval
> > > Queries https://issues.apache.org/jira/browse/SOLR-13764 
> > >  this week.
> > > > >>
> > > > >> пн, 30 сент. 2019 г., 18:04 Ishan Chattopadhyaya
> > > mailto:ichattopadhy...@gmail.com>>:
> > > > >>>
> > > > >>> * Due to some unfinished and half merged work in SOLR-13661, we
> > are
> > > in
> > > > >>> a difficult position for a branch cutting today (as I had proposed).
> > > > >>> I have documented the options on how to deal with that immediately
> > > in
> > > > >>> that issue. I'll work to resolve the situation and cut a branch as
> > > > >>> soon as possible.
> > > > >>> * SOLR-13677 is also a blocker for release, but I can proceed with 
> > > > >>> the
> > > > >>> branch cutting.
> > > > >>>
> > > > >>> I'll take a look at the ref guide's simultaneous release as we reach
> > > > >>> closer to building the artifacts.
> > > > >>> Thanks,
> > > > >>> Ishan
> > > > >>>
> > > > >>> On Wed, Sep 18, 2019 at 9:06 PM Cassandra Targett
> > > mailto:casstarg...@gmail.com>> wrote:
> > > > >>> >
> > > > >>> > As I’ve mentioned to some of you over the past couple of weeks, I
> > > want to propose that we don’t “release” the Ref Guide at all the way we
> > have
> > > been doing it.
> > > > >>> >
> > > > >>> > It deserves a separate thread, which since it’s come up a few 
> > > > >>> > times
> > > this week I should start now, but in essence, my idea is to no longer 
> > > treat
> > the
> > > PDF as a release artifact that requires a vote, and publish the HTML as 
> > > our
> > > primary version of the Ref Guide in effectively the same way we publish 
> > > the
> > > javadocs (at the same time as the binary 

Re: 8.3 release

[Andrzej Białecki]

I’m also working on SOLR-13790 (which is marked Critical, but depending on your 
POV it could be a Blocker - the functionality is broken as is).

If the feature freeze is next week then maybe I’ll also manage to finish 
SOLR-8241, which would give users opportunity to test CaffeineCache performance 
in real-life scenarios.

> On 30 Sep 2019, at 22:59, Ishan Chattopadhyaya  
> wrote:
> 
> Sure Mikhail,
> I'm okay to delay branch cutting by 1 week.
> If someone has any objections, please let me know.
> I'll try to see how we can get those blockers resolved.
> Regards,
> Ishan
> 
> On Tue, Oct 1, 2019 at 1:27 AM Mikhail Khludnev  wrote:
>> 
>> Ishan, thanks for update.
>> May I propose to hold it for this week, beside of the severe issues you 
>> mentioned, I'd like to drop pretty neat JSON Query parser for Interval 
>> Queries https://issues.apache.org/jira/browse/SOLR-13764 this week.
>> 
>> пн, 30 сент. 2019 г., 18:04 Ishan Chattopadhyaya :
>>> 
>>> * Due to some unfinished and half merged work in SOLR-13661, we are in
>>> a difficult position for a branch cutting today (as I had proposed).
>>> I have documented the options on how to deal with that immediately in
>>> that issue. I'll work to resolve the situation and cut a branch as
>>> soon as possible.
>>> * SOLR-13677 is also a blocker for release, but I can proceed with the
>>> branch cutting.
>>> 
>>> I'll take a look at the ref guide's simultaneous release as we reach
>>> closer to building the artifacts.
>>> Thanks,
>>> Ishan
>>> 
>>> On Wed, Sep 18, 2019 at 9:06 PM Cassandra Targett  
>>> wrote:
 
 As I’ve mentioned to some of you over the past couple of weeks, I want to 
 propose that we don’t “release” the Ref Guide at all the way we have been 
 doing it.
 
 It deserves a separate thread, which since it’s come up a few times this 
 week I should start now, but in essence, my idea is to no longer treat the 
 PDF as a release artifact that requires a vote, and publish the HTML as 
 our primary version of the Ref Guide in effectively the same way we 
 publish the javadocs (at the same time as the binary artifacts).
 
 Instead of highjacking this thread with that discussion since it has 
 several aspects, let me send another mail on it where I can flesh it out 
 more and we can discuss there. I have the mail mostly queued up and ready 
 to go already.
 
 Cassandra
 On Sep 18, 2019, 10:23 AM -0500, Gus Heck , wrote:
 
 I learned recently that it's actually all  documented here: 
 https://lucene.apache.org/solr/guide/8_1/how-to-contribute.html#ref-guide-publication-process
 
 On Tue, Sep 17, 2019 at 7:31 PM Ishan Chattopadhyaya 
  wrote:
> 
> Hi Adrien,
> Indeed, meant to write about starting a vote.
> 
> @Gus, I'll have to let Cassandra weigh in on this one as I'm not very 
> familiar with the ref guide release process.
> 
> Regards,
> Ishan
> 
> On Mon, 16 Sep, 2019, 7:28 PM Adrien Grand,  wrote:
>> 
>> +1 to start working on 8.3
>> 
>> Did you mean "start a vote" when you wrote "release the artifacts"? It
>> got me wondering because I don't think we frequently managed to go
>> from cutting a branch to releasing artifacts in so little time in the
>> past.
>> 
>> On Mon, Sep 16, 2019 at 5:52 PM Ishan Chattopadhyaya
>>  wrote:
>>> 
>>> Hi all,
>>> We have a lot of unreleased features and fixes. I propose that we cut
>>> a 8.3 branch in two weeks (in order to have sufficient time to bake in
>>> all in-progress features). If there are no objections to doing so, I
>>> can volunteer for the release as an RM and plan for cutting a release
>>> branch on 30 September (and release the artifacts about 3-4 days after
>>> that).
>>> 
>>> WDYT?
>>> Regards,
>>> Ishan
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
>> 
>> --
>> Adrien
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> 
 
 
 --
 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
>>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


-
To 

Re: Notes from the committers' meeting at Activate 2019

[Andrzej Białecki]

> On 16 Sep 2019, at 19:38, Yonik Seeley  wrote:
> 
> >  - PR is opened - should automatically create a jira if it doesn’t exist yet
> 
> What were the reasons behind this? Shouldn't a JIRA just be optional if we 
> started with a PR?

That’s why we need to discuss this :)

I remember that at some point ASF treated JIRA as the system of record for the 
legal validation of contributions.

I also remember that at some point we used to say that if a discussion didn’t 
happen in JIRA then it didn’t exist, and that any decisions regarding code 
should be recorded in JIRA because we can’t expect people to monitor and 
contribute / object to decisions happening elsewhere.

—

Andrzej Białecki

Re: Notes from the committers' meeting at Activate 2019

[Andrzej Białecki]

> On 16 Sep 2019, at 17:55, Ishan Chattopadhyaya  
> wrote:
> 
>> Committers attending (at least some part of) the meeting, in no particular 
>> order: Erik Hatcher, Anshum Gupta, David Smiley, Gus Heck, Noble Paul, Varun 
>> Thacker, Ishan Chattopadhyaya, Tomás Löbbe, and yours truly.
> 
> Also, Tim Allison, Joel Bernstein, Jason Gerlowski. (Did we miss out
> someone else too?)

Gah, of course, sorry guys - I was even sitting next to them…

> 
> On Mon, Sep 16, 2019 at 7:24 AM Andrzej Białecki  wrote:
>> 
>> Hey folks,
>> 
>> Some of the committers attended the Activate 2019 conference, which took 
>> place in Washington, DC on Sep 10-13.
>> 
>> The schedule was packed, so we managed to only have a ~1hr meeting during a 
>> lunch break - nonetheless, I think it was still very productive!
>> 
>> Committers attending (at least some part of) the meeting, in no particular 
>> order: Erik Hatcher, Anshum Gupta, David Smiley, Gus Heck, Noble Paul, Varun 
>> Thacker, Ishan Chattopadhyaya, Tomás Löbbe, and yours truly.
>> 
>> Here are the notes I took - those attending, feel free to clear up any 
>> errors, omissions or misunderstandings.
>> 
>> - Clean up tests that needlessly use AbstractDistribZk…
>>- because this class creates a control collection, which in many cases is 
>> not needed.
>> 
>> - Consider reusing a single MiniSolrCloudCluster instance for multiple test 
>> suites
>>- always use unique collection names per suite / test
>>- some suites won’t be able to use this due to a particular setup or 
>> side-effects (sysprops, expected metrics, etc)
>>- those that can should execute much faster
>> 
>> - Deprecations in 8x - we still need to actually remove the stuff from 
>> master:
>>- old blob store
>>- old spatial
>>- other things?
>> 
>> - Replace NamedList with MapWriter?
>>- avoid creating objects during serialization
>>- big undertaking, but transition piece by piece
>>- example: ExportHandler / ExportWriter
>>- new API should use MapWriter instead of NamedList / Map
>>- public API changes have to go through deprecation in 8x and removal 
>> only in 9
>> 
>> - We have three different and partially incomplete faceting impls
>>- do we want to do something about it to reduce confusion and code 
>> footprint?
>> 
>> - V2 APIs are incomplete, there’s no workflow to maintain them in sync with 
>> v1. Proposed strategy to improve this:
>>- move SolrJ to v2 - this could be done soon
>>- move Solr internally to use v2
>>- move tests to use v2 by default.
>>- RefGuide in 9.0 should show v2 examples by default
>>- deprecate v1
>>- come up with a better way of creating v2 api metadata (annotations?)
>> 
>> - Promote GitHub-centric approach to dev & collaboration
>>- PRs as the main method for submitting contributions
>>- How to Contribute should be the first section of the github page
>>- PR is opened - should automatically create a jira if it doesn’t exist 
>> yet
>>    - discourage using patches when code review is expected.
>>- PR is more inviting for collaboration than a patch
>>- downside: PR is only for a single branch (no backport integration)
>>- travis integration?
>>- or use Github Actions for automated precommits, tests
>> 
>> - Javadocs, typos, small ref guide changes should not require a Jira issue 
>> with its overheads
>> 
>> —--
>> 
>> Andrzej Białecki
>> 
>> 
>> -
>> 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

Notes from the committers' meeting at Activate 2019

[Andrzej Białecki]

Hey folks,

Some of the committers attended the Activate 2019 conference, which took place 
in Washington, DC on Sep 10-13.

The schedule was packed, so we managed to only have a ~1hr meeting during a 
lunch break - nonetheless, I think it was still very productive!

Committers attending (at least some part of) the meeting, in no particular 
order: Erik Hatcher, Anshum Gupta, David Smiley, Gus Heck, Noble Paul, Varun 
Thacker, Ishan Chattopadhyaya, Tomás Löbbe, and yours truly.

Here are the notes I took - those attending, feel free to clear up any errors, 
omissions or misunderstandings.

- Clean up tests that needlessly use AbstractDistribZk…
- because this class creates a control collection, which in many cases is 
not needed.

- Consider reusing a single MiniSolrCloudCluster instance for multiple test 
suites
- always use unique collection names per suite / test
- some suites won’t be able to use this due to a particular setup or 
side-effects (sysprops, expected metrics, etc)
- those that can should execute much faster

- Deprecations in 8x - we still need to actually remove the stuff from master:
- old blob store
- old spatial
- other things?

- Replace NamedList with MapWriter?
- avoid creating objects during serialization
- big undertaking, but transition piece by piece
- example: ExportHandler / ExportWriter
- new API should use MapWriter instead of NamedList / Map
- public API changes have to go through deprecation in 8x and removal only 
in 9

- We have three different and partially incomplete faceting impls
- do we want to do something about it to reduce confusion and code 
footprint?

- V2 APIs are incomplete, there’s no workflow to maintain them in sync with v1. 
Proposed strategy to improve this:
- move SolrJ to v2 - this could be done soon
- move Solr internally to use v2
- move tests to use v2 by default.
- RefGuide in 9.0 should show v2 examples by default
- deprecate v1
- come up with a better way of creating v2 api metadata (annotations?)

- Promote GitHub-centric approach to dev & collaboration
- PRs as the main method for submitting contributions 
- How to Contribute should be the first section of the github page
- PR is opened - should automatically create a jira if it doesn’t exist yet
- discourage using patches when code review is expected.
- PR is more inviting for collaboration than a patch
- downside: PR is only for a single branch (no backport integration)
- travis integration?
- or use Github Actions for automated precommits, tests

- Javadocs, typos, small ref guide changes should not require a Jira issue with 
its overheads

—--

Andrzej Białecki


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

Re: The Gradle train.

[Andrzej Białecki]

+1 for landing this in master soon. Thanks Mark for your relentless efforts to 
make this happen!

> On 15 Aug 2019, at 23:23, Mark Miller  wrote:
> 
> https://issues.apache.org/jira/projects/SOLR/issues/SOLR-13452 
>  Update the 
> lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> 
> Okay, we are at the point where either this thing lands soon and gains some 
> contributors to help finish or it  overwhelms me and crashes & burns. That 
> almost sounds negative, but it was actually the plan so far and I'm pretty 
> excited after all this time invested. I need to punt this over to the 
> community though - the final implications and ramifications of moving fully 
> to gradle are just too big for me individually regardless of the time frame.
> 
> I've done about 95%+ of what I wanted to do before trying to land something - 
> a few more hoops to jump around. We pull in more deps than we should right 
> now, I'll deal with that shortly, and mvn publishing needs work (mostly 
> around solr-server, but dist and publishing both prob need edge work at 
> least). Those are the main things on my mind. There are probably a ton of 
> other little things, but I'm thinking those that are important will rise up 
> quickly and the rest can be handled over time.
> 
> This will be a large change. Some things will still take time to get up to 
> par with what we have now. Many things will need to be sorted out (jenkins, 
> releases, smoke tester type things, docs, etc).
> 
> I've also made all the decisions and trade-offs and what not. I'm pretty 
> happy about that, but I'm sure some will want to discuss and debate some 
> choices once things are in their face. I've spent a lot of time in my recent 
> life on this stuff and I'm ready to battle for some of it :) And to be 
> mistaken, ignorant, or convinced of other paths for some other parts of it. 
> I'll only say, every time I go from working with the gradle build back to 
> ant+ivy+mvn, it feels like a big backslide.
> 
> I'm thinking maybe in September/October? And only on master, hopefully living 
> side by side with ant+ivy+mvn, but the goal would be for that period to be 
> brief. They can't live in complete harmony - someone has to own the 
> dependency view of the world for example, the one that actually gets 
> committed (license, checksums, etc). Otherwise, I've done my best to do this 
> in a way that doesn't break the current build. Will need to inspect that 
> closer before landing though.
> 
> This is just another heads up. Once we are in a main branch, I'm hoping a few 
> of you will either have to jump in and help this land or we will have to pull 
> it back out I think. Be prepared :)
> 
> -- 
> - Mark
> 
> http://about.me/markrmiller 

Re: [VOTE] Release Lucene/Solr 8.2.0 RC1

[Andrzej Białecki]

+1

SUCCESS! [1:51:04.098987]

> On 23 Jul 2019, at 14:01, Adrien Grand  wrote:
> 
> +1 SUCCESS! [2:34:16.487011]
> 
> 
> On Fri, Jul 19, 2019 at 8:35 PM Ignacio Vera  wrote:
>> 
>> Please vote for release candidate 1 for Lucene/Solr 8.2.0
>> 
>> 
>> The artifacts can be downloaded from:
>> 
>> 
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.2.0-RC1-rev31d7ec7bbfdcd2c4cc61d9d35e962165410b65fe
>> 
>> 
>> 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.2.0-RC1-rev31d7ec7bbfdcd2c4cc61d9d35e962165410b65fe
>> 
>> Here is my +1
>> 
>> SUCCESS! [1:19:01.246595]
> 
> 
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: 8.1.2 bug fix release

[Andrzej Białecki]

Dat,

The fix for SOLR-13583 has been committed to branch_8_1.

> On 3 Jul 2019, at 04:56, Đạt Cao Mạnh  wrote:
> 
> Hi Steve,
> 
> I'm seeing this failure
> 
> [smoker] subprocess.CalledProcessError: Command 'export 
> JAVA_HOME="/home/jenkins/tools/java/latest1.9" 
> PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH" 
> JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; java -version' 
> returned non-zero exit status 127
> on
> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-SmokeRelease-8.1/49/console
>  
> 
> 
> It seems that the /home/jenkins/tools/java/latest1.9/bin does not present in 
> the system. Can you work on this, if that is not possible can you show me how 
> I can connect to that jenkins box?
> 
> Thanks a lot!
> 
> On Wed, Jul 3, 2019 at 9:52 AM Đạt Cao Mạnh  > wrote:
> Hi guys,
> 
> I'm seeing several Lucene test failures for branch_8_1. Should they be marked 
> as badApples?
> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-Tests-8.1/73/ 
> 
> https://builds.apache.org/view/L/view/Lucene/job/Lucene-Solr-NightlyTests-8.1/49/
>  
> 
> 
> 
> On Fri, Jun 28, 2019 at 11:28 PM Ignacio Vera  > wrote:
> Thanks! it is done.
> 
> On Fri, Jun 28, 2019 at 5:19 PM Đạt Cao Mạnh  > wrote:
> Ok, I'm hoping these two are these last ones.
> 
> 
> -- 
> Best regards,
> Cao Mạnh Đạt
> E-mail: caomanhdat...@gmail.com 
> 
> 
> -- 
> Best regards,
> Cao Mạnh Đạt
> E-mail: caomanhdat...@gmail.com 

Re: 8.1.2 bug fix release

[Andrzej Białecki]

I just created SOLR-13583 and I’ll be working on a fix. This is a serious bug, 
both in the way it prevents the old collection deletion and it also may lead to 
data loss when used with REINDEXCOLLECTION and removeSource=true.

Unfortunately, my schedule today and over the weekend was already full as it 
was, so realistically speaking I can work on this on Monday - unless someone 
else bets me to it.

> On 26 Jun 2019, at 17:38, Ignacio Vera  wrote:
> 
> I had a look before and I could not find the section 8.1.2 in 8x and master. 
> I supposed the entry is created once the version is released, so not sure how 
> to proceed.
> 
> 
> On Wed, Jun 26, 2019 at 4:53 PM Ignacio Vera  <mailto:iver...@gmail.com>> wrote:
> Thanks Andrezej,
> 
> I will do it soon
> 
> On Wed, Jun 26, 2019 at 4:43 PM Andrzej Białecki  <mailto:a...@getopt.org>> wrote:
> Ignacio, I think you need to move the entry in lucene/CHANGES.txt for this 
> issue to the 8.1.2 section, not just in branch_8_1 but consistenly on master 
> and on branch_8x?
> 
>> On 25 Jun 2019, at 17:02, Ignacio Vera > <mailto:iver...@gmail.com>> wrote:
>> 
>> Hi,
>> 
>> I would like to backport bug fix LUCENE-8775 that fixes some failures in the 
>> polygon Tessellator when a polygon contain a hole sharing a vertex with the 
>> polygon. Is that ok?
>> 
>> Thanks,
>> 
>> Ignacio
>> 
>> On Tue, Jun 25, 2019 at 1:39 AM Steve Rowe > <mailto:sar...@gmail.com>> wrote:
>> Hi Đạt, I re-enabled the ASF Jenkins 8.1 jobs. - Steve
>> 
>>> On Jun 24, 2019, at 8:09 AM, Đạt Cao Mạnh >> <mailto:caomanhdat...@gmail.com>> wrote:
>>> 
>>> Hi Uwe, Steve.
>>> 
>>> Can Jenkins on branch_8_1 be resumed for 8.1.2 release? I am not sure how 
>>> to enable them on https://builds.apache.org/view/L/view/Lucene/ 
>>> <https://builds.apache.org/view/L/view/Lucene/> 
>>> 
>>> Thanks.
>>> 
>>> On Thu, Jun 13, 2019 at 10:51 AM Ishan Chattopadhyaya 
>>> mailto:ichattopadhy...@gmail.com>> wrote:
>>> Sure Dat, sounds good.
>>> 
>>> On Thu, Jun 13, 2019 at 2:11 PM Đạt Cao Mạnh >> <mailto:caomanhdat...@gmail.com>> wrote:
>>> >
>>> > Hi Ishan,
>>> >
>>> > If upgrade Jetty seems too much for a bug fix release, I will try to 
>>> > upgrade only part that affect SOLR-13413 (one module). Then see how tests 
>>> > will behave then. Does that sound good?
>>> >
>>> > On Thu, Jun 13, 2019 at 4:51 AM Ishan Chattopadhyaya 
>>> > mailto:ichattopadhy...@gmail.com>> wrote:
>>> >>
>>> >> Have we vetted all other changes to Jetty? Are we sure that they don't 
>>> >> introduce a different regression?
>>> >>
>>> >> On Thu, 13 Jun, 2019, 4:16 AM Kevin Risden, >> >> <mailto:kris...@apache.org>> wrote:
>>> >>>
>>> >>> +1 to 8.1.2 and the Jetty upgrade. FYI Erick created 
>>> >>> https://issues.apache.org/jira/browse/SOLR-13541 
>>> >>> <https://issues.apache.org/jira/browse/SOLR-13541> specifically for the 
>>> >>> Jetty upgrade.
>>> >>>
>>> >>> Kevin Risden
>>> >>>
>>> >>>
>>> >>> On Wed, Jun 12, 2019 at 4:47 PM Đạt Cao Mạnh >> >>> <mailto:caomanhdat...@gmail.com>> wrote:
>>> >>>>
>>> >>>> Hi David, yeah sure, that bug fix seems important.
>>> >>>> I also want to do the upgrade Jetty 9.4.19 for 8.1.2 (fix: 
>>> >>>> SOLR-13413). Do you guys have any objections?
>>> >>>>
>>> >>>> On Wed, Jun 12, 2019 at 3:40 PM David Smiley >> >>>> <mailto:david.w.smi...@gmail.com>> wrote:
>>> >>>>>
>>> >>>>> Yes thanks for volunteering.  Also, lets get this serious bug fix in: 
>>> >>>>>  https://issues.apache.org/jira/browse/SOLR-13523 
>>> >>>>> <https://issues.apache.org/jira/browse/SOLR-13523>
>>> >>>>>
>>> >>>>> ~ David Smiley
>>> >>>>> Apache Lucene/Solr Search Developer
>>> >>>>> http://www.linkedin.com/in/davidwsmiley 
>>> >>>>> <http://www.linkedin.com/in/davidwsmiley>
>>> >>>>>
>>> >>>>>
>>> >>>>> On Wed, Jun 

Re: 8.1.2 bug fix release

[Andrzej Białecki]

Ignacio, I think you need to move the entry in lucene/CHANGES.txt for this 
issue to the 8.1.2 section, not just in branch_8_1 but consistenly on master 
and on branch_8x?

> On 25 Jun 2019, at 17:02, Ignacio Vera  wrote:
> 
> Hi,
> 
> I would like to backport bug fix LUCENE-8775 that fixes some failures in the 
> polygon Tessellator when a polygon contain a hole sharing a vertex with the 
> polygon. Is that ok?
> 
> Thanks,
> 
> Ignacio
> 
> On Tue, Jun 25, 2019 at 1:39 AM Steve Rowe  > wrote:
> Hi Đạt, I re-enabled the ASF Jenkins 8.1 jobs. - Steve
> 
>> On Jun 24, 2019, at 8:09 AM, Đạt Cao Mạnh > > wrote:
>> 
>> Hi Uwe, Steve.
>> 
>> Can Jenkins on branch_8_1 be resumed for 8.1.2 release? I am not sure how to 
>> enable them on https://builds.apache.org/view/L/view/Lucene/ 
>>  
>> 
>> Thanks.
>> 
>> On Thu, Jun 13, 2019 at 10:51 AM Ishan Chattopadhyaya 
>> mailto:ichattopadhy...@gmail.com>> wrote:
>> Sure Dat, sounds good.
>> 
>> On Thu, Jun 13, 2019 at 2:11 PM Đạt Cao Mạnh > > wrote:
>> >
>> > Hi Ishan,
>> >
>> > If upgrade Jetty seems too much for a bug fix release, I will try to 
>> > upgrade only part that affect SOLR-13413 (one module). Then see how tests 
>> > will behave then. Does that sound good?
>> >
>> > On Thu, Jun 13, 2019 at 4:51 AM Ishan Chattopadhyaya 
>> > mailto:ichattopadhy...@gmail.com>> wrote:
>> >>
>> >> Have we vetted all other changes to Jetty? Are we sure that they don't 
>> >> introduce a different regression?
>> >>
>> >> On Thu, 13 Jun, 2019, 4:16 AM Kevin Risden, > >> > wrote:
>> >>>
>> >>> +1 to 8.1.2 and the Jetty upgrade. FYI Erick created 
>> >>> https://issues.apache.org/jira/browse/SOLR-13541 
>> >>>  specifically for the 
>> >>> Jetty upgrade.
>> >>>
>> >>> Kevin Risden
>> >>>
>> >>>
>> >>> On Wed, Jun 12, 2019 at 4:47 PM Đạt Cao Mạnh > >>> > wrote:
>> 
>>  Hi David, yeah sure, that bug fix seems important.
>>  I also want to do the upgrade Jetty 9.4.19 for 8.1.2 (fix: SOLR-13413). 
>>  Do you guys have any objections?
>> 
>>  On Wed, Jun 12, 2019 at 3:40 PM David Smiley >  > wrote:
>> >
>> > Yes thanks for volunteering.  Also, lets get this serious bug fix in:  
>> > https://issues.apache.org/jira/browse/SOLR-13523 
>> > 
>> >
>> > ~ David Smiley
>> > Apache Lucene/Solr Search Developer
>> > http://www.linkedin.com/in/davidwsmiley 
>> > 
>> >
>> >
>> > On Wed, Jun 12, 2019 at 9:27 AM Đạt Cao Mạnh > > > wrote:
>> >>
>> >> Hi,
>> >>
>> >> Just right after the 8.1.1 release has been published we’ve 
>> >> discovered a serious bug in BasicAuthentication which affect all 
>> >> released versions of Solr including 8.0, 8.1, 8.1.1. Details of the 
>> >> bug can be found in SOLR-13510.
>> >>
>> >> I’m volunteering to do this release, if there are no objections, and 
>> >> I’d like to create a RC early next week.
>> >>
>> >> --
>> >> Best regards,
>> >> Cao Mạnh Đạt
>> >> E-mail: caomanhdat...@gmail.com 
>> 
>> 
>> 
>>  --
>>  Best regards,
>>  Cao Mạnh Đạt
>>  E-mail: caomanhdat...@gmail.com 
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Cao Mạnh Đạt
>> > E-mail: caomanhdat...@gmail.com 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> 
>> 
>> 
>> 
>> -- 
>> Best regards,
>> Cao Mạnh Đạt
>> E-mail: caomanhdat...@gmail.com 
> 

Re: Enable Jenkins 7.7 jobs

[Andrzej Białecki]

The same for 8.1 jobs, I think - thanks!

> On 5 Jun 2019, at 08:32, Jan Høydahl  wrote:
> 
> Steve, these jobs can be disabled again now.
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
>> 14. mai 2019 kl. 10:44 skrev Jan Høydahl > >:
>> 
>> Thanks steve!
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com 
>> 
>>> 14. mai 2019 kl. 10:38 skrev Steve Rowe >> >:
>>> 
>>> Hi Jan,
>>> 
>>> I've re-enabled the 7.7 ASF Jenkins jobs.
>>> 
>>> --
>>> Steve
>>> 
 On May 12, 2019, at 12:10 PM, Jan Høydahl >>> > wrote:
 
 Hi,
 
 Can someone help re-enabling all the 7.7 Jenkins jobs, for the upcoming 
 7.7.2 release?
 
 Jan Høydahl
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
 
 For additional commands, e-mail: dev-h...@lucene.apache.org 
 
 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>>> 
>>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>>> 
>>> 
>> 
> 

Re: VOTE: Apache Solr Reference Guide for Solr 8.0

[Andrzej Białecki]

+1.

I noticed a minor grammar issue in the stream-decorator-reference section on 
“daemon”, where it explains the “list” command: "along with there current 
state” should use “their”.


> On 3 Jun 2019, at 06:37, Anshum Gupta  wrote:
> 
> +1
> 
> 
> On Fri, May 31, 2019 at 7:24 AM Cassandra Targett  > wrote:
> Please vote to release the Solr Reference Guide for 8.0.
> 
> The PDF artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-8.0-RC1/
>  
> 
> 
> $ cat apache-solr-ref-guide-8.0.pdf.sha512 
> c3d01089cb68fdbaa49dc94483a2643fba71ff9900840fbb1a6cc731f2116a9ce9994ab8b832429948f61c6caa7a52f1abfbc8c479c6958644076a8bf99a62f9
>   apache-solr-ref-guide-8.0.pdf
> 
> The online version is available at: https://lucene.apache.org/solr/guide/8_0/ 
> 
> 
> Here's my +1.
> 
> Cassandra
> 
> PS - The 8.1 Guide will follow along hopefully by next week.
> 
> 
> -- 
> Anshum Gupta

Re: [VOTE] Release Lucene/Solr 7.7.2 RC1

[Andrzej Białecki]

+1

SUCCESS! [1:44:46.792802]

> On 31 May 2019, at 14:45, Shalin Shekhar Mangar  
> wrote:
> 
> +1
> 
> SUCCESS! [0:51:25.880324]
> 
> On Wed, May 29, 2019 at 5:24 AM Jan Høydahl  > wrote:
> Please vote for release candidate 1 for Lucene/Solr 7.7.2
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.7.2-RC1-revd4c30fc2856154f2c1fefc589eb7cd070a415b94
>  
> 
> 
> 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-7.7.2-RC1-revd4c30fc2856154f2c1fefc589eb7cd070a415b94
>  
> 
> 
> The vote will be open for at least 3 working days, i.e. until 2019-06-04 
> 08:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> SUCCESS! [1:06:20.144701]
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.

Re: [VOTE] Release Lucene/Solr 7.7.2 RC1

[Andrzej Białecki]

It’s failing for me in every place where the keys are read using ‘utf-8’. 
Changing it to ISO-8859-1 “fixes” this error but it’s not clear to me why this 
is happening in my environment and not in others'.

> On 30 May 2019, at 17:13, Jan Høydahl  wrote:
> 
> Try with encoding=‘ISO-8859-1’ in this line: 
> https://github.com/apache/lucene-solr/blob/faaee86efb01fa6e431fcb129cfb956c7d62d514/dev-tools/scripts/smokeTestRelease.py#L378
>  
> 
> Jan Høydahl
> 
>> 30. mai 2019 kl. 15:21 skrev Jan Høydahl :
>> 
>> Hmm 0xf8 is the ascii code for letter «ø» which is part of my surname and 
>> probably in my gpg key. Sounds like the keys file is attempted parsed as 
>> utf-8 but is ISO encoded or something? Can you check exactly what line of 
>> smoketester script that barfs?
>> 
>> Jan Høydahl
>> 
>>> 30. mai 2019 kl. 15:06 skrev Andrzej Białecki :
>>> 
>>> 0xf8
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: [VOTE] Release Lucene/Solr 7.7.2 RC1

[Andrzej Białecki]

Hi,

For some reason I’m getting the following error (Mac OSX Mojave, clean checkout 
of branch_7_7):

JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home 
python3 -u dev-tools/scripts/smokeTestRelease.py 
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.7.2-RC1-revd4c30fc2856154f2c1fefc589eb7cd070a415b94
Revision: d4c30fc2856154f2c1fefc589eb7cd070a415b94
Java 1.8 
JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home
NOTE: output encoding is UTF-8

Load release URL 
"https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.7.2-RC1-revd4c30fc2856154f2c1fefc589eb7cd070a415b94;...

Get KEYS...
Downloading online KEYS file https://archive.apache.org/dist/lucene/KEYS
0.3 MB in 0.40 sec (0.7 MB/sec)

Test Lucene...
  test basics...
  check changes HTML...
  download lucene-7.7.2-src.tgz...
43.5 MB in 123.23 sec (0.4 MB/sec)
verify sha512 digest
verify sig
Traceback (most recent call last):
  File "dev-tools/scripts/smokeTestRelease.py", line 1518, in 
main()
  File "dev-tools/scripts/smokeTestRelease.py", line 1448, in main
smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, 
c.local_keys, ' '.join(c.test_args))
  File "dev-tools/scripts/smokeTestRelease.py", line 1497, in smokeTest
checkSigs('lucene', lucenePath, version, tmpDir, isSigned, keysFile)
  File "dev-tools/scripts/smokeTestRelease.py", line 379, in checkSigs
for line in f.readlines():
  File "/Users/ab/anaconda3/lib/python3.7/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf8 in position 180: 
invalid start byte


> On 29 May 2019, at 01:54, Jan Høydahl  wrote:
> 
> Please vote for release candidate 1 for Lucene/Solr 7.7.2
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.7.2-RC1-revd4c30fc2856154f2c1fefc589eb7cd070a415b94
> 
> 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-7.7.2-RC1-revd4c30fc2856154f2c1fefc589eb7cd070a415b94
> 
> The vote will be open for at least 3 working days, i.e. until 2019-06-04 
> 08:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> SUCCESS! [1:06:20.144701]
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
> 
> -
> 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

[ANNOUNCE] Apache Solr 8.1.1 released

[Andrzej Białecki]

## 28 May 2019, Apache Solr™ 8.1.1 available

The Lucene PMC is pleased to announce the release of Apache Solr 8.1.1

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, dynamic clustering, database integration, 
rich document
(e.g., Word, PDF) 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.1.1 is available for immediate download at:
  

Please read CHANGES.txt for a full list of new features and changes:

  

### Solr 8.1.1 Release Highlights
* Fix for a Null Pointer Exception when querying collection through collection 
alias.

Please report any feedback to the mailing lists
(http://lucene.apache.org/solr/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 goes for Maven access.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[RESULT] [VOTE] Release Lucene/Solr 8.1.1 RC1

[Andrzej Białecki]

Hi,

This vote has been open for more than 72 hours (including weekend) and it 
passed with 7 +1 binding votes, 1 +1 non-binding vote and 0 -1 votes.

I’m going to work now on preparing the official release + announcements.


> On 22 May 2019, at 19:46, Andrzej Białecki  wrote:
> 
> Please vote for release candidate 1 for Lucene/Solr 8.1.1.
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.1-RC1-revfcbe46c28cef11bc058779afba09521de1b19bef
> 
> 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.1.1-RC1-revfcbe46c28cef11bc058779afba09521de1b19bef
> 
> 
> Here's my +1
> SUCCESS! [1:00:35.149875]
> 
> —
> 
> Andrzej Białecki
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Lucene/Solr 8.1.1

[Andrzej Białecki]

Hi all,

A quick reminder that during the release process for 8.1.1 any commits to 
branch_8_1 must first be submitted as a patch in JIRA and approved by the 
release manager (yours truly).

—

Andrzej Białecki

Re: [jira] [Commented] (LUCENE-8809) Refresh and rollback concurrently can leave segment states unclosed

[Andrzej Białecki]

Hi Nhat,

Commits to branch_8_1 are not allowed now due to the fact that this branch is 
used for the 8.1.1 release - any critical bug fixes should be first submitted 
to JIRA as a patch and approved by the release coordinator (in this case me). 
Please revert your latest commit from branch_8_1.



> On 23 May 2019, at 17:51, ASF subversion and git services (JIRA) 
>  wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/LUCENE-8809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846812#comment-16846812
>  ] 
> 
> ASF subversion and git services commented on LUCENE-8809:
> -
> 
> Commit 2e16009197ac10149a53eb97e875f89bd3a75472 in lucene-solr's branch 
> refs/heads/branch_8_1 from Nhat Nguyen
> [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2e16009 ]
> 
> LUCENE-8809: Ensure release segment states
> 
> If refresh and rollback happen concurrently, then we can leave segment
> states unreleased leads to leaking refCount of some SegmentReaders.
> 
> 
>> Refresh and rollback concurrently can leave segment states unclosed
>> ---
>> 
>>Key: LUCENE-8809
>>URL: https://issues.apache.org/jira/browse/LUCENE-8809
>>Project: Lucene - Core
>> Issue Type: Bug
>> Components: core/index
>>   Affects Versions: 7.7, 8.1, 8.2
>>   Reporter: Nhat Nguyen
>>   Priority: Major
>> Time Spent: 50m
>> Remaining Estimate: 0h
>> 
>> A [failed test|https://github.com/elastic/elasticsearch/issues/30290] from 
>> Elasticsearch shows that refresh and rollback concurrently can leave segment 
>> states unclosed leads to leaking refCount of some SegmentReaders.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
> 
> -
> 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

[VOTE] Release Lucene/Solr 8.1.1 RC1

[Andrzej Białecki]

Please vote for release candidate 1 for Lucene/Solr 8.1.1.

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.1.1-RC1-revfcbe46c28cef11bc058779afba09521de1b19bef

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.1.1-RC1-revfcbe46c28cef11bc058779afba09521de1b19bef


Here's my +1
SUCCESS! [1:00:35.149875]

—

Andrzej Białecki


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

Re: Lucene/Solr 8.1.1

[Andrzej Białecki]

Thanks Jan, this fixed it! Now I’m trying to get it to pass all tests (there 
are intermittent failures from known flaky tests).

> On 21 May 2019, at 17:51, Jan Høydahl  wrote:
> 
> I committed a fix for SOLR-13485, please try again.
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
> 
>> 21. mai 2019 kl. 12:32 skrev Andrzej Białecki > <mailto:a...@getopt.org>>:
>> 
>> Currently blocked by SOLR-13485.
>> 
>>> On 20 May 2019, at 17:53, Andrzej Białecki >> <mailto:a...@getopt.org>> wrote:
>>> 
>>> Hi,
>>> 
>>> Just an update - I started working on the 8.1.1 bug fix release. This 
>>> release will include a fix for SOLR-13475. At this time I’m not aware of 
>>> any other critical / blocker bug fixes scheduled for this release (I think 
>>> that LUCENE-8785 was included in 8.1.0?).
>>> 
>>> If all goes well I should be ready with an RC1 by tomorrow.
>>> 
>>> —
>>> 
>>> Andrzej Białecki
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>>> <mailto:dev-unsubscr...@lucene.apache.org>
>>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>>> <mailto:dev-h...@lucene.apache.org>
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> <mailto:dev-unsubscr...@lucene.apache.org>
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> <mailto:dev-h...@lucene.apache.org>
>> 
> 

Re: 8.1.1 bug fix release

[Andrzej Białecki]

Sure. I’m also blocked on SOLR-13485, I’d appreciate any suggestions where to 
look for the source of this issue.

> On 21 May 2019, at 16:14, Uwe Schindler  wrote:
> 
> Please wait for: https://issues.apache.org/jira/browse/LUCENE-8807 
> <https://issues.apache.org/jira/browse/LUCENE-8807>
>  
> This seems to be important for Apache Foundation, although we use checksums, 
> so it’s not a security issue for Lucene/Solr.
>  
> Uwe
>  
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de <https://www.thetaphi.de/>
> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>  
> From: Andrzej Białecki mailto:a...@getopt.org>> 
> Sent: Friday, May 17, 2019 5:15 PM
> To: Lucene Dev mailto:dev@lucene.apache.org>>
> Subject: Re: 8.1.1 bug fix release
>  
> This is my first release (ever) so I’m still going through local preparations 
> (reading the docs, installing tools, etc). I’m pretty sure I won’t be able to 
> create an RC before Monday.
> 
> 
>> On 17 May 2019, at 13:49, Jan Høydahl > <mailto:jan@cominvent.com>> wrote:
>>  
>> We stil don't have a successful Jenkins Lucene-Solr-SmokeRelease-7.7 build, 
>> and I'm trying to get a successful local build.
>> So I'm OK to delay 7.7.2 RC until after 8.1.1 vote if you are ready to spin 
>> first :)
>>  
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>> 
>> 
>>> 17. mai 2019 kl. 09:09 skrev Ishan Chattopadhyaya 
>>> mailto:ichattopadhy...@gmail.com>>:
>>>  
>>> I'm okay with the timelines, if Jan is okay too. If we do this release 
>>> first, the sooner we can unlock him, the better. (Can we cut an RC today?).
>>>  
>>> On Thu, 16 May, 2019, 10:33 PM Ishan Chattopadhyaya, 
>>> mailto:ichattopadhy...@gmail.com>> wrote:
>>>> Thanks Andrzej. I recommend you get all access (Jira, wiki etc), complete 
>>>> all GPG key prerequisites beforehand. I remember wasting a day on those 
>>>> when I did my first release.
>>>>  
>>>> On Thu, 16 May, 2019, 10:24 PM Andrzej Białecki, >>> <mailto:a...@getopt.org>> wrote:
>>>>> Hi,
>>>>> 
>>>>> Just right after the 8.1.0 release has been published we’ve discovered a 
>>>>> serious bug in the way aliases are handled in the Admin UI (and in some 
>>>>> cases leading to NPE when using API). Details of the bug can be found in 
>>>>> SOLR-13475.
>>>>> 
>>>>> I’m volunteering to do this release, if there are no objections, and I’d 
>>>>> like to create a RC early next week (I need to get up to speed on the 
>>>>> release process ;) ).
>>>>> 
>>>>> —
>>>>> 
>>>>> Andrzej Białecki
>>>>> 
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>>>>> <mailto:dev-unsubscr...@lucene.apache.org>
>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>>>>> <mailto:dev-h...@lucene.apache.org>

Re: Lucene/Solr 8.1.1

[Andrzej Białecki]

Currently blocked by SOLR-13485.

> On 20 May 2019, at 17:53, Andrzej Białecki  wrote:
> 
> Hi,
> 
> Just an update - I started working on the 8.1.1 bug fix release. This release 
> will include a fix for SOLR-13475. At this time I’m not aware of any other 
> critical / blocker bug fixes scheduled for this release (I think that 
> LUCENE-8785 was included in 8.1.0?).
> 
> If all goes well I should be ready with an RC1 by tomorrow.
> 
> —
> 
> Andrzej Białecki
> 
> 
> -
> 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

Lucene/Solr 8.1.1

[Andrzej Białecki]

Hi,

Just an update - I started working on the 8.1.1 bug fix release. This release 
will include a fix for SOLR-13475. At this time I’m not aware of any other 
critical / blocker bug fixes scheduled for this release (I think that 
LUCENE-8785 was included in 8.1.0?).

If all goes well I should be ready with an RC1 by tomorrow.
 
—

Andrzej Białecki


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

Re: 8.1.1 bug fix release

[Andrzej Białecki]

Jan, re. 7.7.2 solr/CHANGES.txt, the entry for SOLR-12833 in the 7.7.2 "Bug 
Fixes" section is somewhat misleading, because the main issue fixed between 
7.7.1 and 7.7.2 was to reduce the memory consumption. I propose to add the 
following (or replace the existing entry, since it only affects the test):

* SOLR-12833: Avoid unnecessary memory cost when DistributedUpdateProcessor 
timed-out lock is not used. (ab)

> On 17 May 2019, at 13:49, Jan Høydahl  wrote:
> 
> We stil don't have a successful Jenkins Lucene-Solr-SmokeRelease-7.7 build, 
> and I'm trying to get a successful local build.
> So I'm OK to delay 7.7.2 RC until after 8.1.1 vote if you are ready to spin 
> first :)
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
> 
>> 17. mai 2019 kl. 09:09 skrev Ishan Chattopadhyaya > <mailto:ichattopadhy...@gmail.com>>:
>> 
>> I'm okay with the timelines, if Jan is okay too. If we do this release 
>> first, the sooner we can unlock him, the better. (Can we cut an RC today?).
>> 
>> On Thu, 16 May, 2019, 10:33 PM Ishan Chattopadhyaya, 
>> mailto:ichattopadhy...@gmail.com>> wrote:
>> Thanks Andrzej. I recommend you get all access (Jira, wiki etc), complete 
>> all GPG key prerequisites beforehand. I remember wasting a day on those when 
>> I did my first release.
>> 
>> On Thu, 16 May, 2019, 10:24 PM Andrzej Białecki, > <mailto:a...@getopt.org>> wrote:
>> Hi,
>> 
>> Just right after the 8.1.0 release has been published we’ve discovered a 
>> serious bug in the way aliases are handled in the Admin UI (and in some 
>> cases leading to NPE when using API). Details of the bug can be found in 
>> SOLR-13475.
>> 
>> I’m volunteering to do this release, if there are no objections, and I’d 
>> like to create a RC early next week (I need to get up to speed on the 
>> release process ;) ).
>> 
>> —
>> 
>> Andrzej Białecki
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> <mailto:dev-unsubscr...@lucene.apache.org>
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> <mailto:dev-h...@lucene.apache.org>
>> 
> 

Re: 8.1.1 bug fix release

[Andrzej Białecki]

This is my first release (ever) so I’m still going through local preparations 
(reading the docs, installing tools, etc). I’m pretty sure I won’t be able to 
create an RC before Monday.

> On 17 May 2019, at 13:49, Jan Høydahl  wrote:
> 
> We stil don't have a successful Jenkins Lucene-Solr-SmokeRelease-7.7 build, 
> and I'm trying to get a successful local build.
> So I'm OK to delay 7.7.2 RC until after 8.1.1 vote if you are ready to spin 
> first :)
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
> 
>> 17. mai 2019 kl. 09:09 skrev Ishan Chattopadhyaya > <mailto:ichattopadhy...@gmail.com>>:
>> 
>> I'm okay with the timelines, if Jan is okay too. If we do this release 
>> first, the sooner we can unlock him, the better. (Can we cut an RC today?).
>> 
>> On Thu, 16 May, 2019, 10:33 PM Ishan Chattopadhyaya, 
>> mailto:ichattopadhy...@gmail.com>> wrote:
>> Thanks Andrzej. I recommend you get all access (Jira, wiki etc), complete 
>> all GPG key prerequisites beforehand. I remember wasting a day on those when 
>> I did my first release.
>> 
>> On Thu, 16 May, 2019, 10:24 PM Andrzej Białecki, > <mailto:a...@getopt.org>> wrote:
>> Hi,
>> 
>> Just right after the 8.1.0 release has been published we’ve discovered a 
>> serious bug in the way aliases are handled in the Admin UI (and in some 
>> cases leading to NPE when using API). Details of the bug can be found in 
>> SOLR-13475.
>> 
>> I’m volunteering to do this release, if there are no objections, and I’d 
>> like to create a RC early next week (I need to get up to speed on the 
>> release process ;) ).
>> 
>> —
>> 
>> Andrzej Białecki
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> <mailto:dev-unsubscr...@lucene.apache.org>
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> <mailto:dev-h...@lucene.apache.org>
>> 
> 

Re: Lucene/Solr 7.7.2

[Andrzej Białecki]

However, changes from all these commits have been already incorporated into 
branch_7_7 in these commits:

fd2851a8d80e81835b45c47ac183282831f30764
2de07e64a959ee380b8bb0159c6193055c969492


> On 16 May 2019, at 18:50, Jan Høydahl  wrote:
> 
> I merged cde00b9a84f3d57252d34daaa77f2b56cf9802cb.
> 
> These commits are not in branch_7_7 either:
> 
> 77cf083e1417e4ac910f06626ae3cb6c3c77a32b Fix PeerSyncTest and 
> TestInPlaceUpdatesDistrib failures Ishan Chattopadhyaya 2019-05-02 23:06
> d9d3c89e3e50f8acee4ad07fff8cd448e2b9b585 DistributedUpdateProcessorTest 
> assumeWorkingMockito() David Smiley* 2019-05-01 06:30
> 74bc993b965c9f51e9a5113c8a6d02b45a423a4a Test should use ExecutorUtil David 
> Smiley 2019-05-01 20:30
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
> 
>> 16. mai 2019 kl. 17:54 skrev Andrzej Białecki 
>> mailto:andrzej.biale...@lucidworks.com>>:
>> 
>> Bulk of SOLR-12833 (including recent changes) should already be there 
>> because it was committed to branch_7_7, with the exception of 
>> cde00b9a84f3d57252d34daaa77f2b56cf9802cb which still needs to be merged to 
>> 7_7 and now to 7_7_2.
>> 
>>> On 16 May 2019, at 17:38, Jan Høydahl >> <mailto:jan@cominvent.com>> wrote:
>>> 
>>> So now backCompat indices for 6.6.6 are pushed, smoketester should be happy.
>>> 
>>> I have also backported these JIRAs, ready to push to branch_7_7, currently 
>>> running tests:
>>> 
>>> SOLR-13229:  Cleanup replicasMetTragicEvent after all exceptions
>>> SOLR-13352:  Remove risk of deadlock/threadleak when shutting down an 
>>> Overseer(TriggerThread)
>>> SOLR-13366:  Clarify 'Invalid stage name' warning logging in 
>>> AutoScalingConfig
>>> SOLR-13386:  OverseerTaskQueue#remove should not throw an exception when no 
>>> node exists after... 
>>> SOLR-13398:  Move log "Processing SSL Credential Provider chain" from INFO 
>>> to DEBUG to prevent...
>>> LUCENE-8720: fix int overflow in NameIntCacheLRU
>>> SOLR-13252:  Fix an NPE when setting a "policy" property for an existing 
>>> collection.
>>> SOLR-13254:  Correct message that is logged in solrj's ConnectionManager 
>>> when an exception…
>>> 
>>> I see no BLOCKERS, and the only JIRA I have on my list for potential 
>>> backport now is
>>> SOLR-12833:  Use timed-out lock in DistributedUpdateProcessor
>>> 
>>> Ishan, Hoss, Andrzej, Smiley, you recently worked with it, what is your 
>>> evaluation of whether it should go in 7.7.2?
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>> 
>>>> 14. mai 2019 kl. 15:38 skrev Ishan Chattopadhyaya 
>>>> mailto:ichattopadhy...@gmail.com>>:
>>>> 
>>>>> I would like to backport SOLR-13410, as without this the ADDROLE of
>>>>> "overseer" is effectively broken. Please let me know if that is fine.
>>>> 
>>>> Just backported this. Hope there's still some time for a Jenkins run or 
>>>> two.
>>>> 
>>>> On Tue, May 14, 2019 at 2:48 PM Jan Høydahl >>> <mailto:jan@cominvent.com>> wrote:
>>>>> 
>>>>> Jenkins jobs for 7_7 were enabled today. Will build the first RC once we 
>>>>> the results of the first few runs.
>>>>> 
>>>>> --
>>>>> Jan Høydahl, search solution architect
>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>>>> 
>>>>> 10. mai 2019 kl. 21:16 skrev Kevin Risden >>>> <mailto:kris...@apache.org>>:
>>>>> 
>>>>> Finished backport of SOLR-13112 for Jackson 2.9.8
>>>>> 
>>>>> Kevin Risden
>>>>> 
>>>>> 
>>>>> On Thu, May 9, 2019 at 6:57 PM Jan Høydahl >>>> <mailto:jan@cominvent.com>> wrote:
>>>>>> 
>>>>>> Looks safe to backport, go ahead!
>>>>>> 
>>>>>> --
>>>>>> Jan Høydahl, search solution architect
>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>>>>> 
>>>>>> 9. mai 2019 kl. 23:07 skrev Cassandra Targett >>>>> <mailto:casstarg...@gmail.com>>:
>>>>>> 
>>>>>

8.1.1 bug fix release

[Andrzej Białecki]

Hi,

Just right after the 8.1.0 release has been published we’ve discovered a 
serious bug in the way aliases are handled in the Admin UI (and in some cases 
leading to NPE when using API). Details of the bug can be found in SOLR-13475.

I’m volunteering to do this release, if there are no objections, and I’d like 
to create a RC early next week (I need to get up to speed on the release 
process ;) ).

—

Andrzej Białecki


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

Re: Lucene/Solr 7.7.2

[Andrzej Białecki]

Bulk of SOLR-12833 (including recent changes) should already be there because 
it was committed to branch_7_7, with the exception of 
cde00b9a84f3d57252d34daaa77f2b56cf9802cb which still needs to be merged to 7_7 
and now to 7_7_2.

> On 16 May 2019, at 17:38, Jan Høydahl  wrote:
> 
> So now backCompat indices for 6.6.6 are pushed, smoketester should be happy.
> 
> I have also backported these JIRAs, ready to push to branch_7_7, currently 
> running tests:
> 
> SOLR-13229:  Cleanup replicasMetTragicEvent after all exceptions
> SOLR-13352:  Remove risk of deadlock/threadleak when shutting down an 
> Overseer(TriggerThread)
> SOLR-13366:  Clarify 'Invalid stage name' warning logging in AutoScalingConfig
> SOLR-13386:  OverseerTaskQueue#remove should not throw an exception when no 
> node exists after... 
> SOLR-13398:  Move log "Processing SSL Credential Provider chain" from INFO to 
> DEBUG to prevent...
> LUCENE-8720: fix int overflow in NameIntCacheLRU
> SOLR-13252:  Fix an NPE when setting a "policy" property for an existing 
> collection.
> SOLR-13254:  Correct message that is logged in solrj's ConnectionManager when 
> an exception…
> 
> I see no BLOCKERS, and the only JIRA I have on my list for potential backport 
> now is
> SOLR-12833:  Use timed-out lock in DistributedUpdateProcessor
> 
> Ishan, Hoss, Andrzej, Smiley, you recently worked with it, what is your 
> evaluation of whether it should go in 7.7.2?
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
> 
>> 14. mai 2019 kl. 15:38 skrev Ishan Chattopadhyaya > <mailto:ichattopadhy...@gmail.com>>:
>> 
>>> I would like to backport SOLR-13410, as without this the ADDROLE of
>>> "overseer" is effectively broken. Please let me know if that is fine.
>> 
>> Just backported this. Hope there's still some time for a Jenkins run or two.
>> 
>> On Tue, May 14, 2019 at 2:48 PM Jan Høydahl > <mailto:jan@cominvent.com>> wrote:
>>> 
>>> Jenkins jobs for 7_7 were enabled today. Will build the first RC once we 
>>> the results of the first few runs.
>>> 
>>> --
>>> Jan Høydahl, search solution architect
>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>> 
>>> 10. mai 2019 kl. 21:16 skrev Kevin Risden >> <mailto:kris...@apache.org>>:
>>> 
>>> Finished backport of SOLR-13112 for Jackson 2.9.8
>>> 
>>> Kevin Risden
>>> 
>>> 
>>> On Thu, May 9, 2019 at 6:57 PM Jan Høydahl >> <mailto:jan@cominvent.com>> wrote:
>>>> 
>>>> Looks safe to backport, go ahead!
>>>> 
>>>> --
>>>> Jan Høydahl, search solution architect
>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>>> 
>>>> 9. mai 2019 kl. 23:07 skrev Cassandra Targett >>> <mailto:casstarg...@gmail.com>>:
>>>> 
>>>> Someone brought https://issues.apache.org/jira/browse/SOLR-13112 
>>>> <https://issues.apache.org/jira/browse/SOLR-13112> to my attention today, 
>>>> which upgraded the Jackson dependencies to 2.9.8. Would it be possible for 
>>>> those to be backported to branch_7_7 for inclusion in 7.7.2?
>>>> 
>>>> Cassandra
>>>> On May 8, 2019, 2:51 PM -0500, Jan Høydahl >>> <mailto:jan@cominvent.com>>, wrote:
>>>> 
>>>> Yes please do!
>>>> 
>>>> --
>>>> Jan Høydahl, search solution architect
>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>>> 
>>>> 8. mai 2019 kl. 18:25 skrev Ishan Chattopadhyaya 
>>>> mailto:ichattopadhy...@gmail.com>>:
>>>> 
>>>> I would like to backport SOLR-13410, as without this the ADDROLE of
>>>> "overseer" is effectively broken. Please let me know if that is fine.
>>>> 
>>>> On Sat, May 4, 2019 at 2:22 AM Jan Høydahl >>> <mailto:jan@cominvent.com>> wrote:
>>>> 
>>>> 
>>>> Sure, go ahead!
>>>> 
>>>> --
>>>> Jan Høydahl, search solution architect
>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>>> 
>>>> 3. mai 2019 kl. 17:53 skrev Andrzej Białecki 
>>>> mailto:andrzej.biale...@lucidworks.com>>:
>>>> 
>>>> Hi,
>>>> 
>>>> I would like to back-port the rec

Re: Solr 8.1 issue with collection aliases

[Andrzej Białecki]

Yes, I can work on 8.1.1 release - I’ll announce this shortly.

> On 16 May 2019, at 13:51, Ishan Chattopadhyaya  
> wrote:
> 
> Absolutely. This is a critical feature.
> Andrzej, would you have time to do a 8.1.1 release? We also need to
> coordinate with Jan, since he's doing a 7.7.2 release right now.
> 
> On Thu, May 16, 2019 at 5:18 PM Jörn Franke  wrote:
>> 
>> For the specific client the Solr 8.1 is not usable with this bug.
>> 
>> Collection aliases are also a crucial feature for doing “zero-downtime” 
>> reindexing or changing the Schema of a collection or for switching back to 
>> an old Index if the new Index structure has bugs etc.
>> 
>> However  I also understand that there are other considerations by other 
>> people.
>> 
>>> Am 16.05.2019 um 11:55 schrieb Ishan Chattopadhyaya 
>>> :
>>> 
>>> Does this warrant a 8.1.1 release? I think this is serious enough.
>>> 
 On Thu, May 16, 2019 at 12:03 PM Jörn Franke  wrote:
 
 SOLR-13475
 
> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya 
> :
> 
> Please open a JIRA.
> 
>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke,  wrote:
>> Sorry autocorrection. It is not only a admin UI issue. I described in my 
>> previous email that access through the collection alias does not work. I 
>> cannot even do execute the select query handler if I use the collection 
>> alias instead of the collection name.
>> So it is maybe more problematic.
>> 
>>> Am 16.05.2019 um 04:36 schrieb Jörn Franke :
>>> 
>>> Note only an admin UI issue. Access collections via their alias does 
>>> not work.
>>> 
 Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
 
 It seems creating alias in Solr Admin UI is broken. It's a minor issue 
 for 8.1.0
 I've alias via REST call 
 http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
   successfully.
 Jörn, thanks for reporting.
 
> On Tue, May 14, 2019 at 11:03 PM Jörn Franke  
> wrote:
> Hi,
> 
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue 
> with
> collection aliases, but I am not 100% sure it is due to the upgrade.
> 
> Situation:
> I have a collection called c_testcollection.
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue
> 
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> http://localhost:8983/solr/c_testcollection/select?q=test
> When I do a query on testcollection then I receive the stacktrace 
> below
> http://localhost:8983/solr/testcollection/select?q=test
> 
> Additionally I observe a strange behavior in the admin ui. When I try 
> to
> create an alias (e.g. new) for a new collection (e.g. c_new) then it
> creates two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I 
> remove
> the alias from c_new to c_new then I get the same error. Is this 
> desired
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to 
> filter
> them out in my application when retrieving all aliases.
> Is there a related issue.
> 
> Here the stacktrace:
> {
> "error":{
>   "trace":"java.lang.NullPointerException\n\tat
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
> 

Re: Lucene/Solr 7.7.2

[Andrzej Białecki]

Hi,

I would like to back-port the recent changes in the re-opened SOLR-12833, since 
the increased memory consumption adversely affects existing 7x users.

> On 3 May 2019, at 10:38, Jan Høydahl  wrote:
> 
> To not confuse two releases at the same time, I'll delay the first 7.7.2 RC 
> until after a successful 8.1 vote.
> Uwe, can you re-enable the Jenkins 7.7 jobs to make sure we have a healthy 
> branch_7_7?
> Feel free to push important bug fixes to the branch in the meantime, 
> announcing them in this thread.
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com 
> 
>> 30. apr. 2019 kl. 18:19 skrev Ishan Chattopadhyaya 
>> mailto:ichattopadhy...@gmail.com>>:
>> 
>> +1 Jan for May 7th.
>> Hopefully, 8.1 would be already out by then (or close to being there).
>> 
>> On Tue, Apr 30, 2019 at 1:33 PM Bram Van Dam > > wrote:
>>> 
>>> On 29/04/2019 23:33, Jan Høydahl wrote:
 I'll vounteer as RM for 7.7.2 and aim at first RC on Tuesday May 7th
>>> 
>>> Thank you!
> 

Re: Metrics 4 upgrade and Ganglia reporter removal

[Andrzej Białecki]

Judging from the resounding silence ;) it’s not a topic that people lose sleep 
over… I’ll go ahead then and do the upgrade + removal, both in master and in 
branch_8x. Feel free to chime in if you feel otherwise.

> On 17 Apr 2019, at 18:56, Andrzej Białecki  wrote:
> 
> Hi all,
> 
> I’d like to draw your attention to SOLR-12461: Upgrade Dropwizard Metrics to 
> 4.0.5 release.
> 
> The upgrade would've been straightforward if not for the fact that Dropwizard 
> removed support for Ganglia reporter in 4x due to a transitive LGPL 
> dependency (on remotetea).
> 
> We have to upgrade this library on master - version 3x is not compatible with 
> Java 11 (due to the internal use of sun.misc.Unsafe), so the Ganglia reporter 
> on master is a goner either way. The question remains what to do about 8x.
> 
> We could stick to Metrics 3 on branch 8x in order to preserve back-compat, 
> but Metrics 4 contains many important bug fixes and improvements so it’s a 
> shame to have to keep using Metrics 3 for the complete lifecycle of 8x... I’m 
> rather inclined to break the back-compat (ever so slightly ;) ) for the 
> greater good - do the upgrade and remove Ganglia in 8x, and put a note in 
> CHANGES to that effect.
> 
> What do people think about this?
> 
> —
> 
> Andrzej Białecki
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: CompositeId router using custom route field for updates and atomic update

[Andrzej Białecki]

Hi Niko,

Please create a Jira issue, this looks like a bug. It also needs more 
discussion - I’m not convinced we should allow updates (atomic or not) to the 
id field, because (as the name suggests) this field defines the identity of the 
document, and if the identity is modified is it still the same document that we 
should be updating? ;)  

> On 18 Apr 2019, at 12:30, Niko Himanen  wrote:
> 
> Hello,
> 
> I came up with a situation with collection created with "router.field" and 
> using atomic update format for route.field in document that documents were 
> routed into wrong shard in CompositeIdRouter. 
> 
> After doing some investigation I noticed that CompositeIdRouter#sliceHash 
> takes field value used for routing as is, which means that atomic update 
> format (like set=123) is used as a whole to calculate route hash instead of 
> just value 123.
> 
> I came over this by using field for routing which is never atomically 
> updated, but I feel like this is still quite nasty feature/bug which is hard 
> to detect.
> 
> Is this a known issue or should I create ticket from it?
> 
> Br,
> 
> Niko Himanen


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

Metrics 4 upgrade and Ganglia reporter removal

[Andrzej Białecki]

Hi all,

I’d like to draw your attention to SOLR-12461: Upgrade Dropwizard Metrics to 
4.0.5 release.

The upgrade would've been straightforward if not for the fact that Dropwizard 
removed support for Ganglia reporter in 4x due to a transitive LGPL dependency 
(on remotetea).

We have to upgrade this library on master - version 3x is not compatible with 
Java 11 (due to the internal use of sun.misc.Unsafe), so the Ganglia reporter 
on master is a goner either way. The question remains what to do about 8x.

We could stick to Metrics 3 on branch 8x in order to preserve back-compat, but 
Metrics 4 contains many important bug fixes and improvements so it’s a shame to 
have to keep using Metrics 3 for the complete lifecycle of 8x... I’m rather 
inclined to break the back-compat (ever so slightly ;) ) for the greater good - 
do the upgrade and remove Ganglia in 8x, and put a note in CHANGES to that 
effect.

What do people think about this?

—

Andrzej Białecki


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

Re: Welcome Tomoko Uchida as Lucene/Solr committer

[Andrzej Białecki]

Welcome, Tomoko!

> On 8 Apr 2019, at 18:18, Tomoko Uchida  wrote:
> 
> Thank you, Uwe and Robert.
> 
> And hello all, I am delighted and excited to join the great team.
> 
> Brief background:
> I've been interested in search & NLP area, and worked with Solr and
> Elasticsearch for five years or so. I joined Luke project (currently
> on GitHub) in 2015 and have served as a committer for my fun and
> learning with the repository owner, Dmitry Kan. Early last year, I
> rewritten Luke almost from scratch to modernize the code base and
> ported UI framework from Thinlet to JavaFX (and then Swing) so that it
> can be distributed under ALv2.
> I am very happy that Luke will finally get into Apache Lucene soon
> (LUCENE-2562). Thanks again for all your help for this long-awaited
> integration!
> 
> Apart from Luke, I'm from Okinawa, Japan, a lovely southern island
> near to Taiwan. ️
> Currently I'm based in Tokyo and work as a web developer and/or search
> engineer. (JFYI, Tomoko is one of the popular Japanese girl's given
> names.)
> 
> Thanks,
> Tomoko
> 
> 2019年4月9日(火) 1:14 Anshum Gupta :
>> 
>> Congratulations and welcome, Tomoko!
>> 
>> On Mon, Apr 8, 2019 at 8:21 AM Uwe Schindler  wrote:
>>> 
>>> Hi all,
>>> 
>>> Please join me in welcoming Tomoko Uchida as the latest Lucene/Solr 
>>> committer!
>>> 
>>> She has been working on https://issues.apache.org/jira/browse/LUCENE-2562 
>>> for several years with awesome progress and finally we got the fantastic 
>>> Luke as a branch on ASF JIRA: 
>>> https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/lucene-2562-luke-swing-3
>>> Looking forward to the first release of Apache Lucene 8.1 with Luke bundled 
>>> in the distribution. I will take care of merging it to master and 8.x 
>>> branches together with her once she got the ASF account.
>>> 
>>> Tomoko also helped with the Japanese and Korean Analyzers.
>>> 
>>> Congratulations and Welcome, Tomoko! Tomoko, it's traditional for you to 
>>> introduce yourself with a brief bio.
>>> 
>>> Uwe & Robert (who nominated Tomoko)
>>> 
>>> -
>>> Uwe Schindler
>>> Achterdiek 19, D-28357 Bremen
>>> https://www.thetaphi.de
>>> eMail: u...@thetaphi.de
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> 
>> 
>> --
>> Anshum Gupta
> 
> 
> 
> -- 
> Tomoko Uchida
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: [VOTE] Release Lucene/Solr 8.0.0 RC2

[Andrzej Białecki]

+1

SUCCESS! [1:22:21.262768]

> On 6 Mar 2019, at 03:37, jim ferenczi  wrote:
> 
> Please vote for release candidate 2 for Lucene/Solr 8.0.0
> 
> The artifacts can be downloaded from 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC2-rev3d5c48ce0edbda1f43ed630911073cae3486df6e
>  
> 
> 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.0.0-RC2-rev3d5c48ce0edbda1f43ed630911073cae3486df6e
>  
> 
> 
> Here’s my +1
> SUCCESS! [0:56:39.85]

Re: [DISCUSS] Opening old indices for reading

[Andrzej Białecki]

+1. I think that even with these caveats (read-only, some data may require 
re-interpretation) it would still be a great help for accessing legacy data, 
for which the original source may no longer exist.

> On 23 Jan 2019, at 15:11, Simon Willnauer  wrote:
> 
> Hey folks,
> 
> tl;dr; I want to be able to open an indexreader on an old index if the
> SegmentInfo version is supported and all segment codecs are available.
> Today that's not possible even if I port old formats to current
> versions.
> 
> Our BWC policy for quite a while has been N-1 major versions. That's
> good and I think we should keep it that way. Only recently, caused by
> changes how we encode/decode norms we also hard-enforce a the
> index-version-created in several places and the version a segment was
> written with. These are great enforcements and I understand why. My
> request here is if we can find consensus on allowing somehow (a
> special DirectoryReader for instance) to open such an index for
> reading only that doesn't provide the guarantees that our high level
> APIs decode norms correctly for instance. This would be enough to for
> instance consume stored fields etc. for reindexing or if a users are
> aware do they norms decoding in the codec. I am happy to work on a
> proposal how this would work. It would still enforce no writing or
> anything like this. I am also all for putting such a reader into misc
> and being experimental.
> 
> simon
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Autoscaling in 8.0

[Andrzej Białecki]

This merits a JIRA issue - things should not behave this way, that’s for sure.

Please create one, attach the ZK:/autoscaling.json and the output of 
`/admin/collections?action=CLUSTERSTATUS` and the outputs from 
/autoscaling/suggestions and /autoscaling/diagnostics - you can anonymize 
actual node names as long as the data stays consistent (ie. the same node names 
across all files).

See also SOLR-13155.

> On 18 Jan 2019, at 20:27, Gus Heck  wrote:
> 
> I'm a little worried about the state of Autoscaling. It looks like it has the 
> potential to create bad first experiences. Granted 8.0 isn't supposed to be 
> stable, but I'm seeing things that were documented for 7.6 not working in 8x
> 
> TLDR:  
>   • Default settings didn't distribute nodes evenly on brand new 50 node 
> cluster
>   • Can't seem to write rules producing suggestions to distribute them 
> evenly
>   • Suggestions are made that then fail despite quiet cluster, no changes.
> Long version:
> 
> My Client and I did something that seems very vanilla but it didn't work out 
> well, and the observed behavior contradicts what's published in 
> https://lucene.apache.org/solr/guide/7_6/solr-upgrade-notes.html#solr-7-6 
> with respect to default core placement. 
> 
> The cluster is a 50 node AWS cluster that was freshly set up by a client to 
> test out 8.0.0 (8.0.0-SNAPSHOT 69cbe29e78c400db22aab2f918405ce627d2d65d - 
> solr - 2019-01-11 15:41:35).
> 
> They created a collection (A) with 50 shards, one replica each (total of50 
> cores). They specified maxShardsPerNode=1, and nothing relating to 
> autoscaling. They indexed a small amount of data in (33438861 docs is small 
> for them) for initial testing. They then handed it over to me, and not yet 
> noticing anything wrong with it I added a second collection (B) similarly 
> configured but with schema changes for comparison. However, I noticed at that 
> point that the nodes page was showing a very strange result for this 
> seemingly vanilla set of steps. Most nodes got one core of each collection, 
> but not all:
> 
> Node 1 got 2 cores from A
> Node 2 got 0 cores
> Node 8 got 3 cores from B
> Node 21 got 2 cores from A and 1 from B
> 
> I've spent all morning fiddling with rules to try to get a configuration that 
> provides suggestions via /api/cluster/autoscaling/suggestions to equalize 
> things and I just can't do it. In particular I can't ever get any suggestion 
> to move anything to node 2. It's as if autoscaling is missing/unable to see 
> node 2. A couple of times I got suggestions with green buttons in the UI 
> (mostly I'm using Postman however)... when I clicked the green button it 
> erred out saying no-node can satisfy Nothing's changing, no data incoming 
> so why is it suggesting things that don't work?
> 
> When I look at /autoscaling/diagnostics I get this seemingly impossible 
> result:
> {
> "node": "solr-2.customer.redacted.com:8983_solr",
> "isLive": true,
> "cores": 2,
> "freedisk": 140.03918838500977,
> "totaldisk": 147.5209503173828,
> "replicas": {}
> },
> 
> 2 cores but no replicas? I looked on disk and there's no data on disk 
> representing a core.
> 
> -Gus
> 
> -- 
> http://www.the111shift.com


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

Re: SOLR-12259: online index schema modification - adding docValues to existing indexed data?

[Andrzej Białecki]

Right - the code on this branch is a port from another branch with other 
changes, too - among others a modified UninvertingReader that discards 
docValues even when FieldInfo claims the field has them (ie it always wraps 
when the mapping says so). Even with that change the results are the same. 

> On 18 Dec 2018, at 20:36, Adrien Grand  wrote:
> 
> UninvertingReader#wrap seems to skip uninverting if the field to
> uninvert already has doc values of the expected type?
> 
> On Tue, Dec 18, 2018 at 8:24 PM Andrzej Białecki
>  wrote:
>> 
>> The unexpected part is that I would have expected the code to handle 
>> franken-segments as well, because at some point we finally resorted to 
>> always forcing the wrapping even for segments that don’t need it (ie. they 
>> claim the field contains DVs) but the test is still failing.
>> 
>> On 18 Dec 2018, at 19:05, Adrien Grand  wrote:
>> 
>> I had a quick look and couldn't find anything to prevent what you
>> called “franken-segments” in the Lucene test?
>> 
>> On Tue, Dec 18, 2018 at 5:59 PM Erick Erickson  
>> wrote:
>> 
>> 
>> A couple of additions:
>> 
>> AddDVMPLuceneTest2 does not use Solr constructs at all, so is the test
>> we think is most interesting at this point, it won't lead anyone down
>> the path of "what's all this Solr stuff and is it right" kinds of
>> questions (believe me, we've spent some time on that path!). Please
>> feel free to look at all the rest of it of course, but the place we're
>> stuck is why this test fails.
>> 
>> AddDvStress is intended as an integration-level test, it requires some
>> special setup (in particular providing a particular configset), we put
>> that together to reliably make the problem visible. We thought the new
>> code was the issue at first and needed something to narrow down the
>> possibilities...
>> 
>> The reason we're obsessing about this is that it calls into question
>> how segments are merged when "things change". We don't understand why
>> this is happening at the Lucene level so don't know how to insure that
>> things like the schema API in Solr aren't affected.
>> 
>> Andrzej isn't the only one running out of ideas ;).
>> 
>> On Tue, Dec 18, 2018 at 4:46 AM Andrzej Białecki  wrote:
>> 
>> 
>> Hi,
>> 
>> I'm working on a use case where an existing Solr setup needs to migrate to a 
>> schema that uses docValues for faceting, instead of uninversion. This case 
>> fits into a broader subject of SOLR-12259 (Robustly upgrade indexes). 
>> However, in this case there are two major requirements for this migration 
>> process:
>> 
>> * data cannot be reindexed from scratch - I need to work with the already 
>> indexed documents (which do contain the values needed for faceting, but 
>> these values are simply indexed and not stored as doc values)
>> 
>> * indexing can’t be stopped while the schema is being changed (the 
>> conversion process needs to work on-the-fly while the collection is online, 
>> both for searching and for updates). Collection reloads / reopening is ok 
>> but it’s not ok to take the collection offline for several minutes (or 
>> hours).
>> 
>> Together with Erick Erickson we implemented a solution that uses MergePolicy 
>> (actually MergePolicyFactory in Solr) to enforce re-writing of segments that 
>> no longer match the schema, ie. don’t contain docValues in a field where the 
>> new schema requires it. This merge policy determines what segments need this 
>> conversion and then forces the “merging” (actually re-writing) of these 
>> segments by first wrapping them into UninvertingReader to supply docValues 
>> where they are required by the new schema but actually are missing in the 
>> segment’s data. This “AddDocValuesMergePolicy” (ADVMP for short) is supposed 
>> to deal with the following types of segments:
>> 
>> * old segments created before the schema change - these don’t contain any 
>> docValues in the target fields and so they are wrapped in UninvertingReader 
>> for merging (and for searching) according to the new schema.
>> 
>> * new segments created after the schema change - if FieldInfo-s for these 
>> fields claim that the segment already contains docValues where it should 
>> then the segment is passed as-is to merging, otherwise it’s wrapped again. 
>> An optimisation was also put here to “mark” the already converted segments 
>> using a marker in SegmentInfo diagnostics map so that we can avoid 
>> re-checking and re-converting already converted data.
>> 
>&g

Re: SOLR-12259: online index schema modification - adding docValues to existing indexed data?

[Andrzej Białecki]

The unexpected part is that I would have expected the code to handle 
franken-segments as well, because at some point we finally resorted to always 
forcing the wrapping even for segments that don’t need it (ie. they claim the 
field contains DVs) but the test is still failing.

> On 18 Dec 2018, at 19:05, Adrien Grand  wrote:
> 
> I had a quick look and couldn't find anything to prevent what you
> called “franken-segments” in the Lucene test?
> 
> On Tue, Dec 18, 2018 at 5:59 PM Erick Erickson  
> wrote:
>> 
>> A couple of additions:
>> 
>> AddDVMPLuceneTest2 does not use Solr constructs at all, so is the test
>> we think is most interesting at this point, it won't lead anyone down
>> the path of "what's all this Solr stuff and is it right" kinds of
>> questions (believe me, we've spent some time on that path!). Please
>> feel free to look at all the rest of it of course, but the place we're
>> stuck is why this test fails.
>> 
>> AddDvStress is intended as an integration-level test, it requires some
>> special setup (in particular providing a particular configset), we put
>> that together to reliably make the problem visible. We thought the new
>> code was the issue at first and needed something to narrow down the
>> possibilities...
>> 
>> The reason we're obsessing about this is that it calls into question
>> how segments are merged when "things change". We don't understand why
>> this is happening at the Lucene level so don't know how to insure that
>> things like the schema API in Solr aren't affected.
>> 
>> Andrzej isn't the only one running out of ideas ;).
>> 
>> On Tue, Dec 18, 2018 at 4:46 AM Andrzej Białecki  wrote:
>>> 
>>> Hi,
>>> 
>>> I'm working on a use case where an existing Solr setup needs to migrate to 
>>> a schema that uses docValues for faceting, instead of uninversion. This 
>>> case fits into a broader subject of SOLR-12259 (Robustly upgrade indexes). 
>>> However, in this case there are two major requirements for this migration 
>>> process:
>>> 
>>> * data cannot be reindexed from scratch - I need to work with the already 
>>> indexed documents (which do contain the values needed for faceting, but 
>>> these values are simply indexed and not stored as doc values)
>>> 
>>> * indexing can’t be stopped while the schema is being changed (the 
>>> conversion process needs to work on-the-fly while the collection is online, 
>>> both for searching and for updates). Collection reloads / reopening is ok 
>>> but it’s not ok to take the collection offline for several minutes (or 
>>> hours).
>>> 
>>> Together with Erick Erickson we implemented a solution that uses 
>>> MergePolicy (actually MergePolicyFactory in Solr) to enforce re-writing of 
>>> segments that no longer match the schema, ie. don’t contain docValues in a 
>>> field where the new schema requires it. This merge policy determines what 
>>> segments need this conversion and then forces the “merging” (actually 
>>> re-writing) of these segments by first wrapping them into UninvertingReader 
>>> to supply docValues where they are required by the new schema but actually 
>>> are missing in the segment’s data. This “AddDocValuesMergePolicy” (ADVMP 
>>> for short) is supposed to deal with the following types of segments:
>>> 
>>> * old segments created before the schema change - these don’t contain any 
>>> docValues in the target fields and so they are wrapped in UninvertingReader 
>>> for merging (and for searching) according to the new schema.
>>> 
>>> * new segments created after the schema change - if FieldInfo-s for these 
>>> fields claim that the segment already contains docValues where it should 
>>> then the segment is passed as-is to merging, otherwise it’s wrapped again. 
>>> An optimisation was also put here to “mark” the already converted segments 
>>> using a marker in SegmentInfo diagnostics map so that we can avoid 
>>> re-checking and re-converting already converted data.
>>> 
>>> So, long story short, this process works very well when there’s no 
>>> concurrent indexing activity - all old segments are properly wrapped and 
>>> re-written and merging with new segments works as intended. However, in a 
>>> situation with concurrent indexing it works well but only for a short 
>>> while. At some point this conversion process seems to lose large percentage 
>>> of the docValues, even though it seems that at all points the

SOLR-12259: online index schema modification - adding docValues to existing indexed data?

[Andrzej Białecki]

Hi,

I'm working on a use case where an existing Solr setup needs to migrate to a 
schema that uses docValues for faceting, instead of uninversion. This case fits 
into a broader subject of SOLR-12259 (Robustly upgrade indexes). However, in 
this case there are two major requirements for this migration process:

* data cannot be reindexed from scratch - I need to work with the already 
indexed documents (which do contain the values needed for faceting, but these 
values are simply indexed and not stored as doc values)

* indexing can’t be stopped while the schema is being changed (the conversion 
process needs to work on-the-fly while the collection is online, both for 
searching and for updates). Collection reloads / reopening is ok but it’s not 
ok to take the collection offline for several minutes (or hours).

Together with Erick Erickson we implemented a solution that uses MergePolicy 
(actually MergePolicyFactory in Solr) to enforce re-writing of segments that no 
longer match the schema, ie. don’t contain docValues in a field where the new 
schema requires it. This merge policy determines what segments need this 
conversion and then forces the “merging” (actually re-writing) of these 
segments by first wrapping them into UninvertingReader to supply docValues 
where they are required by the new schema but actually are missing in the 
segment’s data. This “AddDocValuesMergePolicy” (ADVMP for short) is supposed to 
deal with the following types of segments:

* old segments created before the schema change - these don’t contain any 
docValues in the target fields and so they are wrapped in UninvertingReader for 
merging (and for searching) according to the new schema.

* new segments created after the schema change - if FieldInfo-s for these 
fields claim that the segment already contains docValues where it should then 
the segment is passed as-is to merging, otherwise it’s wrapped again. An 
optimisation was also put here to “mark” the already converted segments using a 
marker in SegmentInfo diagnostics map so that we can avoid re-checking and 
re-converting already converted data.

So, long story short, this process works very well when there’s no concurrent 
indexing activity - all old segments are properly wrapped and re-written and 
merging with new segments works as intended. However, in a situation with 
concurrent indexing it works well but only for a short while. At some point 
this conversion process seems to lose large percentage of the docValues, even 
though it seems that at all points the source segments are properly wrapped - 
the ADVMP merge policy adds a lot of debugging information to track the source 
and type of segments across many levels of merging and whether they were 
wrapped or not.

My working theory is that somehow this schema change produces 
“franken-segments” (while they still haven’t been flushed) where only some of 
the most recent docs have the docValues and earlier ones don’t. As I understand 
it, this should not happen in Solr because a schema change results in a core 
reload. The tracking information from ADVMP  seems to indicate that all 
generations of segments, both those that were flushed and merged earlier, have 
been properly wrapped.

My alternate theory is that there’s some bug in the doc values merging process 
when UninvertingReader is involved, because this problem occurs also when we 
modify ADVMP to always force the wrapping of all segments in 
UninvertingReader-s. The percentage of lost doc values is sometimes quite 
large, up to 50%, perhaps it’s a bug somewhere where the code accounts for the 
presence of doc values in FieldCacheImpl?

Together with Erick we implemented a bunch of tests that illustrate this issue 
- both the tests and the code can be found on branch "jira/solr-12259":

* code.tests.AddDVMPLuceneTest2 - this is a pure Lucene test that shows how doc 
values are lost after several rounds of merging while concurrent indexing is 
going on. This failure is reproducible 100%.

* code.tests.AddDvStress - this is a Solr test that repeatedly creates a 
collection without doc values, starts the indexing, changes the config to use 
ADVMP, makes the schema change to turn doc values on, and verifies the number 
of facets on the target field. This test also fails after a while with the same 
symptoms as the Lucene one, so I think that solving the Lucene test failure 
should solve this failure too.

Any suggestions or insights are very much appreciated - I'm running out of 
ideas to try...

—

Andrzej Białecki

Re: Lucene/Solr 7.6

[Andrzej Białecki]

Hi Nicholas,

If it’s ok I would like to merge a small fix to the Ref Guide, spotted by 
Christine in SOLR-9856.

> On 1 Nov 2018, at 21:38, Nicholas Knize  wrote:
> 
> Hi all,
> 
> To follow up from our discussion on the 8.0 thread, I would like to cut the 
> 7.6 branch on either Tuesday or Wednesday of next week. Since this implies 
> feature freeze I went ahead and had a look at some of the issues that are 
> labeled for 7.6.
> 
> It looks like we only have one active issue listed as a blocker for Solr. The 
> upgrade notes in SOLR-12927 <https://issues.apache.org/jira/browse/SOLR-12927>
> 
> For Lucene we have five active issues (each with a patch provided) listed as 
> blockers targeted for 7.6.
> 
> If there are any other issues that need to land before cutting the branch, 
> and they are not already labeled, please either mark them as blockers 
> accordingly or let me know prior to cutting the branch next Tuesday or 
> Wednesday.
> 
> Thank you!
> 
> - Nick
> -- 
> Nicholas Knize, Ph.D., GISP
> Geospatial Software Guy  |  Elasticsearch
> Apache Lucene Committer
> nkn...@apache.org <mailto:nkn...@apache.org>  
> 



—

Andrzej Białecki

Re: [VOTE] Release Lucene/Solr 7.5.0 RC1

[Andrzej Białecki]

+1

SUCCESS! [1:42:09.201482]

> On 19 Sep 2018, at 03:56, Shalin Shekhar Mangar  
> wrote:
> 
> +1
> 
> SUCCESS! [0:49:21.932804]
> 
> On Tue, Sep 18, 2018 at 9:39 PM jim ferenczi  <mailto:jim...@apache.org>> wrote:
> Please vote for release candidate 1 for Lucene/Solr 7.5.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
>  
> <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df>
> 
> 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-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df
>  
> <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df>
> 
> Here's my +1
> SUCCESS! [1:33:42.884535]
> 
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.



—

Andrzej Białecki

Re: Lucene/Solr 7.5

[Andrzej Białecki]

SOLR-12765 has been committed now to master, branch_7x, branch_7_5 and 
branch_7_4. Thanks!

> On 17 Sep 2018, at 14:14, jim ferenczi  wrote:
> 
> Hi,
> 
> Andrzej, there is another issue in the queue (LUCENE-8502) so I'll wait one 
> more day to build the first RC., please backport the fix for the JMX beans. 
> Cassandra, I backported the Tika version change in the docs, if SOLR-12771 is 
> merged today I'll include it in the RC tomorrow. 
> 
> Le lun. 17 sept. 2018 à 13:57, Andrzej Białecki  <mailto:a...@getopt.org>> a écrit :
> Hi Jim,
> 
> I’d like to commit a fix for SOLR-12765 where a side-effect from other issue 
> changed the format of some JMX beans.
> 
>> On 14 Sep 2018, at 23:25, jim ferenczi > <mailto:jim.feren...@gmail.com>> wrote:
>> 
>> Sorry for the late reply. I built the first RC earlier today and had some 
>> issues to pass the smoke tests. Most of the issue were on my end but I had 
>> to open https://issues.apache.org/jira/browse/LUCENE-8500 
>> <https://issues.apache.org/jira/browse/LUCENE-8500> to fix an actual bug. 
>> SCassandra, the issue is in the smoke tester so I don't know if we need a 
>> respin but I didn't send the artifacts so I can just rebuild RC1 with 
>> LUCENE-8500 when it's merged. In the meantime don't hesitate to merge the 
>> doc changes regarding Tika. Steve I can wait Tuesday to rebuild RC1 if you 
>> think it's worth waiting, otherwise if the smoke tests are fixed I'll 
>> proceed on Monday.
>> 
>> Le ven. 14 sept. 2018 à 21:01, Steve Rowe > <mailto:sar...@gmail.com>> a écrit :
>> Hi Jim,
>> 
>> I put the Solr ref guide edits Cassandra referred to in a patch on 
>> SOLR-12771, but as I mentioned in a comment there, I’d like to get Hoss’ss 
>> input before I commit, and he’s taking today off, so it’ll probably be 
>> Monday before he’ll have a chance to look at it.
>> 
>> So in short, please don’t delay building the RC for SOLR-12771.
>> 
>> --
>> Steve
>> www.lucidworks.com <http://www.lucidworks.com/>
>> 
>> > On Sep 14, 2018, at 8:40 AM, Cassandra Targett > > <mailto:casstarg...@gmail.com>> wrote:
>> > 
>> > Hi Jim, 
>> > 
>> > Are you working on the RC now? Overnight I discovered two really minor 
>> > things: first, there's an error in CHANGES.txt regarding the Tika version 
>> > that I mentioned in SOLR-12551 - Erick told me offline to go ahead and fix 
>> > it. Second, Steve has some edits he'd like to get in for the Solr Ref 
>> > Guide he also sent me offline.
>> > 
>> > Neither have very much impact, but both could probably wait until/if there 
>> > is a respin of the RC - basically if you haven't started the RC yet I'll 
>> > push those through. But if you have started I'll wait.
>> > 
>> > Thanks,
>> > Cassandra
>> > 
>> > On Thu, Sep 13, 2018 at 3:30 AM jim ferenczi > > <mailto:jim.feren...@gmail.com>> wrote:
>> > Sure you can backport Tomás, the first RC is planned for tomorrow.
>> > 
>> > Le jeu. 13 sept. 2018 à 00:10, Tomás Fernández Löbbe 
>> > mailto:tomasflo...@gmail.com>> a écrit :
>> > Hi Jim,
>> > I'd like to commit SOLR-12766 to 7.5. SOLR-11881 added retries for 
>> > internal requests, but the backoff time in cases with multiple updates can 
>> > become big, and cause clients to timeout. The change is minimal, just 
>> > backoff once for a retry batch instead of for every doc.
>> > 
>> > I'm testing a patch and plan to commit later today, if there aren't any 
>> > issues or objections. 
>> > 
>> > On Wed, Sep 12, 2018 at 5:39 AM jim ferenczi > > <mailto:jim.feren...@gmail.com>> wrote:
>> > Thanks !
>> > 
>> > Le mer. 12 sept. 2018 à 11:49, Adrien Grand > > <mailto:jpou...@gmail.com>> a écrit :
>> > Hey Jim,
>> > 
>> > I added you to the hudson-jobadmin group so that you can do it next time.
>> > 
>> > Steve, thanks for taking care of setting up the builds!
>> > 
>> > Le mar. 11 sept. 2018 à 17:32, jim ferenczi > > <mailto:jim.feren...@gmail.com>> a écrit :
>> > No worries at all Cassandra. What do you think of building the first RC on 
>> > Friday and start the vote on Monday next week ? This will leave some
>> > room to finish the missing bits. 
>> > Could someone help to setup the Jenkins releases build ? It seems that I 
>> > cannot create jobs with my account.
>> > 
>> &

Re: Lucene/Solr 7.5

[Andrzej Białecki]

just RM choice? From a personal perspective, I much prefer 
> > >> >>> that model because the Ref Guide requires A LOT of my attention and 
> > >> >>> my work there kicks into high gear as soon as a release is proposed.
> > >> >>>
> > >> >>> Even though the artifact and Ref Guide release processes are 
> > >> >>> separate today, we want them to be a single process, so I need to 
> > >> >>> act as though your timeframe for the RC is the deadline for Ref 
> > >> >>> Guide edits to do an RC of the Ref Guide at the same time. That 
> > >> >>> means I'm on your timetable, no matter what else I may have promised 
> > >> >>> to my bosses and colleagues. It's stressful already to try to get it 
> > >> >>> all done - I usually don't finish everything I want to do - and 
> > >> >>> adding the burden of having to backport everything to 2 branches 
> > >> >>> instead of 1 just makes it tedious as well.
> > >> >>>
> > >> >>> Also, yesterday was a major holiday in the US, and as of this moment 
> > >> >>> it's not even noon on the East Coast, so there's a percentage of the 
> > >> >>> community who may not even have seen your proposal yet.
> > >> >>>
> > >> >>> I greatly appreciate that you've volunteered to do the release and 
> > >> >>> are energized to get it rolling, but is there a reason an RC has to 
> > >> >>> be done by the beginning of next week?
> > >> >>>
> > >> >>> On Tue, Sep 4, 2018 at 10:36 AM Joel Bernstein  > >> >>> <mailto:joels...@gmail.com>> wrote:
> > >> >>>>
> > >> >>>> +1,
> > >> >>>>
> > >> >>>> I'll likely be adding some Solr RefGuide changes later in the week 
> > >> >>>> to the 7.5 branch but I'll make sure they don't effect the build.
> > >> >>>>
> > >> >>>>
> > >> >>>> Joel Bernstein
> > >> >>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
> > >> >>>>
> > >> >>>>
> > >> >>>> On Tue, Sep 4, 2018 at 10:52 AM jim ferenczi 
> > >> >>>> mailto:jim.feren...@gmail.com>> wrote:
> > >> >>>>>
> > >> >>>>> Thanks all,
> > >> >>>>> since there are no objections I am planning to cut the branch for 
> > >> >>>>> 7.5 tomorrow. I'll build the first RC early next week so there 
> > >> >>>>> will be some room to merge important bug fixes later this week. 
> > >> >>>>> All blockers except SOLR-12727 seem to be merged/resolved, I'll 
> > >> >>>>> watch the remaining solr issue for updates.
> > >> >>>>>
> > >> >>>>> Le mar. 4 sept. 2018 à 10:21, jim ferenczi  > >> >>>>> <mailto:jim.feren...@gmail.com>> a écrit :
> > >> >>>>>>
> > >> >>>>>> Sure Jan, this is a nice cleanup, +1 to backport in 7x.
> > >> >>>>>>
> > >> >>>>>> Le mar. 4 sept. 2018 à 10:16, Jan Høydahl  > >> >>>>>> <mailto:jan@cominvent.com>> a écrit :
> > >> >>>>>>>
> > >> >>>>>>> Jim, we have some release process improvements in LUCENE-5143. 
> > >> >>>>>>> Basically, we'll only have one KEYS file instead of three plus 
> > >> >>>>>>> those in the versioned folders that we have today. And the 
> > >> >>>>>>> release py script will start checking that the RM's key is 
> > >> >>>>>>> present in the KEYS file. Would you be ok with that being 
> > >> >>>>>>> committed and you being the first RM to use it for 7.5.0?
> > >> >>>>>>>
> > >> >>>>>>> --
> > >> >>>>>>> Jan Høydahl, search solution architect
> > >> >>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
> > >> >>>>>>>
> > >> >>>>>>> 3. sep. 2018 kl. 10:42 skrev jim ferenczi 
> > >> >>>>>>> mailto:jim.feren...@gmail.com>>:
> > >> >>>>>>>
> > >> >>>>>>> Hi all,
> > >> >>>>>>>
> > >> >>>>>>> 7.4 has been released two months ago on June 29th and we have 
> > >> >>>>>>> new features, enhancements and fixes that are not released yet 
> > >> >>>>>>> so I'd like to start working on releasing Lucene/Solr 7.5.0.
> > >> >>>>>>> There's also a bad bug with index sorting that deletes the wrong 
> > >> >>>>>>> documents when delete by query is used:
> > >> >>>>>>> https://issues.apache.org/jira/browse/LUCENE-8466 
> > >> >>>>>>> <https://issues.apache.org/jira/browse/LUCENE-8466>
> > >> >>>>>>>
> > >> >>>>>>> I can create the 7.5 branch later this week and build the first 
> > >> >>>>>>> RC early next week if that works for everyone. Please let me 
> > >> >>>>>>> know if there are bug fixes that needs to be fixed in 7.5 and 
> > >> >>>>>>> might not be ready by then.
> > >> >>>>>>>
> > >> >>>>>>> Cheers,
> > >> >>>>>>> Jim
> > >> >>>>>>>
> > >> >>>>>>>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > >> <mailto:dev-unsubscr...@lucene.apache.org>
> > >> For additional commands, e-mail: dev-h...@lucene.apache.org 
> > >> <mailto:dev-h...@lucene.apache.org>
> > >>
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > <mailto:dev-unsubscr...@lucene.apache.org>
> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > <mailto:dev-h...@lucene.apache.org>
> > 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> <mailto:dev-unsubscr...@lucene.apache.org>
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> <mailto:dev-h...@lucene.apache.org>
> 



—

Andrzej Białecki

Re: [DISCUSS] Request for review of proposed LUCENE/SOLR JIRA workflow change

[Andrzej Białecki]

> On 3 Jul 2018, at 17:42, Steve Rowe  wrote:
> 
> I forgot to mention on this thread that the “In Progress” status, and the 
> buttons to control that (“Start Progress”/“Stop Progress”) were removed from 
> the LUCENE/SOLR workflow because:
> 
> a) Leaving the progress buttons caused the patch review buttons to be hidden; 
> and
> b) I thought the Progress stuff wasn’t really being used much by anybody.
> 
> (The discussion I had with Gavin McDonald about this apparently was only on 
> Hipchat, so I can’t point people to it since they purposely don’t keep 
> history.  I should have included that in the issue commentary.)
> 
> However, Andrzej Bialecki told me offline that he *did* use the Progress 
> stuff.
> 
> So: should the Progress elements of the workflow be put back?  At a minimum, 
> even if we don’t put the buttons back because of conflicts with the patch 
> review buttons, we could re-instate the status and allow it to be set from 
> the “More” menu or similar.


I did use it … but I can change my workflow as long as there’s a consensus on 
what is the expected method for letting the community know that I’m actively 
working on something. Steve mentioned to me that these buttons interfered with 
the automatic patch review buttons, and I’d rather have these than the progress 
buttons.

I can always add a comment to indicate that “I just started working on this 
issue again” and “eh, life interfered and I’m not going to work on this for a 
while” … but clicking the buttons required less effort and made less noise ;)

> 
> --
> Steve
> www.lucidworks.com
> 
>> On Jun 28, 2018, at 7:48 PM, Steve Rowe  wrote:
>> 
>> The new workflow is now enabled for LUCENE and SOLR JIRA projects.
>> 
>> The new workflow differs in a few respects from my previous summary - see 
>> details inline below:
>> 
>>> On Jun 19, 2018, at 1:53 PM, Steve Rowe  wrote:
>>> 
>>> Summary of the workflow changes: 
>>> 
>>> 1. The “Submit Patch” button will be relabeled “Attach Patch”, and will 
>>> bring up the dialog to attach a patch, with a simultaneous comment (rather 
>>> than just changing the issue status).  This button will remain visible 
>>> regardless of issue status, so that it can be used to attach more patches.
>> 
>> The new button label was changed to “Attach Files”, since it can be used to 
>> attach non-patch files.
>> 
>>> 2. In the “Attach Patch” dialog, there will be a checkbox labeled “Enable 
>>> Automatic Patch Validation”, which will be checked by default. If checked, 
>>> the issue’s status will transition to “Patch Available” (which signals 
>>> Yetus to perform automatic patch validation); if not checked, the patch 
>>> will be attached but no status transition will occur. NOTE: Gavin is still 
>>> working on adding this checkbox, so it’s not demo’d on INFRATEST1 issues 
>>> yet, but he says it’s doable and that he’ll work on it tomorrow, Australia 
>>> time.
>> 
>> Since Gavin couldn’t get the “Enable Automatic Patch Validation” checkbox 
>> functionality to work, attaching a file using the “Attach Files” dialog will 
>> never perform any status transitions at all.  Instead, users will 
>> enable/disable automatic patch validation via the “Enable Patch Review” and 
>> “Cancel Patch Review” buttons.
>> 
>>> 3. When in “Patch Available” status, a button labeled “Cancel Patch Review” 
>>> will be visible; clicking on it will transition the issue status to “Open”, 
>>> thus disabling automatic patch review.
>>> 
>>> 4. The “Start Progress”/“Stop Progress”/“In Progress” aspects of the 
>>> workflow have been removed, because if they remain, JIRA creates a 
>>> “Workflow” menu and puts the “Attach Patch” button under it, which kind of 
>>> defeats its purpose: an obvious way to submit contributions. I asked Gavin 
>>> to remove the “Progress” related aspects of the workflow because I don’t 
>>> think they’re being used except on a limited ad-hoc basis, not part of a 
>>> conventional workflow.
>>> -
>>> 
>>> Separate issue: on the thread where Cassandra moved the “Enviroment” field 
>>> below “Description” on the Create JIRA dialog[4], David Smiley wrote[5]:
>>> 
 ok and these Lucene Fields, two checkboxes, New and Patch Available... I 
 just don't think we really use this but I should raise this separately.
>>> 
>>> I think we should remove these.  In a chat on Infra Hipchat, Gavin offered 
>>> to do this, but since the Lucene PMC has control of this (as part of 
>>> “screen configuration”, which is separate from “workflow” configuration), I 
>>> told him we would tackle it ourselves.
>> 
>> I’ll make a JIRA for this.
>> 
>>> [1] Enable Yetus for LUCENE/SOLR: 
>>> https://issues.apache.org/jira/browse/INFRA-15213
>>> [2] Modify LUCENE/SOLR Yetus-enabling workflow: 
>>> https://issues.apache.org/jira/browse/INFRA-16094
>>> [3] Demo of proposed LUCENE/SOLR workflow: 
>>> https://issues.apache.org/jira/projects/INFRATEST1
>>> [4] Cassandra fixes Create JIRA dialog: 
>>> 

Re: Lucene/Solr 7.4

[Andrzej Białecki]

> On 13 Jun 2018, at 19:41, Andrzej Białecki  
> wrote:
> 
> Hi,
> 
> I’d like to also commit a minor patch that reduces logging from 
> MetricsHistoryHandler and fixes incorrect index size conversion there (this 
> is a follow-up to SOLR-12438).

Make that SOLR-11779, that’s where the problem was reported - but they are both 
about the same component.

> 
>> On 13 Jun 2018, at 19:08, Adrien Grand > <mailto:jpou...@gmail.com>> wrote:
>> 
>> OK to backport SOLR-12434.
>> 
>> Le mer. 13 juin 2018 à 18:41, Steve Rowe > <mailto:sar...@gmail.com>> a écrit :
>> Adrien,
>> 
>> Are you okay with backporting SOLR-12434 to 7.4?
>> 
>> --
>> Steve
>> www.lucidworks.com <http://www.lucidworks.com/>
>> 
>> > On Jun 12, 2018, at 9:37 AM, Steve Rowe > > <mailto:sar...@gmail.com>> wrote:
>> > 
>> > Done, thanks Adrien.
>> > 
>> > --
>> > Steve
>> > www.lucidworks.com <http://www.lucidworks.com/>
>> > 
>> >> On Jun 12, 2018, at 9:23 AM, Adrien Grand > >> <mailto:jpou...@gmail.com>> wrote:
>> >> 
>> >> +1 to backport LUCENE-8278 to 7.4. Thanks Steve.
>> >> 
>> >> Le lun. 11 juin 2018 à 23:21, Steve Rowe > >> <mailto:sar...@gmail.com>> a écrit :
>> >> Adrien,
>> >> 
>> >> Are you okay with including the fix on LUCENE-8278 in 7.4?
>> >> 
>> >> --
>> >> Steve
>> >> www.lucidworks.com <http://www.lucidworks.com/>
>> >> 
>> >>> On Jun 11, 2018, at 11:24 AM, Adrien Grand > >>> <mailto:jpou...@gmail.com>> wrote:
>> >>> 
>> >>> No worries Uwe, we'll wait. Enjoy Buzzwords!
>> >>> 
>> >>> Le lun. 11 juin 2018 à 17:08, Uwe Schindler > >>> <mailto:u...@thetaphi.de>> a écrit :
>> >>> I still have this new security issue and to fix it finally everywhere, 
>> >>> it requires API changes. So please wait, I am working but buzzwords is 
>> >>> so interesting! 勞
>> >>> 
>> >>> Uwe
>> >>> 
>> >>> 
>> >>> Am June 11, 2018 2:45:54 PM UTC schrieb David Smiley 
>> >>> mailto:david.w.smi...@gmail.com>>:
>> >>> It'd be nice to get in this bug 
>> >>> https://issues.apache.org/jira/browse/LUCENE-8344 
>> >>> <https://issues.apache.org/jira/browse/LUCENE-8344> but is pending a 
>> >>> review.
>> >>> 
>> >>> On Tue, Jun 5, 2018 at 4:24 AM Adrien Grand > >>> <mailto:jpou...@gmail.com>> wrote:
>> >>> Hi all,
>> >>> 
>> >>> We released 7.3 two months ago on April 4th and we accumulated quite a 
>> >>> number of features, enhancements and fixes that are not released yet, so 
>> >>> I'd like to start working on releasing Lucene/Solr 7.4.0.
>> >>> 
>> >>> I propose to create the 7.4 branch later this week and build the first 
>> >>> RC early next week if that works for everyone. Please let me know if 
>> >>> that are bug fixes that we think should make it to 7.4 and might not be 
>> >>> ready by then.
>> >>> 
>> >>> Adrien
>> >>> -- 
>> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker 
>> >>> <https://maps.google.com/?q=Developer,+Author,+Speaker=gmail=g>
>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley 
>> >>> <http://linkedin.com/in/davidwsmiley> | Book: 
>> >>> http://www.solrenterprisesearchserver.com 
>> >>> <http://www.solrenterprisesearchserver.com/>
>> >>> 
>> >>> --
>> >>> Uwe Schindler
>> >>> Achterdiek 19, 28357 Bremen
>> >>> https://www.thetaphi.de <https://www.thetaphi.de/>
>> >> 
>> >> 
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> >> <mailto:dev-unsubscr...@lucene.apache.org>
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> >> <mailto:dev-h...@lucene.apache.org>
>> >> 
>> > 
>> 
> 

Re: Lucene/Solr 7.4

[Andrzej Białecki]

Hi,

I’d like to also commit a minor patch that reduces logging from 
MetricsHistoryHandler and fixes incorrect index size conversion there (this is 
a follow-up to SOLR-12438).

> On 13 Jun 2018, at 19:08, Adrien Grand  wrote:
> 
> OK to backport SOLR-12434.
> 
> Le mer. 13 juin 2018 à 18:41, Steve Rowe  > a écrit :
> Adrien,
> 
> Are you okay with backporting SOLR-12434 to 7.4?
> 
> --
> Steve
> www.lucidworks.com 
> 
> > On Jun 12, 2018, at 9:37 AM, Steve Rowe  > > wrote:
> > 
> > Done, thanks Adrien.
> > 
> > --
> > Steve
> > www.lucidworks.com 
> > 
> >> On Jun 12, 2018, at 9:23 AM, Adrien Grand  >> > wrote:
> >> 
> >> +1 to backport LUCENE-8278 to 7.4. Thanks Steve.
> >> 
> >> Le lun. 11 juin 2018 à 23:21, Steve Rowe  >> > a écrit :
> >> Adrien,
> >> 
> >> Are you okay with including the fix on LUCENE-8278 in 7.4?
> >> 
> >> --
> >> Steve
> >> www.lucidworks.com 
> >> 
> >>> On Jun 11, 2018, at 11:24 AM, Adrien Grand  >>> > wrote:
> >>> 
> >>> No worries Uwe, we'll wait. Enjoy Buzzwords!
> >>> 
> >>> Le lun. 11 juin 2018 à 17:08, Uwe Schindler  >>> > a écrit :
> >>> I still have this new security issue and to fix it finally everywhere, it 
> >>> requires API changes. So please wait, I am working but buzzwords is so 
> >>> interesting! 勞
> >>> 
> >>> Uwe
> >>> 
> >>> 
> >>> Am June 11, 2018 2:45:54 PM UTC schrieb David Smiley 
> >>> mailto:david.w.smi...@gmail.com>>:
> >>> It'd be nice to get in this bug 
> >>> https://issues.apache.org/jira/browse/LUCENE-8344 
> >>>  but is pending a 
> >>> review.
> >>> 
> >>> On Tue, Jun 5, 2018 at 4:24 AM Adrien Grand  >>> > wrote:
> >>> Hi all,
> >>> 
> >>> We released 7.3 two months ago on April 4th and we accumulated quite a 
> >>> number of features, enhancements and fixes that are not released yet, so 
> >>> I'd like to start working on releasing Lucene/Solr 7.4.0.
> >>> 
> >>> I propose to create the 7.4 branch later this week and build the first RC 
> >>> early next week if that works for everyone. Please let me know if that 
> >>> are bug fixes that we think should make it to 7.4 and might not be ready 
> >>> by then.
> >>> 
> >>> Adrien
> >>> -- 
> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker 
> >>> 
> >>> LinkedIn: http://linkedin.com/in/davidwsmiley 
> >>>  | Book: 
> >>> http://www.solrenterprisesearchserver.com 
> >>> 
> >>> 
> >>> --
> >>> Uwe Schindler
> >>> Achterdiek 19, 28357 Bremen
> >>> https://www.thetaphi.de 
> >> 
> >> 
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> >> 
> >> For additional commands, e-mail: dev-h...@lucene.apache.org 
> >> 
> >> 
> > 
> 

Re: BadApple report

[Andrzej Białecki]

> On 12 Jun 2018, at 09:01, Adrien Grand  wrote:
> 
> Hi Andrzej,
> 
> I'm seeing a fix commit for SolrRrdBackendFactoryTest but not for 
> IndexSizeTriggerTest. The reason I'm looking is that the 7.4 smokerelease 
> build failed on IndexSizeTriggerTest so I wanted to check whether the fix had 
> been backported there.
> 

It is now :)

(btw. at the moment this test is failing on master / branch_7x as a result of 
incomplete fix for SOLR-12208, which is not scheduled for 7.4)

> Le lun. 11 juin 2018 à 22:33, Andrzej Białecki 
> mailto:andrzej.biale...@lucidworks.com>> a 
> écrit :
> 
> 
>> On 11 Jun 2018, at 17:51, Erick Erickson > <mailto:erickerick...@gmail.com>> wrote:
>> 
>> IndexSizeTriggerTest.testMixedBounds
> 
> I committed a change today that should fix this.
> 
>> SearchRateTriggerTest.testTrigger
> 
>> TestLargeCluster.testBasic
>> TestLargeCluster.testNodeLost
> 
> On June 6 I made a change that should fix these tests.
> 
> --
> Best regards,
> Andrzej Bialecki
> 
> --=# http://www.lucidworks.com <http://www.lucidworks.com/> #=--
> 

Re: BadApple report

[Andrzej Białecki]

> On 11 Jun 2018, at 17:51, Erick Erickson  wrote:
> 
> IndexSizeTriggerTest.testMixedBounds

I committed a change today that should fix this.

> SearchRateTriggerTest.testTrigger

> TestLargeCluster.testBasic
> TestLargeCluster.testNodeLost

On June 6 I made a change that should fix these tests.

--
Best regards,
Andrzej Bialecki

--=# http://www.lucidworks.com #=--

Re: Lucene/Solr 7.4

[Andrzej Białecki]

> On 7 Jun 2018, at 14:27, Adrien Grand  wrote:
> 
> I read quickly and assumed there was still work left since it was still open, 
> but if it's merged already it's perfect. I don't have enough background to 
> know whether SOLR-12438 is safe but I'll trust your judgement.

I left it open because ultimately we want to upgrade to 4.0.2, which we’re 
unable to do at the moment due to some missing artifacts in Maven repo. It may 
have been confusing … I’ll close this issue and create a separate one for the 
next upgrade.

I’ll do some beasting of the other patch and if it works ok I’ll commit it by 
tomorrow.

> 
> Le jeu. 7 juin 2018 à 14:25, Andrzej Białecki 
> mailto:andrzej.biale...@lucidworks.com>> a 
> écrit :
> Hi Adrien,
> 
> Did you mean SOLR-12438? I pushed SOLR-12445 just before you created a 
> branch, so it’s already there. However, I upgraded SOLR-12438 to a Bug, 
> because accidentally some of the responses from that handler were improperly 
> serialised (as arrays instead of maps). Since this is a fix for a new feature 
> in 7.4 I think it makes sense to commit this fix too. 
> 
> 
>> On 7 Jun 2018, at 10:31, Adrien Grand > <mailto:jpou...@gmail.com>> wrote:
>> 
>> Hello,
>> 
>> I just pushed a branch_7_4. Please do not push features or enhancements to 
>> this branch, however it's totally fine to keep pushing bugfixes to it, 
>> though we should be careful if these fixes are not unlikely to introduce 
>> other bugs. Andrzej, I see SOLR-12445 is marked as an enhancement in JIRA, 
>> but it's fine to push it to branch_6_4.
>> 
>> Le mer. 6 juin 2018 à 20:56, Cassandra Targett > <mailto:casstarg...@gmail.com>> a écrit :
>> Oh, OK, I see our disconnect. This week is fine, even if it's on the larger 
>> side. I just meant if someone *does* have big changes, they should start 
>> sooner rather than later. IOW, don't wait until next week or later.
>> 
>> (Part of what motivated my message is I saw a comment in an issue earlier 
>> that said there would be time between 7.4 release and Ref Guide release to 
>> work on docs - that's what I don't want to happen.)
>> 
>> On Wed, Jun 6, 2018 at 12:48 PM David Smiley > <mailto:david.w.smi...@gmail.com>> wrote:
>> Roger; but I don't think this simultaneous release means that ref guide 
>> edits this week are not welcome?  Risky/big changes are not welcome I assume.
>> 
>> On Wed, Jun 6, 2018 at 1:35 PM Cassandra Targett > <mailto:casstarg...@gmail.com>> wrote:
>> Well, I know some people don't update docs with their code changes for 
>> whatever their reasons are, so I just wanted to remind folks that for 7.2 
>> the Ref Guide was released at the same time, and I intend this one to be 
>> too. Not sure if the goal of merging these release processes was widely 
>> understood yet, so didn't want to assume and catch people unaware.
>> 
>> On Wed, Jun 6, 2018 at 12:23 PM David Smiley > <mailto:david.w.smi...@gmail.com>> wrote:
>> >  I'd suggest to anyone holding off on doc edits to try to make some time 
>> > in the next few days, if possible.
>> 
>> What's the concern?
>> 
>> On Wed, Jun 6, 2018 at 9:57 AM Cassandra Targett > <mailto:casstarg...@gmail.com>> wrote:
>> +1, thanks Adrien.
>> 
>> As with the last release, I plan to produce the Solr Ref Guide RC on the 
>> same day the 7.4 RC is available, so I'd suggest to anyone holding off on 
>> doc edits to try to make some time in the next few days, if possible.
>> 
>> On Wed, Jun 6, 2018 at 4:59 AM Adrien Grand > <mailto:jpou...@gmail.com>> wrote:
>> +1
>> 
>> Le mer. 6 juin 2018 à 11:53, Andrzej Białecki 
>> mailto:andrzej.biale...@lucidworks.com>> a 
>> écrit :
>> Hi Adrien,
>> 
>> I would like to upgrade the metrics library to 3.2.6, which fixes an 
>> important bug affecting histograms (SOLR-12445).
>> 
>> 
>>> On 6 Jun 2018, at 08:01, Dawid Weiss >> <mailto:dawid.we...@gmail.com>> wrote:
>>> 
>>> +1. Thanks Adrien.
>>> 
>>> 
>>> On Wed, Jun 6, 2018 at 12:01 AM, Varun Thacker >> <mailto:va...@vthacker.in>> wrote:
>>>> +1
>>>> 
>>>> On Tue, Jun 5, 2018 at 1:24 AM, Adrien Grand >>> <mailto:jpou...@gmail.com>> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> We released 7.3 two months ago on April 4th and we accumulated quite a
>>>>> number of features, enhancements and fixes that are not released yet, so 
>>>&g

Re: Lucene/Solr 7.4

[Andrzej Białecki]

Hi Adrien,

Did you mean SOLR-12438? I pushed SOLR-12445 just before you created a branch, 
so it’s already there. However, I upgraded SOLR-12438 to a Bug, because 
accidentally some of the responses from that handler were improperly serialised 
(as arrays instead of maps). Since this is a fix for a new feature in 7.4 I 
think it makes sense to commit this fix too. 

> On 7 Jun 2018, at 10:31, Adrien Grand  wrote:
> 
> Hello,
> 
> I just pushed a branch_7_4. Please do not push features or enhancements to 
> this branch, however it's totally fine to keep pushing bugfixes to it, though 
> we should be careful if these fixes are not unlikely to introduce other bugs. 
> Andrzej, I see SOLR-12445 is marked as an enhancement in JIRA, but it's fine 
> to push it to branch_6_4.
> 
> Le mer. 6 juin 2018 à 20:56, Cassandra Targett  <mailto:casstarg...@gmail.com>> a écrit :
> Oh, OK, I see our disconnect. This week is fine, even if it's on the larger 
> side. I just meant if someone *does* have big changes, they should start 
> sooner rather than later. IOW, don't wait until next week or later.
> 
> (Part of what motivated my message is I saw a comment in an issue earlier 
> that said there would be time between 7.4 release and Ref Guide release to 
> work on docs - that's what I don't want to happen.)
> 
> On Wed, Jun 6, 2018 at 12:48 PM David Smiley  <mailto:david.w.smi...@gmail.com>> wrote:
> Roger; but I don't think this simultaneous release means that ref guide edits 
> this week are not welcome?  Risky/big changes are not welcome I assume.
> 
> On Wed, Jun 6, 2018 at 1:35 PM Cassandra Targett  <mailto:casstarg...@gmail.com>> wrote:
> Well, I know some people don't update docs with their code changes for 
> whatever their reasons are, so I just wanted to remind folks that for 7.2 the 
> Ref Guide was released at the same time, and I intend this one to be too. Not 
> sure if the goal of merging these release processes was widely understood 
> yet, so didn't want to assume and catch people unaware.
> 
> On Wed, Jun 6, 2018 at 12:23 PM David Smiley  <mailto:david.w.smi...@gmail.com>> wrote:
> >  I'd suggest to anyone holding off on doc edits to try to make some time in 
> > the next few days, if possible.
> 
> What's the concern?
> 
> On Wed, Jun 6, 2018 at 9:57 AM Cassandra Targett  <mailto:casstarg...@gmail.com>> wrote:
> +1, thanks Adrien.
> 
> As with the last release, I plan to produce the Solr Ref Guide RC on the same 
> day the 7.4 RC is available, so I'd suggest to anyone holding off on doc 
> edits to try to make some time in the next few days, if possible.
> 
> On Wed, Jun 6, 2018 at 4:59 AM Adrien Grand  <mailto:jpou...@gmail.com>> wrote:
> +1
> 
> Le mer. 6 juin 2018 à 11:53, Andrzej Białecki 
> mailto:andrzej.biale...@lucidworks.com>> a 
> écrit :
> Hi Adrien,
> 
> I would like to upgrade the metrics library to 3.2.6, which fixes an 
> important bug affecting histograms (SOLR-12445).
> 
> 
>> On 6 Jun 2018, at 08:01, Dawid Weiss > <mailto:dawid.we...@gmail.com>> wrote:
>> 
>> +1. Thanks Adrien.
>> 
>> 
>> On Wed, Jun 6, 2018 at 12:01 AM, Varun Thacker > <mailto:va...@vthacker.in>> wrote:
>>> +1
>>> 
>>> On Tue, Jun 5, 2018 at 1:24 AM, Adrien Grand >> <mailto:jpou...@gmail.com>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> We released 7.3 two months ago on April 4th and we accumulated quite a
>>>> number of features, enhancements and fixes that are not released yet, so 
>>>> I'd
>>>> like to start working on releasing Lucene/Solr 7.4.0.
>>>> 
>>>> I propose to create the 7.4 branch later this week and build the first RC
>>>> early next week if that works for everyone. Please let me know if that are
>>>> bug fixes that we think should make it to 7.4 and might not be ready by
>>>> then.
>>>> 
>>>> Adrien
>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> <mailto:dev-unsubscr...@lucene.apache.org>
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> <mailto:dev-h...@lucene.apache.org>
>> 
> 
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
> <http://linkedin.com/in/davidwsmiley> | Book: 
> http://www.solrenterprisesearchserver.com 
> <http://www.solrenterprisesearchserver.com/>-- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
> <http://linkedin.com/in/davidwsmiley> | Book: 
> http://www.solrenterprisesearchserver.com 
> <http://www.solrenterprisesearchserver.com/>

Re: Lucene/Solr 7.4

[Andrzej Białecki]

Hi Adrien,

I would like to upgrade the metrics library to 3.2.6, which fixes an important 
bug affecting histograms (SOLR-12445).

> On 6 Jun 2018, at 08:01, Dawid Weiss  wrote:
> 
> +1. Thanks Adrien.
> 
> 
> On Wed, Jun 6, 2018 at 12:01 AM, Varun Thacker  wrote:
>> +1
>> 
>> On Tue, Jun 5, 2018 at 1:24 AM, Adrien Grand  wrote:
>>> 
>>> Hi all,
>>> 
>>> We released 7.3 two months ago on April 4th and we accumulated quite a
>>> number of features, enhancements and fixes that are not released yet, so I'd
>>> like to start working on releasing Lucene/Solr 7.4.0.
>>> 
>>> I propose to create the 7.4 branch later this week and build the first RC
>>> early next week if that works for everyone. Please let me know if that are
>>> bug fixes that we think should make it to 7.4 and might not be ready by
>>> then.
>>> 
>>> Adrien
>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: Not adding badapples this week.

[Andrzej Białecki]

Yesterday I committed several fixes to the simulation package, which should 
improve reliability of these tests. If these failures still persist we should 
BadApple the ones that keep failing.

> On 5 Jun 2018, at 10:14, Adrien Grand  wrote:
> 
> Thanks Steve. IndexSizeTriggerTest seems to be the test that fails most often 
> on this build indeed.
> 
> Le lun. 4 juin 2018 à 19:30, Steve Rowe  <mailto:sar...@gmail.com>> a écrit :
> I looked at the way that tests are run, an tthe only difference I see in the 
> smoke tester jobs is that tests are run twice, once each for Java8 and Java9. 
>  Compared to non-smoke-tester jobs, this will double the likelihood of 
> overall failure.
> 
> I looked at the suites that failed in the last ten runs on those two smoke 
> tester jobs.  Except for SearchHandlerTest, which I have since (hopefully) 
> fixed, there are seven suites with failed tests - here they are along with 
> their packages:
> 
>   TestExecutePlanAction o.a.s.cloud.autoscaling.sim
>   TestComputePlanAction o.a.s.cloud.autoscaling.sim
>   TestTriggerIntegrationo.a.s.cloud.autoscaling.sim
>   IndexSizeTriggerTest  o.a.s.cloud.autoscaling
>   CreateRoutedAliasTest o.a.s.cloud
>   ReplaceNodeTest   o.a.s.cloud
>   MetricsHistoryHandlerTest o.a.s.handler.admin
> 
> Some of those are pretty regular offenders AFAICT from 
> http://fucit.org/solr-jenkins-reports/failure-report.html 
> <http://fucit.org/solr-jenkins-reports/failure-report.html> .
> 
> Andrzej Białecki did some work on IndexSizeTriggerTest (SOLR-12392) and 
> un-bad-apple’d its tests, but at least one of them is still failing since 
> then - I’ll go add a comment on the issue.
> 
> --
> Steve
> www.lucidworks.com <http://www.lucidworks.com/>
> 
> > On Jun 4, 2018, at 11:16 AM, Erick Erickson  > <mailto:erickerick...@gmail.com>> wrote:
> > 
> > Adrien:
> > 
> > "Do you know whether there is something that makes these jobs any 
> > different?"
> > 
> > Unfortunately no. I'm not really very well versed in the various test
> > environments, maybe Uwe or Steve Rowe or Hoss might have some insight?
> > 
> > On Mon, Jun 4, 2018 at 3:34 AM, Adrien Grand  > <mailto:jpou...@gmail.com>> wrote:
> >> Thanks for helping on this front Erick. I noticed a significant decrease in
> >> noise since you started badapple-ing bad tests, but I'm observing that our
> >> smoke-release builds still keep failing because of Solr tests (10 out of 
> >> the
> >> last 10 builds) in spite of the fact that they disable bad apples:
> >> - https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/ 
> >> <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/>
> >> - https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/ 
> >> <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/>
> >> 
> >> Do you know whether there is something that makes these jobs any different?
> >> 
> >> Le mar. 29 mai 2018 à 18:12, Erick Erickson  >> <mailto:erickerick...@gmail.com>> a
> >> écrit :
> >>> 
> >>> With the long weekend and the fact that the number of non-BadApple
> >>> tests is fairly small this week, I'll skip adding more BadApple tests
> >>> until next week.
> >>> 
> >>> We're scarily close to the non-BaApple'd tests coming under  control.
> >>> If we're lucky, we can draw a line in the sand soon then start working
> >>> on the backlog. I'll be encouraged if we can start shrinking the
> >>> BadApple'd tests.
> >>> 
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> >>> <mailto:dev-unsubscr...@lucene.apache.org>
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org 
> >>> <mailto:dev-h...@lucene.apache.org>
> >>> 
> >> 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > <mailto:dev-unsubscr...@lucene.apache.org>
> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > <mailto:dev-h...@lucene.apache.org>
> > 
> 
> 
> 
> Begin forwarded message:
> 
> > From: Erick Erickson  > <mailto:erickerick...@gmail.com>>
> > Subject: Re: Not adding badapples this week.
> > Date: June 4, 2018 at 11:16:56 AM EDT
> > To: dev@lucene.apache.org <mailto:dev@lucene

Re: lucene-solr:branch_7_3: SOLR-11407: Add more logging to this test to discover the reason for failures.

[Andrzej Białecki]

Thank you!

> On 20 Mar 2018, at 10:25, romseyg...@apache.org wrote:
> 
> Repository: lucene-solr
> Updated Branches:
>  refs/heads/branch_7_3 0977743ae -> 40c49ec3a
> 
> 
> SOLR-11407: Add more logging to this test to discover the reason for failures.
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/40c49ec3
> Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/40c49ec3
> Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/40c49ec3
> 
> Branch: refs/heads/branch_7_3
> Commit: 40c49ec3a1936367197b3a6046a187e01252e3c1
> Parents: 0977743
> Author: Andrzej Bialecki 
> Authored: Wed Oct 11 19:26:00 2017 +0200
> Committer: Alan Woodward 
> Committed: Tue Mar 20 09:21:06 2018 +
> 
> --
> .../admin/AutoscalingHistoryHandlerTest.java| 24 ++--
> 1 file changed, 17 insertions(+), 7 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/40c49ec3/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java
> --
> diff --git 
> a/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java
>  
> b/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java
> index 23fe619..1133684 100644
> --- 
> a/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java
> +++ 
> b/solr/core/src/test/org/apache/solr/handler/admin/AutoscalingHistoryHandlerTest.java
> @@ -249,8 +249,10 @@ public class AutoscalingHistoryHandlerTest extends 
> SolrCloudTestCase {
> waitForState("Timed out wait for collection be active", 
> CollectionAdminParams.SYSTEM_COLL,
> clusterShape(1, 1));
> 
> +log.info("### Start add node...");
> JettySolrRunner jetty = cluster.startJettySolrRunner();
> String nodeAddedName = jetty.getNodeName();
> +log.info("### Added node " + nodeAddedName);
> boolean await = actionFiredLatch.await(60, TimeUnit.SECONDS);
> assertTrue("action did not execute", await);
> 
> @@ -342,6 +344,7 @@ public class AutoscalingHistoryHandlerTest extends 
> SolrCloudTestCase {
> 
> Thread.sleep(5000);
> // commit on the history collection
> +log.info("### Commit .system");
> solrClient.commit(CollectionAdminParams.SYSTEM_COLL);
> Thread.sleep(5000);
> 
> @@ -372,18 +375,25 @@ public class AutoscalingHistoryHandlerTest extends 
> SolrCloudTestCase {
>   private static void waitForRecovery(String collection) throws Exception {
> log.info("Waiting for recovery of " + collection);
> boolean recovered = false;
> +boolean allActive = true;
> +boolean hasLeaders = true;
> +DocCollection collState = null;
> for (int i = 0; i < 300; i++) {
>   ClusterState state = solrClient.getZkStateReader().getClusterState();
> -  DocCollection collState = getCollectionState(collection);
> +  collState = getCollectionState(collection);
>   log.debug("## " + collState);
>   Collection replicas = collState.getReplicas();
> -  boolean allActive = true;
> -  boolean hasLeaders = true;
> +  allActive = true;
> +  hasLeaders = true;
>   if (replicas != null && !replicas.isEmpty()) {
> for (Replica r : replicas) {
> -  if (!r.isActive(state.getLiveNodes())) {
> -log.info("Not active: " + r);
> -allActive = false;
> +  if (state.getLiveNodes().contains(r.getNodeName())) {
> +if (!r.isActive(state.getLiveNodes())) {
> +  log.info("Not active: " + r);
> +  allActive = false;
> +}
> +  } else {
> +log.info("Replica no longer on a live node, ignoring: " + r);
>   }
> }
>   } else {
> @@ -402,7 +412,7 @@ public class AutoscalingHistoryHandlerTest extends 
> SolrCloudTestCase {
> Thread.sleep(1000);
>   }
> }
> -assertTrue("replica never fully recovered", recovered);
> +assertTrue("replica never fully recovered: allActive=" + allActive + ", 
> hasLeaders=" + hasLeaders + ", collState=" + collState, recovered);
> 
>   }
> 
> 

Re: Lucene/Solr 7.3

[Andrzej Białecki]

Alan,

I would like to commit the change in SOLR-11407 
(78d592d2fdfc64c227fc1bcb8fafa3d806fbb384) to branch_7_3. This fixes the logic 
that waits for replica recovery and provides more details about any failures.

> On 17 Mar 2018, at 13:01, Alan Woodward  wrote:
> 
> I’d like to build the RC on Monday, but it depends on SOLR-12070.  I can help 
> debugging that if need be.
> 
> +1 to backport your fixes
> 
>> On 17 Mar 2018, at 01:42, Varun Thacker > > wrote:
>> 
>> I was going through the blockers for 7.3 and only SOLR-12070 came up. Is the 
>> fix complete for this Andrzej?
>> 
>> @Alan : When do you plan on cutting an RC ? I committed SOLR-12083 yesterday 
>> and SOLR-12063 today to master/branch_7x. Both are important fixes for CDCR 
>> so if you are okay I can backport it to the release branch
>> 
>> On Fri, Mar 16, 2018 at 4:58 PM, Đạt Cao Mạnh > > wrote:
>> Hi guys, Alan
>> 
>> I committed the fix for SOLR-12110 to branch_7_3
>> 
>> Thanks!
>> 
>> On Fri, Mar 16, 2018 at 5:43 PM Đạt Cao Mạnh > > wrote:
>> Hi Alan,
>> 
>> Sure the issue is marked as Blocker for 7.3.
>> 
>> On Fri, Mar 16, 2018 at 3:12 PM Alan Woodward > > wrote:
>> Thanks Đạt, could you mark the issue as a Blocker and let me know when it’s 
>> been resolved?
>> 
>>> On 16 Mar 2018, at 02:05, Đạt Cao Mạnh >> > wrote:
>>> 
>>> Hi guys, Alan,
>>> 
>>> I found a blocker issue SOLR-12110, when investigating test failure. I've 
>>> already uploaded a patch and beasting the tests, if the result is good I 
>>> will commit soon.
>>> 
>>> Thanks!
>>>  
>>> On Tue, Mar 13, 2018 at 7:49 PM Alan Woodward >> > wrote:
>>> Just realised that I don’t have an ASF Jenkins account - Uwe or Steve, can 
>>> you give me a hand setting up the 7.3 Jenkins jobs?
>>> 
>>> Thanks, Alan
>>> 
>>> 
 On 12 Mar 2018, at 09:32, Alan Woodward > wrote:
 
 I’ve created the 7.3 release branch.  I’ll leave 24 hours for bug-fixes 
 and doc patches and then create a release candidate.
 
 We’re now in feature-freeze for 7.3, so please bear in mind the following:
 No new features may be committed to the branch.
 Documentation patches, build patches and serious bug fixes may be 
 committed to the branch. However, you should submit all patches you want 
 to commit to Jira first to give others the chance to review and possibly 
 vote against the patch. Keep in mind that it is our main intention to keep 
 the branch as stable as possible.
 All patches that are intended for the branch should first be committed to 
 the unstable branch, merged into the stable branch, and then into the 
 current release branch.
 Normal unstable and stable branch development may continue as usual. 
 However, if you plan to commit a big change to the unstable branch while 
 the branch feature freeze is in effect, think twice: can't the addition 
 wait a couple more days? Merges of bug fixes into the branch may become 
 more difficult.
 Only Jira issues with Fix version “7.3" and priority "Blocker" will delay 
 a release candidate build.
 
 
> On 9 Mar 2018, at 16:43, Alan Woodward  > wrote:
> 
> FYI I’m still recovering from my travels, so I’m going to create the 
> release branch on Monday instead.
> 
>> On 27 Feb 2018, at 18:51, Cassandra Targett > > wrote:
>> 
>> I intend to create the Ref Guide RC as soon as the Lucene/Solr artifacts 
>> RC is ready, so this is a great time to remind folks that if you've got 
>> Ref Guide changes to be done, you've got a couple weeks. If you're stuck 
>> or not sure what to do, let me know & I'm happy to help you out.
>> 
>> Eventually we'd like to release both the Ref Guide and Lucene/Solr with 
>> the same release process, so this will be a big first test to see how 
>> ready for that we are.
>> 
>> On Tue, Feb 27, 2018 at 11:42 AM, Michael McCandless 
>> > wrote:
>> +1
>> 
>> Mike McCandless
>> 
>> http://blog.mikemccandless.com 
>> 
>> On Fri, Feb 23, 2018 at 4:50 AM, Alan Woodward 
>> > > wrote:
>> Hi all,
>> 
>> It’s been a couple of months since the 7.2 release, and we’ve 
>> accumulated some nice new features since then.  I’d like to volunteer to 

TestLTRReRankingPipeline.testDifferentTopN fails 100% on master / branch_7x

[Andrzej Białecki]

Hi,

This test is marked BadApple but fails 100% all the time in my local builds and 
on jenkins. This is not what a bad apple means … it’s simply broken and needs 
to be fixed.

The issue that changed AwaitsFix to BadApple is SOLR-11134 (Apache Jira seems 
to have some problems at the moment - I can’t reopen the issue).

I propose to do one of the following:

* fix it :)

* change the annotation back to AwaitsFix (assuming that at some point some 
gentle soul will write a script to run & report AwaitsFix tests so that they 
are not simply ignored)

* leave it as is (and pretend it’s ok …)

—

Andrzej Białecki

Re: TestReplicationHandler is failing 100% (master and 7.x / 7.3)

[Andrzej Białecki]

Well … I looked at it briefly but I have no idea what’s going on there. I could 
dig into it nonetheless, but if there’s someone who already knows the 
replication handler ins and outs it would probably get fixed sooner...

> On 14 Mar 2018, at 14:23, Alan Woodward <romseyg...@gmail.com> wrote:
> 
> I’m happy either way, but if it’s a bug can we get it fixed quickly?  Can you 
> take ownership of this one Andrzej?
> 
>> On 14 Mar 2018, at 11:24, Andrzej Białecki <a...@getopt.org 
>> <mailto:a...@getopt.org>> wrote:
>> 
>> Hi,
>> 
>> This test has always been fragile, but recently it’s been failing 100%, most 
>> often in ‘doTestIndexFetchOnMasterRestart’.
>> 
>> I don’t know the replication handler enough to be able to find the real 
>> reason behind these failures, but there are two possibilities that I see:
>> 
>> * the test has a bug and needs to be fixed - and if we can’t fix it soon 
>> then with 7.3 release imminent we could BadApple it until it’s properly fixed
>> 
>> * or actually the replication handler has a bug, which needs to be fixed - 
>> in which case I propose to bump up SOLR-12078 to Blocker.
>> 
>> I’m open to suggestions.
>> 
>> —
>> 
>> Andrzej Białecki
>> 
> 

TestReplicationHandler is failing 100% (master and 7.x / 7.3)

[Andrzej Białecki]

Hi,

This test has always been fragile, but recently it’s been failing 100%, most 
often in ‘doTestIndexFetchOnMasterRestart’.

I don’t know the replication handler enough to be able to find the real reason 
behind these failures, but there are two possibilities that I see:

* the test has a bug and needs to be fixed - and if we can’t fix it soon then 
with 7.3 release imminent we could BadApple it until it’s properly fixed

* or actually the replication handler has a bug, which needs to be fixed - in 
which case I propose to bump up SOLR-12078 to Blocker.

I’m open to suggestions.

—

Andrzej Białecki

Re: JIRA and reopened issues?

[Andrzej Białecki]

This is counter-intuitive but you need to use the Workflow drop-down ...

> On 13 Mar 2018, at 12:24, Alan Woodward  wrote:
> 
> Doing the same for me...
> 
>> On 13 Mar 2018, at 10:57, Dawid Weiss  wrote:
>> 
>> This is strange. I reopened LUCENE-8201 but Jira still shows the
>> "reopen" button and it won't allow be to modify the resolution for
>> that issue. Have I missed something? Is this a bug or me?
>> 
>> Dawid
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: [1/7] lucene-solr:master: SOLR-11795: Add Solr metrics exporter for Prometheus

[Andrzej Białecki]

Builds on jenkins are failing due to precommit failures in this code...

> On 20 Feb 2018, at 09:47, k...@apache.org wrote:
> 
> Repository: lucene-solr
> Updated Branches:
>  refs/heads/master dfc0fe86e -> 4bfcbc5c6
> 
> 
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/4bfcbc5c/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java
> --
> diff --git 
> a/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java
>  
> b/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java
> new file mode 100644
> index 000..c62d354
> --- /dev/null
> +++ 
> b/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java
> @@ -0,0 +1,121 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +package org.apache.solr.prometheus.scraper.config;
> +
> +import org.apache.solr.SolrTestCaseJ4;
> +import org.junit.Test;
> +
> +import java.util.ArrayList;
> +import java.util.Arrays;
> +import java.util.LinkedHashMap;
> +import java.util.List;
> +
> +/**
> + * Unit test for SolrQueryConfig.
> + */
> +public class SolrQueryConfigTest extends SolrTestCaseJ4 {
> +  @Test
> +  public void testQueryConfig() throws Exception {
> +SolrQueryConfig queryConfig = new SolrQueryConfig();
> +
> +assertNotNull(queryConfig);
> +  }
> +
> +  @Test
> +  public void testGetCollection() throws Exception {
> +SolrQueryConfig queryConfig = new SolrQueryConfig();
> +
> +String expected = "";
> +String actual = queryConfig.getCollection();
> +assertEquals(expected, actual);
> +  }
> +
> +  @Test
> +  public void testSetCollection() throws Exception {
> +SolrQueryConfig queryConfig = new SolrQueryConfig();
> +
> +queryConfig.setCollection("collection1");
> +
> +String expected = "collection1";
> +String actual = queryConfig.getCollection();
> +assertEquals(expected, actual);
> +  }
> +
> +  @Test
> +  public void testGetPath() throws Exception {
> +SolrQueryConfig queryConfig = new SolrQueryConfig();
> +
> +String expected = "";
> +String actual = queryConfig.getPath();
> +assertEquals(expected, actual);
> +  }
> +
> +  @Test
> +  public void testSetPath() throws Exception {
> +SolrQueryConfig queryConfig = new SolrQueryConfig();
> +
> +queryConfig.setPath("/select");
> +
> +String expected = "/select";
> +String actual = queryConfig.getPath();
> +assertEquals(expected, actual);
> +  }
> +
> +  @Test
> +  public void testGetParams() throws Exception {
> +SolrQueryConfig queryConfig = new SolrQueryConfig();
> +
> +List> expected = new ArrayList<>();
> +List> actual = queryConfig.getParams();
> +assertEquals(expected, actual);
> +  }
> +
> +  @Test
> +  public void testSetParams() throws Exception {
> +SolrQueryConfig queryConfig = new SolrQueryConfig();
> +
> +LinkedHashMap param1 = new LinkedHashMap<>();
> +param1.put("q", "*:*");
> +
> +LinkedHashMap param2 = new LinkedHashMap<>();
> +param2.put("facet", "on");
> +
> +queryConfig.setParams(Arrays.asList(param1, param2));
> +
> +List> expected = Arrays.asList(param1, 
> param2);
> +List> actual = queryConfig.getParams();
> +assertEquals(expected, actual);
> +  }
> +
> +  @Test
> +  public void testGetParamsString() throws Exception {
> +SolrQueryConfig queryConfig = new SolrQueryConfig();
> +
> +LinkedHashMap param1 = new LinkedHashMap<>();
> +param1.put("q", "*:*");
> +param1.put("fq", "manu:apple");
> +
> +LinkedHashMap param2 = new LinkedHashMap<>();
> +param2.put("facet", "on");
> +
> +queryConfig.setParams(Arrays.asList(param1, param2));
> +
> +String expected = "q=*:*=manu:apple=on";
> +String actual = queryConfig.getParamsString();
> +assertEquals(expected, actual);
> +  }
> +}
> 
> 

Re: Lucene/Solr 7.2

[Andrzej Białecki]

> On 6 Dec 2017, at 18:45, Andrzej Białecki <andrzej.biale...@lucidworks.com> 
> wrote:
> 
> I attached the patch to SOLR-11714, which disables the ‘searchRate’ trigger - 
> if there are no objections I’ll commit it shortly to branch_7.2.


This has been committed now to branch_7_2 and I don’t have any other open 
issues for 7.2. Thanks!


> 
>> On 6 Dec 2017, at 15:51, Andrzej Białecki <andrzej.biale...@lucidworks.com 
>> <mailto:andrzej.biale...@lucidworks.com>> wrote:
>> 
>> 
>>> On 6 Dec 2017, at 15:35, Andrzej Białecki <andrzej.biale...@lucidworks.com 
>>> <mailto:andrzej.biale...@lucidworks.com>> wrote:
>>> 
>>> SOLR-11458 is committed and resolved - thanks for the patience.
>> 
>> 
>> Actually, one more thing … ;) SOLR-11714 is a more serious bug in a new 
>> feature (searchRate autoscaling trigger). It’s probably best to disable this 
>> feature in 7.2 rather than releasing a broken version, so I’d like to commit 
>> a patch that disables it (plus a note in CHANGES.txt).
>> 
>> 
>>> 
>>> 
>>> 
>>>> On 6 Dec 2017, at 14:02, Adrien Grand <jpou...@gmail.com 
>>>> <mailto:jpou...@gmail.com>> wrote:
>>>> 
>>>> Thanks for the heads up, Anshum.
>>>> 
>>>> This leaves us with only SOLR-11458 to wait for before building a RC 
>>>> (which might be ready but just not marked as resolved).
>>> 
>>>> 
>>>> 
>>>> Le mer. 6 déc. 2017 à 13:47, Ishan Chattopadhyaya 
>>>> <ichattopadhy...@gmail.com <mailto:ichattopadhy...@gmail.com>> a écrit :
>>>> Hi Adrien,
>>>> I'm planning to skip SOLR-11624 for this release (as per my last comment 
>>>> https://issues.apache.org/jira/browse/SOLR-11624?focusedCommentId=16280121=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280121
>>>>  
>>>> <https://issues.apache.org/jira/browse/SOLR-11624?focusedCommentId=16280121=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280121>).
>>>>  If someone has an objection, please let me know; otherwise, please feel 
>>>> free to proceed with the release.
>>>> I'll continue working on it anyway, and shall try to have it ready for the 
>>>> next release.
>>>> Thanks,
>>>> Ishan
>>>> 
>>>> On Wed, Dec 6, 2017 at 2:41 PM, Adrien Grand <jpou...@gmail.com 
>>>> <mailto:jpou...@gmail.com>> wrote:
>>>> FYI I created the new branch for 7.2, so you will have to backport to this 
>>>> branch. No hurry though, I mostly created the branch so that it's fine to 
>>>> cherry-pick changes that may wait for 7.3 to be released.
>>>> 
>>>> Le mer. 6 déc. 2017 à 08:53, Adrien Grand <jpou...@gmail.com 
>>>> <mailto:jpou...@gmail.com>> a écrit :
>>>> Sorry to hear that Ishan, I hope you are doing better now. +1 to get 
>>>> SOLR-11624 in.
>>>> 
>>>> Le mer. 6 déc. 2017 à 07:57, Ishan Chattopadhyaya 
>>>> <ichattopadhy...@gmail.com <mailto:ichattopadhy...@gmail.com>> a écrit :
>>>> I was a bit unwell over the weekend and yesterday; I'm working on a very 
>>>> targeted fix for SOLR-11624 right now; I expect it to take another 5-6 
>>>> hours.
>>>> Is that fine with you, Adrien? If not, please go ahead with the release, 
>>>> and I'll volunteer later for a bugfix release for this after 7.2 is out.
>>>> 
>>>> On Wed, Dec 6, 2017 at 3:25 AM, Adrien Grand <jpou...@gmail.com 
>>>> <mailto:jpou...@gmail.com>> wrote:
>>>> Fine with me.
>>>> 
>>>> 
>>>> Le mar. 5 déc. 2017 à 22:34, Varun Thacker <va...@vthacker.in 
>>>> <mailto:va...@vthacker.in>> a écrit :
>>>> Hi Adrien,
>>>> 
>>>> I'd like to commit SOLR-11590 . The issue had a patch couple of weeks ago 
>>>> and has been reviewed but never got committed. I've run all the tests 
>>>> twice as well to verify.
>>>> 
>>>> On Tue, Dec 5, 2017 at 9:08 AM, Andrzej Białecki 
>>>> <andrzej.biale...@lucidworks.com <mailto:andrzej.biale...@lucidworks.com>> 
>>>> wrote:
>>>> 
>>>>> On 5 Dec 2017, at 18:05, Adrien Grand <jpou...@gmail.com 
>>>>> <mailto:jpou...@gmail.com>> wrote:
>>>>> 
>>>>> Andrzej, ok to merge since it 

Re: Lucene/Solr 7.2

[Andrzej Białecki]

I attached the patch to SOLR-11714, which disables the ‘searchRate’ trigger - 
if there are no objections I’ll commit it shortly to branch_7.2.

> On 6 Dec 2017, at 15:51, Andrzej Białecki <andrzej.biale...@lucidworks.com> 
> wrote:
> 
> 
>> On 6 Dec 2017, at 15:35, Andrzej Białecki <andrzej.biale...@lucidworks.com 
>> <mailto:andrzej.biale...@lucidworks.com>> wrote:
>> 
>> SOLR-11458 is committed and resolved - thanks for the patience.
> 
> 
> Actually, one more thing … ;) SOLR-11714 is a more serious bug in a new 
> feature (searchRate autoscaling trigger). It’s probably best to disable this 
> feature in 7.2 rather than releasing a broken version, so I’d like to commit 
> a patch that disables it (plus a note in CHANGES.txt).
> 
> 
>> 
>> 
>> 
>>> On 6 Dec 2017, at 14:02, Adrien Grand <jpou...@gmail.com 
>>> <mailto:jpou...@gmail.com>> wrote:
>>> 
>>> Thanks for the heads up, Anshum.
>>> 
>>> This leaves us with only SOLR-11458 to wait for before building a RC (which 
>>> might be ready but just not marked as resolved).
>> 
>>> 
>>> 
>>> Le mer. 6 déc. 2017 à 13:47, Ishan Chattopadhyaya 
>>> <ichattopadhy...@gmail.com <mailto:ichattopadhy...@gmail.com>> a écrit :
>>> Hi Adrien,
>>> I'm planning to skip SOLR-11624 for this release (as per my last comment 
>>> https://issues.apache.org/jira/browse/SOLR-11624?focusedCommentId=16280121=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280121
>>>  
>>> <https://issues.apache.org/jira/browse/SOLR-11624?focusedCommentId=16280121=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280121>).
>>>  If someone has an objection, please let me know; otherwise, please feel 
>>> free to proceed with the release.
>>> I'll continue working on it anyway, and shall try to have it ready for the 
>>> next release.
>>> Thanks,
>>> Ishan
>>> 
>>> On Wed, Dec 6, 2017 at 2:41 PM, Adrien Grand <jpou...@gmail.com 
>>> <mailto:jpou...@gmail.com>> wrote:
>>> FYI I created the new branch for 7.2, so you will have to backport to this 
>>> branch. No hurry though, I mostly created the branch so that it's fine to 
>>> cherry-pick changes that may wait for 7.3 to be released.
>>> 
>>> Le mer. 6 déc. 2017 à 08:53, Adrien Grand <jpou...@gmail.com 
>>> <mailto:jpou...@gmail.com>> a écrit :
>>> Sorry to hear that Ishan, I hope you are doing better now. +1 to get 
>>> SOLR-11624 in.
>>> 
>>> Le mer. 6 déc. 2017 à 07:57, Ishan Chattopadhyaya 
>>> <ichattopadhy...@gmail.com <mailto:ichattopadhy...@gmail.com>> a écrit :
>>> I was a bit unwell over the weekend and yesterday; I'm working on a very 
>>> targeted fix for SOLR-11624 right now; I expect it to take another 5-6 
>>> hours.
>>> Is that fine with you, Adrien? If not, please go ahead with the release, 
>>> and I'll volunteer later for a bugfix release for this after 7.2 is out.
>>> 
>>> On Wed, Dec 6, 2017 at 3:25 AM, Adrien Grand <jpou...@gmail.com 
>>> <mailto:jpou...@gmail.com>> wrote:
>>> Fine with me.
>>> 
>>> 
>>> Le mar. 5 déc. 2017 à 22:34, Varun Thacker <va...@vthacker.in 
>>> <mailto:va...@vthacker.in>> a écrit :
>>> Hi Adrien,
>>> 
>>> I'd like to commit SOLR-11590 . The issue had a patch couple of weeks ago 
>>> and has been reviewed but never got committed. I've run all the tests twice 
>>> as well to verify.
>>> 
>>> On Tue, Dec 5, 2017 at 9:08 AM, Andrzej Białecki 
>>> <andrzej.biale...@lucidworks.com <mailto:andrzej.biale...@lucidworks.com>> 
>>> wrote:
>>> 
>>>> On 5 Dec 2017, at 18:05, Adrien Grand <jpou...@gmail.com 
>>>> <mailto:jpou...@gmail.com>> wrote:
>>>> 
>>>> Andrzej, ok to merge since it is a bug fix. Since we're close to the RC 
>>>> build, maybe try to get someone familiar with the code to review it to 
>>>> make sure it doesn't have unexpected side-effects?
>>> 
>>> Sure I’ll do this - thanks!
>>> 
>>>> 
>>>> Le mar. 5 déc. 2017 à 17:57, Andrzej Białecki 
>>>> <andrzej.biale...@lucidworks.com <mailto:andrzej.biale...@lucidworks.com>> 
>>>> a écrit :
>>>> Adrien,
>>>> 
>>>> If it’s ok I would also like to merge SOLR-11458, this significa

Re: Lucene/Solr 7.2

[Andrzej Białecki]

> On 6 Dec 2017, at 15:35, Andrzej Białecki <andrzej.biale...@lucidworks.com> 
> wrote:
> 
> SOLR-11458 is committed and resolved - thanks for the patience.


Actually, one more thing … ;) SOLR-11714 is a more serious bug in a new feature 
(searchRate autoscaling trigger). It’s probably best to disable this feature in 
7.2 rather than releasing a broken version, so I’d like to commit a patch that 
disables it (plus a note in CHANGES.txt).


> 
> 
> 
>> On 6 Dec 2017, at 14:02, Adrien Grand <jpou...@gmail.com 
>> <mailto:jpou...@gmail.com>> wrote:
>> 
>> Thanks for the heads up, Anshum.
>> 
>> This leaves us with only SOLR-11458 to wait for before building a RC (which 
>> might be ready but just not marked as resolved).
> 
>> 
>> 
>> Le mer. 6 déc. 2017 à 13:47, Ishan Chattopadhyaya <ichattopadhy...@gmail.com 
>> <mailto:ichattopadhy...@gmail.com>> a écrit :
>> Hi Adrien,
>> I'm planning to skip SOLR-11624 for this release (as per my last comment 
>> https://issues.apache.org/jira/browse/SOLR-11624?focusedCommentId=16280121=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280121
>>  
>> <https://issues.apache.org/jira/browse/SOLR-11624?focusedCommentId=16280121=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16280121>).
>>  If someone has an objection, please let me know; otherwise, please feel 
>> free to proceed with the release.
>> I'll continue working on it anyway, and shall try to have it ready for the 
>> next release.
>> Thanks,
>> Ishan
>> 
>> On Wed, Dec 6, 2017 at 2:41 PM, Adrien Grand <jpou...@gmail.com 
>> <mailto:jpou...@gmail.com>> wrote:
>> FYI I created the new branch for 7.2, so you will have to backport to this 
>> branch. No hurry though, I mostly created the branch so that it's fine to 
>> cherry-pick changes that may wait for 7.3 to be released.
>> 
>> Le mer. 6 déc. 2017 à 08:53, Adrien Grand <jpou...@gmail.com 
>> <mailto:jpou...@gmail.com>> a écrit :
>> Sorry to hear that Ishan, I hope you are doing better now. +1 to get 
>> SOLR-11624 in.
>> 
>> Le mer. 6 déc. 2017 à 07:57, Ishan Chattopadhyaya <ichattopadhy...@gmail.com 
>> <mailto:ichattopadhy...@gmail.com>> a écrit :
>> I was a bit unwell over the weekend and yesterday; I'm working on a very 
>> targeted fix for SOLR-11624 right now; I expect it to take another 5-6 hours.
>> Is that fine with you, Adrien? If not, please go ahead with the release, and 
>> I'll volunteer later for a bugfix release for this after 7.2 is out.
>> 
>> On Wed, Dec 6, 2017 at 3:25 AM, Adrien Grand <jpou...@gmail.com 
>> <mailto:jpou...@gmail.com>> wrote:
>> Fine with me.
>> 
>> 
>> Le mar. 5 déc. 2017 à 22:34, Varun Thacker <va...@vthacker.in 
>> <mailto:va...@vthacker.in>> a écrit :
>> Hi Adrien,
>> 
>> I'd like to commit SOLR-11590 . The issue had a patch couple of weeks ago 
>> and has been reviewed but never got committed. I've run all the tests twice 
>> as well to verify.
>> 
>> On Tue, Dec 5, 2017 at 9:08 AM, Andrzej Białecki 
>> <andrzej.biale...@lucidworks.com <mailto:andrzej.biale...@lucidworks.com>> 
>> wrote:
>> 
>>> On 5 Dec 2017, at 18:05, Adrien Grand <jpou...@gmail.com 
>>> <mailto:jpou...@gmail.com>> wrote:
>>> 
>>> Andrzej, ok to merge since it is a bug fix. Since we're close to the RC 
>>> build, maybe try to get someone familiar with the code to review it to make 
>>> sure it doesn't have unexpected side-effects?
>> 
>> Sure I’ll do this - thanks!
>> 
>>> 
>>> Le mar. 5 déc. 2017 à 17:57, Andrzej Białecki 
>>> <andrzej.biale...@lucidworks.com <mailto:andrzej.biale...@lucidworks.com>> 
>>> a écrit :
>>> Adrien,
>>> 
>>> If it’s ok I would also like to merge SOLR-11458, this significantly 
>>> reduces the chance of accidental data loss when using MoveReplicaCmd.
>>> 
>>>> On 5 Dec 2017, at 14:44, Adrien Grand <jpou...@gmail.com 
>>>> <mailto:jpou...@gmail.com>> wrote:
>>>> 
>>>> Quick update:
>>>> 
>>>> LUCENE-8043, SOLR-9137, SOLR-11662 and SOLR-11687 have been merged, they 
>>>> will be in 7.2.
>>>> 
>>>> LUCENE-8048 and SOLR-11624 are still open. 
>>>> 
>>>> LUCENE-8048 looks like it could make things better in some cases but I 
>>>> don't think it is required for 7.2, so I