Cool. FYI this does also seem to apply to Copilot Chat if you join the
waiting list. I think it took a few weeks for me to get accepted from the
wait list. It seems significantly less capable than cut and pasting to
ChatGPT4, but it does come with an 8K context and seemingly no request
limits,
I’ve been working on this Jira issue to make Robert and Uwe redundant in
case they get hit by a bus or don’t survive SkyNet. Virtual Uwe is much
further along, with a full 3D avatar model and fully cloned voice, but they
are both coming along, despite some kinks still to be worked out and
upgrades
Hmm, sorry bout that, I assumed there would be no request. I must have
requested way way back or something. I just went to the page where it used
to ask me to pick a yearly or monthly payment and it said I don’t have to
pay when it used to make me pick. But I just read it went GA, so that seems
Purely FYI
Figured it’s worth sharing that committers now appear to have free access
to GitHub Copilot.
Didn’t seem to in the past - I used the free trial, didn’t find it worth
paying the 100 bucks for it to be part of my current ecosystem of dev
tools, but as I was on my way out, I saw this
who knows. No proposal yet, but there may be something interesting that
pops up here before too long.
Mark
On Fri, Oct 8, 2021 at 7:08 PM Mark Miller wrote:
> This is not a proposal to add one more benchmark module to Lucene, but
> I've been digging into simpler ways to explore luce
This is not a proposal to add one more benchmark module to Lucene, but I've
been digging into simpler ways to explore luceneutil benchmark behavior via
a home game that allows simpler rules and introspection.
I've got a couple half baked straw-men already that I have been playing
with for such an
SOLR-1 is critical query path and appears able to currently fail up to
150 tests per run due to what looks mostly to be stats/metrics races,
though it’s hard to be sure that’s all with all the noise. Do you have an
update you can push Mike?
MRM
On Tue, Sep 7, 2021 at 12:35 PM David Smiley
some merging or something. So I see some benefit on
lots of threads coming into the indexwriter with docs, but perhaps wait
times are more time shifted than reduced or something, so further research
needed as well.
- Mark
On Wed, Apr 21, 2021 at 12:02 AM Mark Miller wrote:
> So I've ne
So I've never really been in the position of having the time or tools to
easily and efficiently pound on Lucene updates - always lacked one of the
ingredients, and having a beer while a bit stocked up on both, I've been
doing some light hammering.
Not likely some high priority item, when I say
Except for some fixes and tweaks and some planned continued testing
and banging in more real envs, I'm done with this mission.
It will take some time and effort to expose what is here, see what and
how various things can be captured and extracted, pull in others to
help with that task, etc, but
So I’m done with my mode and effort meant to ensure I don’t get knocked out
like a year and a half ago.
There is still some ongoing effort with some others that will happen to
solidify this work.
Essentially though, my starburst and then stellar effort is done (even the
party Melinda my effort
Let me amend this a bit to be a little more informative.
SolrCloud will get a second shot, I'm bringing it up because I'm near
the end of the road on my effort toward that shot (bittersweet and
thank god). It will be visible, touchable, smellable and observable.
I am not a Solr PMC member, I
So it’s been a while since I’ve brought up SolrCloud sickness. Plenty to
navigate and figure out in the meantime. Given the constraints of life,
there was a point I wanted to give and share some insight into what I could
see. But it quickly became clear that was not a great plan - just what I
was
look like a huge black star.
On Fri, Feb 26, 2021 at 4:38 AM Mark Miller wrote:
> There are already so many conflicts, you will cry and then realize there
> are more. Even worse, some things have been changed due to their
> cost/benefit failings, things that someone, somewhere, will clin
There are already so many conflicts, you will cry and then realize there
are more. Even worse, some things have been changed due to their
cost/benefit failings, things that someone, somewhere, will cling to like a
life vest.
The ref branch waits for no man, and expects the same.
It lives on
one’s supposed to sleep every single night now? You realize
that nighttime makes up half of all time?"*
On Thu, Feb 4, 2021 at 12:54 PM Mark Miller wrote:
> Thanks, I should be all set now.
>
> MRM
>
> “I’ll tell you how I feel about school, Jerry: it’s a waste of time.
and a piece of paper that says you can go take a
dump or somethin’. I mean, it’s not a place for smart people, Jerry. I know
that’s not a popular opinion, but that’s my two cents on the issue.”
On Wed, Feb 3, 2021 at 8:18 PM Mark Miller wrote:
> Hey there.
>
> Do you have SolrCloud experienc
Hey there.
Do you have SolrCloud experience? Do you build clusters and smash updates
into them? Would you prefer Solr and SolrCloud to be faster? More stable?
I'm looking for someone that is interested in engaging closely for a bit on
a project I've been working on. I'm seeking someone that
. God I’m lazy. But I love building software. Stay out of my way :)
but don’t be a stranger.
Mark
On Tue, Nov 12, 2019 at 9:37 AM Mark Miller wrote:
> Soon you guys are gonna fight about transitive deps.
>
> I encourage you to take a fresh look at everything.
>
> We have a huge
Soon you guys are gonna fight about transitive deps.
I encourage you to take a fresh look at everything.
We have a huge project that we have to harmonize deps across.
We want our deps up to date - bugs, security issues, debt, pain with more
time, deps that actually do count on min versions of
, Nov 12, 2019 at 8:28 AM Mark Miller wrote:
> You might want to pull out my jdeps stuff, probably that needs more work
> by someone up to speed - every project should be doing, its like java gave
> us this tool, it seems super underused.
>
> You might also pull the Docker test t
it, but this is the type of stuff you guys
would have to decide to keep and maintain.
On Tue, Nov 12, 2019 at 8:23 AM Mark Miller wrote:
> I'm gonna help you here, cause im not sure anyone else fully knows.
>
> On Tue, Nov 12, 2019 at 8:12 AM Michael Sokolov
> wrote:
>
>> H
I'm gonna help you here, cause im not sure anyone else fully knows.
On Tue, Nov 12, 2019 at 8:12 AM Michael Sokolov wrote:
> Hi I am playing around with the gradle build. Overall looks great!
> Thanks to everyone who has been pushing this forward. I have a few
> questions; maybe just gradle
I love Cassandra and she does amazing work :) yes and and I know others are
key to doc too.
On Sun, Nov 10, 2019 at 7:29 PM Mark Miller wrote:
> Don’t you dare ever question that. Don’t be sad you missed the twitter
> fun.
> --
> - Mark
>
> http://about.me/markrmiller
Don’t you dare ever question that. Don’t be sad you missed the twitter fun.
--
- Mark
http://about.me/markrmiller
Finally. You will not lose my knowledge. I am and will share as much as I
can with my teammates. And if you want to talk to me about Solr and Lucene
I will talk your ear off. I’m not against anyone here.
Mark
On Sun, Nov 10, 2019 at 6:04 PM Mark Miller wrote:
> And I don't know you w
3 of you where doing that.
- Mark
On Sun, Nov 10, 2019 at 5:35 PM Mark Miller wrote:
> And don't worry, there are a lot of people in my wake that don't want to
> fight with me, I'm not fun to fight with, I don't want fight with you
> either. I'm disappointed in myself and in
it out on anyone here.
- Mark
On Sun, Nov 10, 2019 at 5:16 PM Mark Miller wrote:
> New people to Solr and maybe some old ones :)
>
> This is an old project. There is a lot of stuff in the history. This whole
> thing is more about me than anyone else. This software is salvageable,
. And
you won't have all my code, you don't need all my code, and the code I
have, I'm sure you will end up with. I'm entrusting it to good hands.
- mark
On Sat, Nov 9, 2019 at 7:30 PM Mark Miller wrote:
> Dear Lucene/Solr Community,
>
> I have been searching for an answer for Solr and
Dear Lucene/Solr Community,
I have been searching for an answer for Solr and SolrCloud for a long time.
I feel like I landed in a tornado and I don’t know where the time went. I
forget even why I’m here. Because I didn’t come here to work for silicon
valley companies, or make a lot of money, or
I will even take most of the responsibility for that. Point people at me.
But I cannot take the responsibility to fix things myself.
On Wed, Nov 6, 2019 at 4:25 PM Mark Miller wrote:
> Let me put a tiny bit of these geenie back in the bottle.
>
> Solr and SolrCloud are being run by
Let me put a tiny bit of these geenie back in the bottle.
Solr and SolrCloud are being run by a billion places small and utterly huge
and providing a ridiculous amount of value to the word.
In that light, they are completely broken.
It's the same software that everywhere has been using for
Some of these are hard to trigger without doing a lot of other things. Like
you have to make the overseer much faster. Much as I dislike that thing,
you can make much much much faster as it is and that will help. Many many
bugs hide because we crawl.
On Wed, Nov 6, 2019 at 12:19 PM Mark Miller
.
ZkSolrResourceLoader SHOULD NOT fall back to SolrResourceLoader - a lot of
this type of crap also hides bugs.
On Wed, Nov 6, 2019 at 11:48 AM Mark Miller wrote:
> This BadApple stuff would have more value after more valuable work though.
>
> I can't stress it enough - you have to make this fa
This BadApple stuff would have more value after more valuable work though.
I can't stress it enough - you have to make this fast to fix it.
I'll give you some more items to consider:
* Our xml parsing is deathly slow and blocking. All blocking stuff when
cores start is death to multicore. You
for the state you want to see. Go fix that
and again, return will be huge for the effort.
On Wed, Nov 6, 2019 at 10:34 AM Mark Miller wrote:
> Just like go look. Like your dog is limping and you check it out. You will
> find fleas everywhere first, and then ticks, and then maybe some inf
bills,
but it's no mind game to get there.
On Wed, Nov 6, 2019 at 9:42 AM Mark Miller wrote:
> Really though, if you want to fix tests, start fixing the performance
> bottlenecks.
>
> Like being able to say solr.Class or just class in configs. That costs you
> your life, especially
, 2019 at 9:31 AM Mark Miller wrote:
> I mean honestly, if you just ignore me and fix the the smaller list of
> critical things that affect like everything - that will make the system at
> least look like it’s almost good.
>
> On Wed, Nov 6, 2019 at 9:22 AM Mark Miller wrote
I mean honestly, if you just ignore me and fix the the smaller list of
critical things that affect like everything - that will make the system at
least look like it’s almost good.
On Wed, Nov 6, 2019 at 9:22 AM Mark Miller wrote:
> Like one of the biggest things those auth guys do is just
the
connection. Just that will help those security tests a lot.
On Wed, Nov 6, 2019 at 9:19 AM Mark Miller wrote:
> You can still make progress this way. For example, all those like auth
> type tests, you can fix them mostly by not closing connections in
> solrdispatchfilter and waiting for c
You can still make progress this way. For example, all those like auth type
tests, you can fix them mostly by not closing connections in
solrdispatchfilter and waiting for collection creates, and maybe a security
file in zk watcher thing.
You can still make progress this way, you just prob won’t
Sorry you guys got to play therapist for a bit. 10 years to get over, most
of it buried. Had to let that beast out.
On Wed, Nov 6, 2019 at 12:33 AM Mark Miller wrote:
> Another Overseer :)
>
> I don't mean to contradict your curator statement either - I talk with the
> auth
Another Overseer :)
I don't mean to contradict your curator statement either - I talk with the
authority of god but with the confidence of no one ;)
On Tue, Nov 5, 2019 at 7:44 PM Scott Blum wrote:
> WHO OVERSEES THE OVERSEER
>
> On Tue, Nov 5, 2019 at 5:16 PM Mark Miller wrote
Bottom line, garden is a fricken mess and there are tons of attempts to
solve shit the wrong way cause nobody understands what was intended here.
At least one of those is on me.
Mark
On Tue, Nov 5, 2019 at 10:16 PM Mark Miller wrote:
> bq. SolrCloud is a ballerina. Doesn't look it, cause
. I was overloaded.
On Tue, Nov 5, 2019 at 11:01 AM Mark Miller wrote:
> And now we are to meat of it. Fill in here:
> https://issues.apache.org/jira/browse/SOLR-13888
>
> We can play in a better world, we can have fun, but some of you are going
> to have to adjust your ways. In the
, but there are
certain requirements to building an aircraft, and there certain
requirements to building this.
On Tue, Nov 5, 2019 at 10:44 AM Mark Miller wrote:
> If you had any idea how much suffering just that has caused. Not just
> users, but us.
>
> Mark
>
> On Tue, Nov 5, 201
If you had any idea how much suffering just that has caused. Not just
users, but us.
Mark
On Tue, Nov 5, 2019 at 10:38 AM Mark Miller wrote:
> It’s like 6-7 years since I quickly added a shitty collections API in my
> free time because we desperately needed SOMETHING. I don’t know if I
from Solr 4 to whatever. I was
mostly out of the loop. But this is crazy, me in there too.
Mark
On Tue, Nov 5, 2019 at 10:05 AM Mark Miller wrote:
> I'll tell you what guys, development right now sucks. I don't enjoy.
>
> But when I start to put things in shape? I get this smile, an
embly too (joke Yonik).
>
> Curator was an option initially. Then it was yet another project hosted by
> Netflix. Now it is essential.
>
>
> - Mark
>
> On Tue, Nov 5, 2019 at 9:41 AM Mark Miller wrote:
>
>> And look, we started pretty deep in the hole. Solr started w
initially. Then it was yet another project hosted by
Netflix. Now it is essential.
- Mark
On Tue, Nov 5, 2019 at 9:41 AM Mark Miller wrote:
> And look, we started pretty deep in the hole. Solr started with tons of
> bug or limitations that hardly mattered to it and hit SolrCloud in the eye
it
could go a few more rounds. SolrCloud is a ballerina. Doesn't look it,
cause we dont take care of it. But it is, and it cannot take the beating
that the brute does.
- Mark
On Tue, Nov 5, 2019 at 5:19 AM Mark Miller wrote:
> Basically I can fix 99% of this without you guys - with simple ca
about facets. So let's
meet half way.
On Tue, Nov 5, 2019 at 5:14 AM Mark Miller wrote:
> There are 10,000 problems here.
>
> So if you eventually land on one possible solution you agree on, we a
> little closer.
>
> There is no problem with the current design. Design's can al
There are 10,000 problems here.
So if you eventually land on one possible solution you agree on, we a
little closer.
There is no problem with the current design. Design's can always be
improved, sure. I've made this one fast. You won't believe me fast. The low
hanging fruit is astronomical,
* I have not been able to SELL yet.
On Sun, Nov 3, 2019 at 6:50 PM Mark Miller wrote:
> BUT .. it's in reasonable shape. More things should be done. Reduce
> unnecessary dependencies between projects - we want to avoid as much
> circular nonsense as we can. Other stuff. You might wan
for a start if and when anyone
gets interested or I come back to it.
- Mark
On Sun, Nov 3, 2019 at 6:40 AM Mark Miller wrote:
> Don’t know that I’ll be around yet in the future so I’m not going to make
> such a big change myself.
>
> Mark
>
> On Sun, Nov 3, 2019 at 12:29 AM Dav
And the bummer is, in the midst of this madness people are doing good work.
Good cleanups. Good improvements. Good features. Good code. And it’s all
basically wasted. It’s my hurts my mind.
Mark
On Sun, Nov 3, 2019 at 7:58 AM Mark Miller wrote:
> From a credentials standpoint:
>
> Yo
you.
Otherwise, I don't even have much confidence anyone else even knows this
system remotely well. All that time and effort and the most I know of it is
what awful awful shape its in and the bad trend direction.
- Mark
On Sun, Nov 3, 2019 at 7:35 AM Mark Miller wrote:
> Personally, I b
Personally, I believe the latter so strongly, if I can’t convince the
others in the raft with me, I’m jumping in and swimming to another raft
after my entire adult life here.
Mark
On Sun, Nov 3, 2019 at 7:30 AM Mark Miller wrote:
> In fact this will be a fundamental difference some of
infested waters
waiting to die actually, starting to float backwards sometimes now.
- Mark
On Sun, Nov 3, 2019 at 7:23 AM Mark Miller wrote:
> bq. They also would allow it to do it in an iterative manner without
> changing everything at once.
>
> Sadly, you can't fix this piece b
hope we don't resort to personal attacks and use this as an
> opportunity to improve our processes.
> >>> Thanks
> >>>
> >>> On Sun, Nov 3, 2019, 9:52 AM Scott Blum wrote:
> >>>>
> >>>> Very much agreed. I've been trying to figur
ht now but it's a shame
> this didn't get committed, even if imperfect.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Oct 23, 2019 at 6:51 PM Mark Miller wrote:
>
>> Popping out of the 'The Lucene
Things are also counterintuitive. The more you fix and the faster things
work the more things fail. It’s like rings of hell.
Mark
On Sat, Nov 2, 2019 at 10:29 PM Mark Miller wrote:
> And it didnt get any easier. What I did about it is kill myself multiple
> times over 2 years for weeks
of the
work as well. And so it's not easy to get out of this. Its not easy at all.
And i havent even done the hard part yet.
- Mark
On Sat, Nov 2, 2019 at 10:24 PM Mark Miller wrote:
> I mean the reality is - why do we not have just a single watcher per node
> pulling in state. We are we not tr
somehow made our
peace with it or not.
It's easy when you dont go deep. Hell thats easy to forget even if you do.
But I'm looping on it now, have to eject.
- Mark
On Sat, Nov 2, 2019 at 10:15 PM Mark Miller wrote:
> Not much. Something you can understand. How about tests < 10 second
l amount of ZK work in most cases?
>
> On Sat, Nov 2, 2019 at 5:44 PM Mark Miller wrote:
>
>> Give me a short bit to follow up and I will lay out my case and proposal.
>>
>> Everyone is then free to decide that we need to do something drastic or
>> that I
_nodes` to understand whether a replica is
>> available. It's not even foolproof since kill -9 on a solr node won't mark
>> all the replicas DOWN-- that doesn't happen until the node comes back up
>> (perversely).
>>
>> What would it take to get to a state where r
and we will still all be happier. Win win.
If we can just not make drastic changes for a just a brief week or so
window, I'll say what I have to say, you guys can judge and do whatever
you'd please.
- mark
On Fri, Nov 1, 2019 at 7:46 PM Mark Miller wrote:
> Hey All Solr Dev's,
>
> SolrClou
Hey All Solr Dev's,
SolrCloud is sick right now. The way low level Zookeeper is handeled, the
Overseer, is mix and mess of proper exception handling and super slow
startup and shutdown, adding new things all the time with no concern for
performance or proper ordering (which is harder to tell than
t;host" has an empty string default,
>> and AFAICT this is not equivalent to 127.0.0.1.
>>
>> Any thoughts on this from folks in terms of understanding if/why we can't
>> do this, or why this inconsistency is this way today?
>> Two relevant issues:
>> https://issues.apache.org/jira/browse/SOLR-2722 (Mark Miller, Hossman
>> https://issues.apache.org/jira/browse/SOLR-7976 (Shalin)
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>
--
- Mark
http://about.me/markrmiller
Popping out of the 'The Lucene Gradle Build Game Plan' thread to make sure
as many people catch this as possible.
I was looking at maybe putting the Gradle build in side by side with the
ant+ivy build today.
Unfortunately, it took me almost 24 hours to fix it, deal with the
ramifications of
Okay, I stayed up to deal with the current craziness around settings.gradle
and the fallout from that again.
Let's just put this in master today and deal with the rest there.
- Mark
On Tue, Oct 22, 2019 at 8:37 PM Mark Miller wrote:
> 3rd time for a lot of it ;)
>
> Yes, 7 is t
ave VCS and were working with “C”, the
> .c files and the compiled version .o were in the same directory. Twice in a
> week the boss typed:
>
> ‘rm * .o’
>
> rather than
>
> ‘rm *.o”
>
> deleting the source code as well. Oops.
>
>
>
> > On Oct 21, 201
And yes, if it's not clear, I've lost 80-90% of these same work before.
Total idiot.
- Mark
On Mon, Oct 21, 2019 at 8:56 PM Mark Miller wrote:
> The branch is there, certainly it can go in without me.
>
> It does need the settings.xml fix. When I think about timing, my main
> c
, Martin Gainty wrote:
> >
> > agree with david
> > as your schedule gets packed there are more than a few that are willing
> to pickup the slack
> > if the branch is checked-in and labelled we can tackle what needs to be
> done
> > From: David Smiley
> > Se
Hello Dawid, I'm sorry about the absence. I had a two week trip to SF and
that tends to steal my mind, thank god something does.
Yes, I have local changes that you should likely wait for.
There is a substantial issue with how I was mapping our directory names to
project names. That issue led to
Okay, to catch up anyone missing an email or two, I got a bit side tracked
on trying to complete the Gradle build with trying to do some Solr test
improvement work.
The short version of that offshoot is that I’ve done a lot of work to
address major core test issues in separate efforts - the
Yes, it's all in the gradle branch, locally. I would like to take it out
and put in master before moving forward with the gradle branch.
It's not a tiny amount to digest unfortunately, but the results are pretty
compelling.
I've opened an issue here: SOLR-13796: Fix Solr Test Performance
But hey, we will start using the configset specified in the test on master
again!
On Thu, Sep 26, 2019 at 3:36 PM Mark Miller wrote:
> Yes, it's all in the gradle branch, locally. I would like to take it out
> and put in master before moving forward with the gradle branch.
>
> It'
So my Gradle landing might be a little delayed, I've burned myself out a
little trying to get Solr tests to perform at top speed due to Gradle's
"dumb" parallel test distribution.
I extended the Gradle test task and made my own testFast target that is
"smart" and has been fun to play with, but
Anyway, moving on from gradle properties - I'm sure that will work out just
fine. My vote is to add support for build.properties like we have now for
users, I've said what I think beyond that (gradle.properties is for the
gradle build), I don't think I'm needed anymore there.
In terms of your
solution pale in comparison to
what can be done for our specific test situation.
I can make our tests fast (which is critically helpful for hardcore devs),
rather than focus on some general test framework that does a so so job of
mitigating long test times.
Mark
On Fri, Sep 20, 2019 at 8:47 AM Mark
On Fri, Sep 20, 2019 at 1:37 AM Dawid Weiss wrote:
> Hi Mark,
>
> > I find the Gradle way of doing things odd, but I knew better than to try
> and go directly against them.
> > So none of this is really my choosing, I went with how you are supposed
> to do it.
>
> Nah -- that's not really right.
On Wed, Sep 18, 2019 at 10:46 AM Dawid Weiss wrote:
>
> > If tests_jvms is a lucene/solr specific property, that needs to be in a
> users "multi-project" "~/.gradle" file
>
> Yeah... I'm not at all a fan of modifying the global gradle settings
> file. While it may be ok for settings that only
in the meantime, wow those workflow limits are not too bad at all. I could
stop another new test that takes 2 minutes from coming in non nightly. Now
that’s practically interesting.
Mark
On Tue, Sep 17, 2019 at 7:39 PM Mark Miller wrote:
> I think that is a little over the
I think that is a little over the top.
As it is the majority of dev and pr's and action is moving to GitHub,
whether anyone is from Syria or not.
If we decided, like most other communities on Gods green earth, to tell our
community we are going GitHub first it and expect committers to not avoid
I think I may prefer JIRA to GitHub Issues. I'm not sure.
Anyway, it's worth wondering if we can just move JIRA to GitHub. GitHub is
now a first class mirror for Apache that we can commit to, but they still
keep a primary copy of our code at Apache. Perhaps that is only a code
concern now though.
bq. Are we free to commit to that gradle branch or do you prefer PRs?
Commit away unless you are looking for feedback and a PR makes it easier.
I held onto it for long enough :) Time to get some more blood in this thing.
Also, if there are any things or parts that are important and you don't
This is no reproduce output yet, in my mind that is waiting with the tests
seed work that I started on but needs review and finishing.
tests_jvms is jvms and no user param naming is yet thought out or final
when it comes to modifying the build. I've instead stuck to exposing few
things and
.
Mark
On Mon, Sep 16, 2019 at 1:36 PM Mark Miller wrote:
> That's against Gradle best practices, if you look it up, this is the way
> Gradle is intended to work. Settings like
>
> That task description can warn about editing your file, but I feel it's
> pretty safe given that you
ect root dir and make it
> .gitignore?
>
> On Sun, Sep 15, 2019 at 8:47 PM Mark Miller wrote:
>
>> Okay, there is now a task called defaultUserConfig
>>
>> You can do gw defaultUserConfig to set some recommended settings in
>> ~/.gradle/gradle.properties. By de
defaultUserConfig --style=aggressive
Mark
On Sun, Sep 15, 2019 at 5:50 PM Mark Miller wrote:
> By the way, I did hear about the hack day and some Gradle testing, which
> is great, and very useful. Totally needed, but we also need a bit of a more
> deep core developer view of things vs the
targets and such. Of course a lot of that can come after we switch, but I
have a sneaky feeling some core devs will have deep opinions about certain
things.
Ill add a new task for default config setup.
Mark
On Sun, Sep 15, 2019 at 5:12 PM Mark Miller wrote:
> I'll just detail it out here as w
to org.gradle.workers.max and module
tasks are run in parallel by default.
By setting them the same, we get similar behavior whether we run tests from
the root directory of the project (all tests) or from a single module (say
solr-core).
On Sun, Sep 15, 2019 at 5:03 PM Mark Miller wrote:
> I've added more ab
do
> other work.
>
> -Gus
>
> On Sun, Sep 15, 2019 at 3:24 PM Mark Miller wrote:
>
>> Okay, I've tried to spread that link a little on social media as well.
>>
>> Please do some experimentation. Especially those of you that use or know
>> more esoteric
the ownership switch.
- Mark
On Sun, Sep 15, 2019 at 12:28 PM Mark Miller wrote:
> I've started to put together a little guide to help people ramp up here:
> https://cwiki.apache.org/confluence/display/SOLR/Intro+to+the+Gradle+build
>
> On Sat, Sep 14, 2019 at 9:09 PM Mark Miller wrote
I've started to put together a little guide to help people ramp up here:
https://cwiki.apache.org/confluence/display/SOLR/Intro+to+the+Gradle+build
On Sat, Sep 14, 2019 at 9:09 PM Mark Miller wrote:
> https://issues.apache.org/jira/browse/SOLR-13452
> Update the lucene-solr build from I
https://issues.apache.org/jira/browse/SOLR-13452
Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
Hey all.
Here is my Lucene and Solr 'move to Gradle' plans.
* I plan on trying to commit the Gradle build by 9/30
* In the meantime I'll do a bit more work on packaging,
Going to handle this better in the gradle build.
We should either require a specific logging impl or get better at managing
our logging jars (gradle is gonna help there).
Solr should not rely on any slf4j impl jar. It does this for some UI stuff,
but if we want to do that and properly support
[
https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924391#comment-16924391
]
Mark Miller commented on SOLR-13677:
Reverts should take place right away, else we can easily end up
[
https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920247#comment-16920247
]
Mark Miller edited comment on SOLR-13452 at 9/1/19 12:24 AM:
-
Development has
1 - 100 of 13770 matches
Mail list logo
