adapt solr's "copy-lucene-jars" ant task to copy the ivy output dir
> - delete the lucene stuff from release wizard.
>
> This is quick and easy. Adapting Gradle for a minor release is too hard.
>
> Am 21. November 2021 21:34:40 UTC schrieb Noble Paul >:
>>
All Solr users using 8x and they will need some time to get comfortable
with 9x . So, there is a good chance we may need to release an 8.12 based
on Lucene 8.11
On Mon, Nov 22, 2021, 8:22 AM Adrien Grand wrote:
> +1 to making branch_8x read-only as Uwe suggested
>
> I think Uwe's other point is
>>>> >>>
>>>> >>> On Thu, May 6, 2021 at 10:28 PM Adrien Grand wrote:
>>>> >>>>
>>>> >>>> +1
>>>> >>>>
>>>> >>>> Mayya, are you volunteering
upgrading from 8.4 (if they have not already done it)
2) revert this change and do a break fix release
3) Fix the actual bug that caused the null node_name in the first place
regards
Noble Paul
On Tue, May 18, 2021 at 10:22 PM Andrzej Białecki wrote:
>
> Ishan, as I pointed out in Jira I don’
dependencies and IMO we should think about them in that way.
>
> Ilan
>
> On Tue 4 May 2021 at 09:45, Noble Paul wrote:
>
>> @Houston
>>
>> So, Are you suggesting we should not do that ?
>>
>> On Tue, May 4, 2021 at 2:35 PM Houston Putman
>> wrote:
&g
@Houston
So, Are you suggesting we should not do that ?
On Tue, May 4, 2021 at 2:35 PM Houston Putman
wrote:
> In the future we wont be able to “work on both at the same time”, once
> Lucene 9 is cut. Why not pull that bandaid now?
>
> On Mon, May 3, 2021 at 11:32 PM Noble
ause they don’t live in the main
> project where all of us have oversight and easy access.
> >
> >
> > Agreed :-(
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
--
-
Noble Paul
Congrats Jan
On Sun, Feb 21, 2021, 3:04 AM Marcus Eagan wrote:
> Awesome, way to go Jan!
>
> - Marcus
>
> On Sat, Feb 20, 2021 at 10:53 Lucky Sharma wrote:
>
>> Congratulations Jan
>>
>> Regards,
>> Lucky Sharma
>>
>> On Sat, 20 Feb 2021 at 8:07 PM, Karl Wright wrote:
>>
>>> Congratulations!
t the board approved in its February 2021 meeting.
>> >
>> > Congratulations, Mike!
>> >
>> > --
>> > Anshum Gupta
>>
>> -
>> To unsubscribe, e
ades of servers (ideally
> > multi-node clusters) running pre-8.8.0 to this RC if possible. Also,
> > please try client applications that are using an older SolrJ, esp.
> > those that load cluster state directly from ZK.
> >
> > Best regards,
> > Tim
>
> ---
.dups=1 -Dtests.iters=5 -Dbeast.iters=5
>>>> -Dtestcase=SolrCloudReportersTest beast
>>>>
>>>> No failures.
>>>>
>>>> [beaster] Beast round 1 results:
>>>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/1
>>>
t;>>>>>
>>>>>> a. A rolling upgrade of a 3-node 8.7.0 cluster to the 8.8.1 RC completes
>>>>>> successfully w/o any NPEs or weirdness with leader election / recoveries.
>>>>>>
>>>>>>
>>>>>> b. The b
/Changes.html
- -
Noble Paul
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.0.0
Comment: Seamlessly send and receive encrypted email
wsFzBAEBCgAGBQJgF/RnACEJEMOP9ew/z9s+FiEEz85fu5IMPHRc7uCEw4/1
7D/P2z6fzRAAm4AKbeIGWfPK
you are using may not
have
replicated the release yet. If that is the case, please try another mirror.
This also applies to Maven access.
- -
Noble Paul
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.0.0
Comment: Seamlessly
8. And there's
> likely to be an 8.8.1 or 8.9 at some point later. So there's
> definitely a "point in trying to fix" those failures, generally
> speaking.
>
> Jason
>
> On Thu, Jan 28, 2021 at 6:01 PM Noble Paul wrote:
> >
> > I'm not sure why the tests
> Do you think it is just test flakiness or flakiness in Solr's related
> functionality?
>
> ~ David
>
>
> On Thu, Jan 28, 2021 at 5:36 PM Noble Paul wrote:
>>
>> Both of those are gone for good @David Smiley I think we can safely
>> make them BadApple
8:25.213071]
>>>
>>> +1 better late than never?
>>>
>>> On Thu, Jan 28, 2021 at 8:04 AM Ishan Chattopadhyaya
>>> wrote:
>>> >
>>> > Thanks Noble!
>>> >
>>> > On Thu, 28 Jan, 2021, 4:24 pm Noble Paul, wro
Yeah , there were 5 binding votes
On Thu, Jan 28, 2021 at 11:19 PM Atri Sharma wrote:
>
> Hi Noble,
>
> Is the binding vote count not incorrect?
>
> On Thu, 28 Jan 2021, 16:24 Noble Paul, wrote:
>>
>> [+1] 9 (4 binding)
>>
>> [0] 0
>>
>>
smoke tester, a demo app, and checked the change log. All of that
> looks good.
>
> On Mon, Jan 25, 2021 at 2:22 AM Noble Paul wrote:
>>
>> Please vote for release candidate 2 for Lucene/Solr 8.8.0
>>
>> The artifacts can be downloaded from:
>>
>>
/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
The vote will be open for at least 72 hours
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Here is my +1
--
-
Noble Paul
I've pushed the changes.
@Ishan Chattopadhyaya if you are unavailable just ping me. I'll put up RC2
On Sat, Jan 23, 2021 at 2:48 PM Noble Paul wrote:
>
> please hold on there is a concurrency issue, I'm fixing it
>
> On Sat, Jan 23, 2021 at 12:54 PM Ishan Chattopadhyaya
> wr
t 4:46 PM Houston Putman
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for volunteering Ishan.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think it might be a good idea to wait to cut and rel
>>>>
>> >>>> You can run the smoke tester directly with this command:
>> >>>>
>> >>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> >>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC1-rev737cb9c49b08f6e3964c1e8a80132da3c764e027
>> >>>>
>> >>>> The vote will be open for at least 72 hours i.e. until 2021-01-22 17:00
>> >>>> UTC.
>> >>>>
>> >>>> [ ] +1 approve
>> >>>> [ ] +0 no opinion
>> >>>> [ ] -1 disapprove (and reason why)
>> >>>>
>> >>>> Here is my +1
>> >>>>
>>
>> --
>> Regards,
>>
>> Atri
>> Apache Concerted
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Devs,
>>
>> Just admitted mom to a hospital, she has given us a sudden health scare. I
>> doubt I'll be around for this release or for some time now.
>>
>> I've spoken to Noble and requested him to take over the release duties here.
>>
>> Thanks and
at the time of the
> release, I'll revert this. Thanks!
>
> On Thu, Jan 14, 2021 at 11:33 AM Noble Paul wrote:
>>
>> @Ishan Chattopadhyaya
>>
>> I wish to port https://issues.apache.org/jira/browse/SOLR-14155 to
>> 8.8, if it is OK
>>
>>
> inclusion into 8.8.
>>>>>>>> Would it be reasonable to cut the release branch end of this week and
>>>>>>>> start the RC process around 13th January?
>>>>>>>> If there are any issues someone would w
gt; On Tue, Jan 12, 2021 at 8:13 PM Noble Paul wrote:
>
>> I'm +1 for a top level sandbox repo. Anyone should be able create a
>> project in that.
>>
>> Once the project graduates out of the sandbox we should create a top level
>>
>> On Wed, Jan 1
code in. If it
> works out well, we can release it or iterate on the code/implementation. In
> any case, it would have zero impact on the project itself.
>
> -Anshum
>
> On Tue, Jan 12, 2021 at 3:37 PM Noble Paul wrote:
>
>> I feel this is placing the cart before the hors
y directed repo. Lucene has a sandbox in
>>>>>>>>>>>> the main code. We could similarly start this under Solr contrib
>>>>>>>>>>>> and move it out before an actual release of 9x happens.
---
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail:
t;
> >
> > -----
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
h about 3-4
>>> days before that). Please let me know if someone has any concerns.
>>> Thanks and regards,
>>> Ishan
>>>
>> --
>> Sent from Gmail Mobile
>
>
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
port 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
ward
incompatibility.
--
-----
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
ion... maybe there are subtle reasons they are needed and I
>> think it would be good as a project that we are clear on them.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> htt
Thu, Oct 1, 2020 at 8:36 AM Timothy Potter
> wrote:
>
>> Awesome guys, thanks for the pointers ... am cooking up a PR (for master)
>> for this today
>>
>> On Thu, Oct 1, 2020 at 2:22 AM Noble Paul wrote:
>>
>>> The annotation (
>>> https://gith
gt;> documenting the changes done in that branch, pointing to where these changes
>> happened and then picking them up one by one and porting them more or less
>> independently of each other. We might only port a subset of changes by the
>> time 9.0 is released, that's fine
to help test/debug.
>>>
>>> That said I don’t know for sure what are the changes in the branch that do
>>> not belong in 9. The problem with them being 10x only is that backports
>>> would potentially be more difficult for all the life of 9.
>>>
>>&
could be use to help test/debug.
>>
>> That said I don’t know for sure what are the changes in the branch that do
>> not belong in 9. The problem with them being 10x only is that backports
>> would potentially be more difficult for all the life of 9.
>>
>> On Mo
>I don't think it can be said what committers do and don't do with regards
to running Solr. All of us would answer this differently and at different
points in time.
" I have run it in one large cluster, so it is certified to be bug
free/stable" I don't think it's a reasonable approach. We need
-07 02:00 UTC.
>>
>>
>> [ ] +1 approve
>>
>> [ ] +0 no opinion
>>
>> [ ] -1 disapprove (and reason why)
>>
>>
>> Here is my +1
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
m that branch, say Solr 10
> alpha (early access) or any other name that someone suggests, so that users
> could try it out and report regressions or improvements etc.
>
>
>
> I volunteer to be the RM and planning to start the process around 1
> December-15 December timeframe. Until
t;> Is there any thoughts, concerns, questions?
>>
>> Regards,
>> Ishan
>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
e sneaked in, unless someone notices very carefully a few lines of
>> changes in a 25 class PR?
>>
>> Looking for some suggestions here.
>> Thanks and regards,
>> Ishan
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
in, unless someone notices very carefully a few lines of
> changes in a 25 class PR?
>
> Looking for some suggestions here.
> Thanks and regards,
> Ishan
--
-
Noble Paul
--
;
>> @Tim
>>
>> Please check ClusterAPI or ZookeeperReadAPI etc.
>> Recently used it in Yasa:
>> https://github.com/yasa-org/yasa/blob/master/yasa-solr-plugin/src/main/java/io/github/kezhenxu94/YasaHandler.java
>>
>> On Thu, Oct 1, 2020 at 10:46 AM Noble P
>>
>>>> From where I sit, I think we should just remove the use of restlet in the
>>>> implementation but keep the API for Solr 9 (master).
>>>>
>>>> @Ishan ~ you mentioned there is a way to get REST API like behavior w/o
>>>> using JAX-
11:57 am Dawid Weiss, wrote:
>>>>>>
>>>>>> We can't have or redistribute binaries in ASL sources - that's my
>>>>>> understanding.
>>>>>>
>>>>>> Dawid
>>>>>>
>>>>>> On Tue, Sep 29, 2020 at 10:02 PM Ishan Chattopadhyaya
>>>>>> wrote:
>
t;>>> >
>>>>> > On Wed, 30 Sep, 2020, 1:19 am Dawid Weiss,
>>>>> > wrote:
>>>>> >>
>>>>> >>
>>>>> >> We can upgrade if it doesn't break anything... which I can't
>>>>> >> guarantee. ;)
>>>>> >>
>>>>> >> Dawid
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>>
>>>
>>> --
>>> Uwe Schindler
>>> Achterdiek 19, 28357 Bremen
>>> https://www.thetaphi.de
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
@Tomas Fernandez Lobbe
@Ishan Chattopadhyaya
Let's support the single file upload feature. Let's automatically make
that configset "untrusted" if any file is uploaded over REST. Those
"untrusted" features are not really important for normal users
On Wed, Sep 30, 2020 at 3:19
eiss, wrote:
>>
>>
>> We can upgrade if it doesn't break anything... which I can't guarantee. ;)
>>
>> Dawid
--
-----
Noble Paul
-
To unsubscribe,
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
--
-
Noble Paul
ote:
>>
>> Do we have a community blessed alternative to restlet already?
>>
>> On Sep 20, 2020, at 9:40 AM, Noble Paul wrote:
>>
>> Haha.
>>
>> In fact schema APIs don't use restlet. Only the managed resources use it
>>
>> On Sat, Sep
Haha.
In fact schema APIs don't use restlet. Only the managed resources use it
On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> If I were talend, I'd immediately start publishing to maven central. If I
> were the developer who built the schema APIs, I
mplexity to core Solr, yet at the same time, we don’t
> > have the (hopefully!) cleaner structure that is being worked on in the
> > reference_impl_dev to properly support the complexity.
> >
> > Don’t get discouraged!
> >
> >> On Sep 18, 2020, at 11:21 PM, N
> machine or whatever...
>
> On Sat, Sep 19, 2020, 09:31 Noble Paul wrote:
>>
>> I'm beasting changes so many times and I can't see the failures happening
>>
>> I'm wondering if we should just disable the
>> TestPackages@testSchemaPlugins() or revert the changes wholes
until we are able to merge to
> > master. Such drastic test failure situation is unacceptable.
> >
> >> Make schema components load from packages
> >> -
> >>
> >>Key: SOLR-14151
> >
I shall revert the changes and work on a solution
On Sat, Sep 19, 2020, 6:54 AM Jason Gerlowski wrote:
> > I don't think it is along the Apache way to revert somebody's commit
> without an explicit permission to do so
> Interesting, I made the Devil's Advocate argument above with the
> Apache
;>
>> This code is disabled by default and requires the user to set a
>> configuration in ZK's /clusterprops.json to be enabled.
>>
>> Ilan
>>
>>
--
-
Noble Paul
make to
> hard code default configs to get rid of solr.xml. The difference is that the
> hard coding is done in solr.xml rather than in some defaultSolrConfig.java
> class. This makes changing default configuration easy and not requiring
> recompilation but is otherwise not conceptually diff
o_green_300.png
> >>
> >> Please vote for one of the above choices. This vote will close about one
> >> week from today, Mon, Sept 7, 2020 at 11:59PM.
> >>
> >> Thanks!
> >>
> >> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> >> [first-vote]
> >> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> >> [second-vote]
> >> http://mail-archives.apache.org/mod_mbox/lucene-dev/202009.mbox/%3cCA+DiXd7eBrQu5+aJQ3jKaUtUTJUqaG2U6o+kUZfNe-m=smn...@mail.gmail.com%3e
> >> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
e that file, users would have
> >>>>>>> >> to edit/redeploy the file on each node and restart the Solr JVM on
> >>>>>>> >> that node for the new config to be taken into account.
> >>>>>>> >>
> >>>>>>> >> Based on the above, my vision (or mental model) of what to use
> >>>>>>> >> depending on the need:
> >>>>>>> >>
> >>>>>>> >> solrconfig.xml is the only per collection config. IMO it does its
> >>>>>>> >> job correctly: Solr devs can set defaults, users tailor the
> >>>>>>> >> content to what they need for new config sets. It's the only
> >>>>>>> >> option for per collection config anyway.
> >>>>>>> >>
> >>>>>>> >> The real hesitation could be between solr.xml and Zookeeper
> >>>>>>> >> /clusterprops.json. What should go where?
> >>>>>>> >>
> >>>>>>> >> For user configs (anything the user does to the Solr cluster AFTER
> >>>>>>> >> it was deployed and started), /clusterprops.json seems to be the
> >>>>>>> >> obvious choice and offers the right abstractions (global config,
> >>>>>>> >> no need to worry about individual nodes, all nodes pick up configs
> >>>>>>> >> and changes to configs dynamically).
> >>>>>>> >>
> >>>>>>> >> For configs that need to be available without requiring user
> >>>>>>> >> intervention or needed before the connection to ZK is established,
> >>>>>>> >> there's currently no other choice than using solr.xml. Such
> >>>>>>> >> configuration obviously include parameters that are needed to
> >>>>>>> >> connect to ZK (timeouts, credential provider and hopefully one day
> >>>>>>> >> an option to either use direct ZK interaction code or Curator
> >>>>>>> >> code), but also configuration of general features that should be
> >>>>>>> >> the default without requiring users to opt in yet allowing then to
> >>>>>>> >> easily opt out by editing solr.xml before deploying to their
> >>>>>>> >> cluster (in the future, this could include which Lucene version to
> >>>>>>> >> load in Solr for example).
> >>>>>>> >>
> >>>>>>> >> To summarize:
> >>>>>>> >> • Collection specific config? --> solrconfig.xml
> >>>>>>> >> • User provided cluster config once SolrCloud is running? -->
> >>>>>>> >> ZK /clusterprops.json
> >>>>>>> >> • Solr dev provided cluster config? --> solr.xml
> >>>>>>> >>
> >>>>>>> >> Going forward, some (but only some!) of the config that currently
> >>>>>>> >> can only live in solr.xml could be made to go to
> >>>>>>> >> /clusterprops.json or another ZK based config file. This would
> >>>>>>> >> require adding code to create that ZK file upon initial cluster
> >>>>>>> >> start (to not force the user to push it) and devise a mechanism
> >>>>>>> >> (likely a script, could be tricky though) to update that file in
> >>>>>>> >> ZK when a new release of Solr is deployed and a previous version
> >>>>>>> >> of that file already exists. Not impossible tasks, but not trivial
> >>>>>>> >> ones either. Whatever the needs of such an approach are, it might
> >>>>>>> >> be easier to keep the existing solr.xml as a file and allow users
> >>>>>>> >> to define overrides in Zookeeper for the configuration parameters
> >>>>>>> >> from solr.xml that make sense to be overridden in ZK (obviously ZK
> >>>>>>> >> credentials or connection timeout do not make sense in that
> >>>>>>> >> context, but defining the shard handler implementation class does
> >>>>>>> >> since it is likely loaded after a node managed to connect to ZK).
> >>>>>>> >>
> >>>>>>> >> Some config will have to stay in a local Node file system file and
> >>>>>>> >> only there no matter what: Zookeeper timeout definition or any
> >>>>>>> >> node configuration that is needed before the node connects to
> >>>>>>> >> Zookeeper.
> >>>>>>> >>
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > -
> >>>>>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>>>>>> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>>>>> >
> >>>>>>>
> >>>>>>>
> >>>>>>> -
> >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> http://www.needhamsoftware.com (work)
> >>>>> http://www.the111shift.com (play)
> >>>
> >>>
> >>>
> >>> --
> >>> http://www.needhamsoftware.com (work)
> >>> http://www.the111shift.com (play)
> >
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.com (play)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
The filestore dir is where the packages live. If we move it to another
location, existing installations might fail. So, it's a backward
incompatible change.
What are our options?
Is it possible to have these directories precreated in the distro/code to
ensure that these warnings don't come.
On
/issues.apache.org/jira/browse/LUCENE-9221
> [first-vote]
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting
>
>
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
tra noise. Deprecated features
>>> can be removed in a later 9.x release, when the new alternative is solid
>>> and well known.
>>
>>
>> Again, maybe I'm misreading but I'd like to us to manage to remove a lot of
>> deprecated stuff as the norm. There will be exceptions to the norm -- Solr
>> Cell, CDCR. To make this point clear, I wish to add to the roadmap, Solr
>> 9.0 table, first row, saying basically "Remove lots of deprecated stuff"
>> with some JIRAs linked like https://issues.apache.org/jira/browse/SOLR-13138
>>
>> ~ David
>>
>>
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
;> to join.
>>
>> Congratulations and welcome, Atri!
>>
>>
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
ions?
> Regards,
> Ishan
>
--
-----
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
reasons to go that route.
>
>
> On 19.08.20 08:49, Noble Paul wrote:
> > So, it's not very different from directly reading a file from ZK?
> >
> > what benefit do you get by using the ManagedResourceStorage?
> >
> > On Sun, Aug 16, 2020 at 7:08 PM Matthias Krueger wrote:
&
o store some (well-known) resources.
>
> Matt
>
>
> On 15.08.20 11:38, Noble Paul wrote:
> >> I use MangedResource#StorageIO and its implementations as a convenient way
> >> to abstract away the underlying config storage when creating plugins that
> >> need to support bo
gt; -Yonik
>
>
> On Sun, Aug 2, 2020 at 7:19 PM Ishan Chattopadhyaya
> wrote:
>>
>> I am pleased to announce that Namgyu Kim has accepted the PMC's invitation
>> to join.
>>
>> Congratulations and welcome, Namgyu!
&g
t 7:32 PM Noble Paul wrote:
>
> >As authentication is plugged into the SolrDispatchFilter I would assume that
> >you would need to be authenticated to read/write Managed Resources
>
> I'm talking about the authorization plugins
>
> On Fri, Aug 14, 2020
gt;
> On Sun, Aug 2, 2020 at 7:21 PM Ishan Chattopadhyaya
> wrote:
>>
>> I am pleased to announce that Gus Heck has accepted the PMC's invitation to
>> join.
>>
>> Congratulations and welcome, Gus!
>
t; invitation to join.
>>
>> Congratulations and welcome, Munendra!
>>
>
>
--
-
Noble Paul
t;
> IMO an abstraction that allows distributing configuration (ML models,
> configuration snippets, external file fields...) that exceeds the typical ZK
> size limits to SolrCloud while also supporting Solr Standalone would be nice
> to have.
>
> Matt
>
>
> On 12.08.20 02:0
e. until 2020-08-13 20:00
> >>> UTC.
> >>>
> >>> [ ] +1 approve
> >>> [ ] +0 no opinion
> >>> [ ] -1 disapprove (and reason why)
> >>>
> >>> Here is my +1
> >
> >
> >
> > --
> > http://www.needhamsoftware.com (work)
> > http://www.the111shift.c
it is a critical feature for users.
> >
> > Another possibility is to offer a replacement for the feature using a
> > different API
> >
> > Your feedback will help us decide on what a potential solution should be
> >
> > --
> > -
> > Noble Paul
>
feedback will help us decide on what a potential solution should be
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail
gt;> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
> > Congratulations and welcome, Gus!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
--
---
...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
>
> --
> Adrien
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
> Congratulations and welcome, Munendra!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
--
---
On Sat, Aug 1, 2020 at 12:02 PM Noble Paul wrote:
>
> Thanks David for bringing this up.
>
> I want us to stop using concrete classes. We should exclusively use
> interfaces in our public APIs.
>
> We should stop using NamedList and start using this interface
>
> https
nc(SolrRequest
> request);
>
> BTW I'm trying to avoid implementation details here. My objective is to
> devise a user-friendly API, and my hope is that the eventual implementation
> is reasonable.
>
> I hope I haven't bored you all to tears and that you find thi
;
> > Congratulations and welcome, Mike!
> >
> > --
> > Anshum Gupta
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apach
.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC1-reva32a3ac4e43f629df71e5ae30a3330be94b095f2
>>
>> The vote will be open for at least 72 hours i.e. until 2020-08-02 22:00 UTC.
>>
>> [ ] +1 approve
>> [ ] +0 no opinion
&
It's OK,
It can wait until 8.7
On Fri, Jul 31, 2020 at 1:02 AM Houston Putman wrote:
>
> I started the process last night. Is there a reason why you want this to make
> it into 8.6.1 and not 8.7?
>
> - Houston
>
> On Thu, Jul 30, 2020 at 8:13 AM Noble Paul wrote:
>>
:27:28
>>>>> > To: dev@lucene.apache.org
>>>>> > Subject: Re: Welcome Tomoko Uchida to the PMC
>>>>> >
>>>>> > Thank you Adrien and the whole PMCs, it's a great honour for me!
>>>>> >
>>>>> > Tomok
>
> Thanks Adrien, and to the whole PMC
>
> Mike
>
> On Fri, Jul 3, 2020, 7:57 AM Adrien Grand wrote:
>>
>> I am pleased to announce that Michael Sokolov has accepted the PMC's
>> invitation to join.
>>
>> Welcome Michael!
>>
>> --
>&g
gt;>>>>>>>>>> > If we agree that this warrants a patch release, I volunteer
>>>>>>>>>>>>>>>>> > to do the release.
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>&
t; > > added to stats, facet and time series. Streaming expressions
> > added to
> > > > > > /export handler. Drill Streaming Expression for efficient and
> > accurate
> > > > > > high cardinality aggregation.
> > > > > >
> > > &
unk.
>
> Comments?
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
--
-
Noble Paul
-
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
>> http://www.opensourceconnections.com | My Free/Busy
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> This e-mail and all contents, including attachments, is considered to be
>> Company Confidential unless explicitly stated otherwise, regardless of
>> whether attachments are marked as such.
>>
--
-
Noble Paul
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
SUCCESS! [1:07:35.754307]
with Java 8
+1
On Wed, Jul 8, 2020 at 9:20 PM Noble Paul wrote:
>
> it worked Uwe.
> But there was a test failure
> [junit4] Tests with failures [seed: D6C8B0CC504808B4]:
>[junit4] -
> org.apache.solr.cloud.api.collections.TestHdfsCloudBack
apache.org/repos/dist/dev/lucene/lucene-solr-8.6.0-RC1-reva9c5fb0da2dfc8c7375622c80dbf1a0cc26f44dc
>
> The vote will be open for at least 72 hours i.e. until 2020-07-11 09:00 UTC.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here is my +1
dfc8c7375622c80dbf1a0cc26f44dc
>
> The vote will be open for at least 72 hours i.e. until 2020-07-11 09:00 UTC.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Here
It was not urgent. I think we are too late for any new addition. I
shall add it to the next release
On Tue, Jul 7, 2020 at 11:12 PM Noble Paul wrote:
>
> I would like to commit
> https://issues.apache.org/jira/browse/SOLR-14634 as well please
>
> On Tue, Jul 7, 2020 at 6:04 PM
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 Bru
of solr/packaging toDir task)... The
> bigger issue with gradle is that somebody has to step up and try to identify
> any other issues and/or missing bits when trying to do a full release cycle.
>
> D.
>
>
--
-
Noble Paul
---
15:22, Joel Bernstein wrote:
>>
>> Welcome Ilan!
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>>
>> On Mon, Jun 22, 2020 at 9:11 AM Michael McCandless
>> wrote:
>>>
>>> Welcome Ilan!
>>>
>>> Mike McCan
Hi all,
Please join me in welcoming Ilan Ginzburg as the latest Lucene/Solr
committer.
Ilan, it's tradition for you to introduce yourself with a brief bio.
Congratulations and Welcome!
Noble
1 - 100 of 7042 matches
Mail list logo
