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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
