3rd time for a lot of it ;) Yes, 7 is the latest Gradle branch and active and pushable.
I keep what one is active up to date is the jira desc. I would not push too much complicated until I unfark settings.gradle. Mark On Tue, Oct 22, 2019 at 9:58 AM Erick Erickson <erickerick...@gmail.com> wrote: > Been there, done that. And it’s totally frustrating! > > Just to make it totally clear to me, this is the solr-13452_gradle_7 > branch of the public repo, correct? And we all can push to it? > > Cheer up, it’s always faster to do it the second time ;)… > > In the bad old days when we didn’t have 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, 2019, at 9:58 PM, Mark Miller <markrmil...@gmail.com> wrote: > > > > 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 <markrmil...@gmail.com> > 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 > concern is my availability - I'll be gone nov 14 to the end of the month > and then holidays are busy. If others want to take on the responsibility > though, I would not stop it. Trying to get gradle in while keeping my other > work from going stale was looking like a tall order by the 14th. > > > > I'm not sure what my plans are at the moment. I'm a totally idiot and > just lost 10 days of 16-20 hours per day of work, including the > settings.xml fix. Luckily at least that is straightforward enough to do > again. > > > > As it is, I have little to no desire to do much now. I'll try and make > that settings fix soon and then the build is not ready (dist needs work, > dependencies need vetting, some other make sure everything is 100% stuff) > but it can probably go in and get what it needs as we go. > > > > - Mark > > > > On Mon, Oct 21, 2019 at 7:49 AM Erick Erickson <erickerick...@gmail.com> > wrote: > > 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 <mgai...@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.smi...@gmail.com> > > > Sent: Monday, October 21, 2019 2:13 AM > > > To: Mark Miller <markrmil...@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 <markrmil...@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-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > -- > > - Mark > > > > http://about.me/markrmiller > > > > > > -- > > - Mark > > > > http://about.me/markrmiller > > -- - Mark http://about.me/markrmiller
