lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <erickerick...@gmail.com>
Subject Re: The Lucene Solr Gradle Build Game plan
Date Mon, 21 Oct 2019 12:49:06 GMT
Going out on a limb here, as in “this may be a whacky idea but let’s toss it around anyway”.

- Check in the test fixes and Gradle build in the current state to master/9.0 as soon as possible.
Essentially let it break however it will, even if that means we shut off Jenkins for a while.
Or only test Lucene. Or…..

- Concentrate (all of us in our copious spare time) on fixing master at least back to the
state it is today reliability-wise.

- Cut Solr 9.0 when it’s ready. My _guess_ would be early next year.

- Slow/stop 8x development as necessary.

- Yes, the 8x code line will have a short life, about 1 year. Given that 9.0 was the first
one we required Java 11, I pretty much expected that.

I don’t have strong feelings about this proposal, so feel free to shoot it down. That said,
if we get the work Mark has done in front of everyone, there’s less incentive to “just
let Mark do it”. And it’s not like we’d be breaking the currently released version.

Erick

> On Oct 21, 2019, at 7:39 AM, Martin Gainty <mgainty@hotmail.com> 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 <david.w.smiley@gmail.com>
> Sent: Monday, October 21, 2019 2:13 AM
> To: Mark Miller <markrmiller@gmail.com>
> Cc: Lucene Dev <dev@lucene.apache.org>
> Subject: Re: The Lucene Solr Gradle Build Game plan
>  
> Thanks for your efforts Mark!
> 
> Why has the migration to Gradle somehow been blocked by performance improvements to Solr's
tests?
> What are the blockers to the Gradle branch being merged to master?  It's an experimental
shadow build, so... none?
> 
> I appreciate you want everything to be great from the beginning but I think it's better
to try and find that subjective line where it's good enough to be committed then iterated
on in follow-up issues.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> 
> On Mon, Oct 21, 2019 at 1:30 AM Mark Miller <markrmiller@gmail.com> wrote:
> 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 allowing some funny things and so addressing it makes the build a bit to
a lot less silly. Sorry Tomoko Uchida :(
> 
> Anyway, I had to pause Gradle when I remembered that Solr tests are only slow for silly
or broken reasons.
> 
> So I worked on that and then I remember that about a year and a half ago I had realized
SolrCloud was seriously rotting in come very core and key areas. At the time I spent a lot
of effort on my Starburst branch addressing some fundamental problems and patterns. I then
had a 6 week sabbatical and 3 week movie making trip. Though my own lack of care, I lost all
that work and mostly forgot about the whole thing.
> 
> Coming back to that, after wasting a lot of effort trying to find my previous work, I
set off to duplicate that work and hopefully take it a bit further. I really can't work on
anything unless until that is on a clear path to being addressed unless someone attached to
my livelihood forces me.
> 
> Meanwhile, I'll be gone half of November on across the world vacation and December is
always a mess.
> 
> On the plus side, the gradle build has gotten some great testing, but I'm little fuzzy
on when I'm ready. I will certainly be separating out these efforts. So I'll be extracting
the gradle changes to the gradle branch and keeping my new state as a separate branch.
> 
> - Mark


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


Mime
View raw message