Re: Review your squash-merge message to remove duplicate text
I could only git show the last id in your email David. That means that for most squash and merge the dialog box should be left empty, as the PR title should already have the relevant info (Jira ID + short description), right? And when the PR title does not contain this info, we should edit it prior to commit. Making sure I understand you correctly. Ilan On Thu, Jun 25, 2020 at 6:00 AM David Smiley wrote: > Fellow committers, > > When hitting that squash-merge button in GitHub UI, the first line of the > dialog for the commit message is set apart from the rest of the message. > Then it's followed by a multi-line text box for the remaining lines. The > beginning line of the rest of the message is often duplicated or > effectively redundant with that first title line. Please edit your message > so that the redundancy is gone because the whole thing winds up in the > commit message, which is ultimately rather untidy/unclean. > > Most commits are fine. Here are some examples of the problem I speak of > by 3 separate individuals: > > 57a892f896f543913d6b22a81577f69184cd94b6 > 25428013fb0ed8f8fdbebdef3f1d65dea77129c2 > 26075fc1dc06766a9d2af8bd5dd14243c0463a6b > > Thanks, > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley >
Re: The moment you've all been waiting for PLEASE READ, Gradle builds will start failing on warnings on 9x!
> Personally I think it’s too early right now. Perhaps for 9.0? WDYT? Agreed; Ant is currently the official supported path so it's too soon to switch it out to Gradle. BTW Ilan (and other fellow committers), feel free to immediately delete all that PR boilerplate text :-) It's for contributors, not us. Not that the items aren't pertinent to us but we don't need to fill it out into the PR to display to everyone what we did/didn't do. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Jun 24, 2020 at 6:47 PM Erick Erickson wrote: > Ah, ok. That makes sense. IDK how to actually accomplish that though > so I’ll leave it to someone else to figure out. > > It’s an open question when we want to take away all of the ant options and > go exclusively to Gradle. > Personally I think it’s too early right now. Perhaps for 9.0? WDYT? > > > On Jun 24, 2020, at 6:25 PM, Ilan Ginzburg wrote: > > > > What I mean is that when creating a PR, one has to (more precisely > "can") check the box that ant precommit was run. > > I'm suggesting we either replace this by gradle precommit or add gradle > precommit in the instructions. > > > > I know I was following all the items in the checklist when submitting a > PR only to see gradle precommit then fail, it would be more friendly for > newcomers to know what to do right away. > > > > I'm not suggesting doing anything differently than what you describe, > just a way to make it clearer to everybody what the expectations are. > > > > Ilan > > > > On Wed, Jun 24, 2020 at 10:26 PM Erick Erickson > wrote: > > Ilan: > > > > Failing on newly introduced warnings is much more draconian than having > to run > > “gradlew check -x test” (or precommit). Compilation will fail. So I > don’t think there’s > > any reason to add a note, it’ll smack you right in the face. > > > > “gradle check -x test” is preferred now to “gradle precommit". “gradle > check” by > > itself will do both precommit+ and testing all in one go. “gradle > helpAnt” will show > > you most equivalent tasks to what we’re all familiar with from ant for > retraining > > purposes ;). The Gradle precommit task was put there for “back compat”. > Since > > “check” depends on “precommit”, check may contain, now or in future, more > > than precommit. IDK whether they’re identical at this point, Dawid put > in that magic. > > > > Hmmm we might want to add a note that “gradlew check” does both. I think > I might > > add that in the help text for gradle though.. > > > > precommit has never really been optional, or at least people who don’t > run it and > > check in code that fails precommit were expected to fix it immediately. > And _all_ > > of us have done that at one point or another. I have to say that Gradle > is much > > faster, and just being to do “gradle check” and go do something else for > a while has > > made it much more likely that I’ll run it more often. > > > > Erick > > > > > On Jun 24, 2020, at 2:32 PM, Ilan Ginzburg wrote: > > > > > > Thank you Erick! This is useful and saves time (I was able to set up > gradle with the assistance you gave me a while ago). > > > > > > I guess that also means Gradle precommit is no longer optional and > likely the text initializing PR's descriptions should mention that in some > way... > > > > > > On Wed, Jun 24, 2020 at 9:13 AM Atri Sharma wrote: > > > Thank you so much, Erick! > > > > > > On Wed, Jun 24, 2020 at 2:48 AM Erick Erickson < > erickerick...@gmail.com> wrote: > > > > > > > > As of my push a few minutes ago, Gradle compiling on 9x WILL FAIL > if there are any warnings in the code. See LUCENE-9411. I’ve finally > finished suppressing over 8,000 warnings in Solr, so could check this in. > Many thanks to Dawid for helping me with the Gradle parts. The goal now is > to not add any _more_ SuppressWarnings if at all possible. I hope we can > start taking the suppressions out when we’re working on code, so when > working on code please consider removing some of them. > > > > > > > > I was hoping that we could also fail ant builds, but there are some > tricky dependencies in third party code that weren’t easy to resolve in the > ant world due to licensing issues, if you’re interested in details, see the > JIRA or ping me on Slack. One consequence of this is that 8x will NOT fail > on warnings, neither will Ant builds on 9x. If someone wants to try working > that out, please feel free but I’m just really tired of banging my head > against that wall. > > > > > > > > So please, Please, PLEASE start compiling 9x with Gradle or cover > your ears to keep from hearing me complain. And I’ve been taking lessons > from my 3 1/2 year old grandson on doing that LOUDLY. > > > > > > > > About SuppressWarnings. There were so many of them that there was no > hope of actually fixing the underlying causes in one go. I’ve enhanced the > BadApples report to start reporting on the number of SuppressWarnings in > each file week to week when they
Review your squash-merge message to remove duplicate text
Fellow committers, When hitting that squash-merge button in GitHub UI, the first line of the dialog for the commit message is set apart from the rest of the message. Then it's followed by a multi-line text box for the remaining lines. The beginning line of the rest of the message is often duplicated or effectively redundant with that first title line. Please edit your message so that the redundancy is gone because the whole thing winds up in the commit message, which is ultimately rather untidy/unclean. Most commits are fine. Here are some examples of the problem I speak of by 3 separate individuals: 57a892f896f543913d6b22a81577f69184cd94b6 25428013fb0ed8f8fdbebdef3f1d65dea77129c2 26075fc1dc06766a9d2af8bd5dd14243c0463a6b Thanks, ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
Re: The moment you've all been waiting for PLEASE READ, Gradle builds will start failing on warnings on 9x!
Ah, ok. That makes sense. IDK how to actually accomplish that though so I’ll leave it to someone else to figure out. It’s an open question when we want to take away all of the ant options and go exclusively to Gradle. Personally I think it’s too early right now. Perhaps for 9.0? WDYT? > On Jun 24, 2020, at 6:25 PM, Ilan Ginzburg wrote: > > What I mean is that when creating a PR, one has to (more precisely "can") > check the box that ant precommit was run. > I'm suggesting we either replace this by gradle precommit or add gradle > precommit in the instructions. > > I know I was following all the items in the checklist when submitting a PR > only to see gradle precommit then fail, it would be more friendly for > newcomers to know what to do right away. > > I'm not suggesting doing anything differently than what you describe, just a > way to make it clearer to everybody what the expectations are. > > Ilan > > On Wed, Jun 24, 2020 at 10:26 PM Erick Erickson > wrote: > Ilan: > > Failing on newly introduced warnings is much more draconian than having to > run > “gradlew check -x test” (or precommit). Compilation will fail. So I don’t > think there’s > any reason to add a note, it’ll smack you right in the face. > > “gradle check -x test” is preferred now to “gradle precommit". “gradle check” > by > itself will do both precommit+ and testing all in one go. “gradle helpAnt” > will show > you most equivalent tasks to what we’re all familiar with from ant for > retraining > purposes ;). The Gradle precommit task was put there for “back compat”. Since > “check” depends on “precommit”, check may contain, now or in future, more > than precommit. IDK whether they’re identical at this point, Dawid put in > that magic. > > Hmmm we might want to add a note that “gradlew check” does both. I think I > might > add that in the help text for gradle though.. > > precommit has never really been optional, or at least people who don’t run it > and > check in code that fails precommit were expected to fix it immediately. And > _all_ > of us have done that at one point or another. I have to say that Gradle is > much > faster, and just being to do “gradle check” and go do something else for a > while has > made it much more likely that I’ll run it more often. > > Erick > > > On Jun 24, 2020, at 2:32 PM, Ilan Ginzburg wrote: > > > > Thank you Erick! This is useful and saves time (I was able to set up gradle > > with the assistance you gave me a while ago). > > > > I guess that also means Gradle precommit is no longer optional and likely > > the text initializing PR's descriptions should mention that in some way... > > > > On Wed, Jun 24, 2020 at 9:13 AM Atri Sharma wrote: > > Thank you so much, Erick! > > > > On Wed, Jun 24, 2020 at 2:48 AM Erick Erickson > > wrote: > > > > > > As of my push a few minutes ago, Gradle compiling on 9x WILL FAIL if > > > there are any warnings in the code. See LUCENE-9411. I’ve finally > > > finished suppressing over 8,000 warnings in Solr, so could check this in. > > > Many thanks to Dawid for helping me with the Gradle parts. The goal now > > > is to not add any _more_ SuppressWarnings if at all possible. I hope we > > > can start taking the suppressions out when we’re working on code, so when > > > working on code please consider removing some of them. > > > > > > I was hoping that we could also fail ant builds, but there are some > > > tricky dependencies in third party code that weren’t easy to resolve in > > > the ant world due to licensing issues, if you’re interested in details, > > > see the JIRA or ping me on Slack. One consequence of this is that 8x will > > > NOT fail on warnings, neither will Ant builds on 9x. If someone wants to > > > try working that out, please feel free but I’m just really tired of > > > banging my head against that wall. > > > > > > So please, Please, PLEASE start compiling 9x with Gradle or cover your > > > ears to keep from hearing me complain. And I’ve been taking lessons from > > > my 3 1/2 year old grandson on doing that LOUDLY. > > > > > > About SuppressWarnings. There were so many of them that there was no hope > > > of actually fixing the underlying causes in one go. I’ve enhanced the > > > BadApples report to start reporting on the number of SuppressWarnings in > > > each file week to week when they increase or decrease. I’ll be nudging > > > people if the number of SuppressWarnings starts going up, starting > > > Monday. I can’t help but think understanding generics will be improved by > > > working through new warnings. > > > > > > A couple of side notes for IntelliJ users (IDK about other IDEs, but I’d > > > be surprised if there weren’t similar capabilities): > > > > > > - When you just open the project, Gradle is automatically configured. > > > There’s no need to execute the “gradlew idea” task. > > > > > > - You can execute tasks in IntelliJ _really easily_ by clicking on them > > > in t
Re: The moment you've all been waiting for PLEASE READ, Gradle builds will start failing on warnings on 9x!
What I mean is that when creating a PR, one has to (more precisely "can") check the box that ant precommit was run. I'm suggesting we either replace this by gradle precommit or add gradle precommit in the instructions. I know I was following all the items in the checklist when submitting a PR only to see gradle precommit then fail, it would be more friendly for newcomers to know what to do right away. I'm not suggesting doing anything differently than what you describe, just a way to make it clearer to everybody what the expectations are. Ilan On Wed, Jun 24, 2020 at 10:26 PM Erick Erickson wrote: > Ilan: > > Failing on newly introduced warnings is much more draconian than having to > run > “gradlew check -x test” (or precommit). Compilation will fail. So I don’t > think there’s > any reason to add a note, it’ll smack you right in the face. > > “gradle check -x test” is preferred now to “gradle precommit". “gradle > check” by > itself will do both precommit+ and testing all in one go. “gradle helpAnt” > will show > you most equivalent tasks to what we’re all familiar with from ant for > retraining > purposes ;). The Gradle precommit task was put there for “back compat”. > Since > “check” depends on “precommit”, check may contain, now or in future, more > than precommit. IDK whether they’re identical at this point, Dawid put in > that magic. > > Hmmm we might want to add a note that “gradlew check” does both. I think I > might > add that in the help text for gradle though.. > > precommit has never really been optional, or at least people who don’t run > it and > check in code that fails precommit were expected to fix it immediately. > And _all_ > of us have done that at one point or another. I have to say that Gradle is > much > faster, and just being to do “gradle check” and go do something else for a > while has > made it much more likely that I’ll run it more often. > > Erick > > > On Jun 24, 2020, at 2:32 PM, Ilan Ginzburg wrote: > > > > Thank you Erick! This is useful and saves time (I was able to set up > gradle with the assistance you gave me a while ago). > > > > I guess that also means Gradle precommit is no longer optional and > likely the text initializing PR's descriptions should mention that in some > way... > > > > On Wed, Jun 24, 2020 at 9:13 AM Atri Sharma wrote: > > Thank you so much, Erick! > > > > On Wed, Jun 24, 2020 at 2:48 AM Erick Erickson > wrote: > > > > > > As of my push a few minutes ago, Gradle compiling on 9x WILL FAIL if > there are any warnings in the code. See LUCENE-9411. I’ve finally finished > suppressing over 8,000 warnings in Solr, so could check this in. Many > thanks to Dawid for helping me with the Gradle parts. The goal now is to > not add any _more_ SuppressWarnings if at all possible. I hope we can start > taking the suppressions out when we’re working on code, so when working on > code please consider removing some of them. > > > > > > I was hoping that we could also fail ant builds, but there are some > tricky dependencies in third party code that weren’t easy to resolve in the > ant world due to licensing issues, if you’re interested in details, see the > JIRA or ping me on Slack. One consequence of this is that 8x will NOT fail > on warnings, neither will Ant builds on 9x. If someone wants to try working > that out, please feel free but I’m just really tired of banging my head > against that wall. > > > > > > So please, Please, PLEASE start compiling 9x with Gradle or cover your > ears to keep from hearing me complain. And I’ve been taking lessons from my > 3 1/2 year old grandson on doing that LOUDLY. > > > > > > About SuppressWarnings. There were so many of them that there was no > hope of actually fixing the underlying causes in one go. I’ve enhanced the > BadApples report to start reporting on the number of SuppressWarnings in > each file week to week when they increase or decrease. I’ll be nudging > people if the number of SuppressWarnings starts going up, starting Monday. > I can’t help but think understanding generics will be improved by working > through new warnings. > > > > > > A couple of side notes for IntelliJ users (IDK about other IDEs, but > I’d be surprised if there weren’t similar capabilities): > > > > > > - When you just open the project, Gradle is automatically configured. > There’s no need to execute the “gradlew idea” task. > > > > > > - You can execute tasks in IntelliJ _really easily_ by clicking on > them in the gradle window, it’s on the extreme right. It seems much more > robust than trying the same thing in Ant. > > > > > > -- The “assemble” task will bring up a convenient window showing > errors (including warnings) that you can click on and get right to the > offending code. “classes” and “testClasses” are also very useful tasks to > execute in this context. > > > > > > - The “inspections” in IntelliJ point out a lot of things, but not > anything with SuppressWarnings. It may be worth coming to consensus on > which inspe
Re: The moment you've all been waiting for PLEASE READ, Gradle builds will start failing on warnings on 9x!
Ilan: Failing on newly introduced warnings is much more draconian than having to run “gradlew check -x test” (or precommit). Compilation will fail. So I don’t think there’s any reason to add a note, it’ll smack you right in the face. “gradle check -x test” is preferred now to “gradle precommit". “gradle check” by itself will do both precommit+ and testing all in one go. “gradle helpAnt” will show you most equivalent tasks to what we’re all familiar with from ant for retraining purposes ;). The Gradle precommit task was put there for “back compat”. Since “check” depends on “precommit”, check may contain, now or in future, more than precommit. IDK whether they’re identical at this point, Dawid put in that magic. Hmmm we might want to add a note that “gradlew check” does both. I think I might add that in the help text for gradle though.. precommit has never really been optional, or at least people who don’t run it and check in code that fails precommit were expected to fix it immediately. And _all_ of us have done that at one point or another. I have to say that Gradle is much faster, and just being to do “gradle check” and go do something else for a while has made it much more likely that I’ll run it more often. Erick > On Jun 24, 2020, at 2:32 PM, Ilan Ginzburg wrote: > > Thank you Erick! This is useful and saves time (I was able to set up gradle > with the assistance you gave me a while ago). > > I guess that also means Gradle precommit is no longer optional and likely the > text initializing PR's descriptions should mention that in some way... > > On Wed, Jun 24, 2020 at 9:13 AM Atri Sharma wrote: > Thank you so much, Erick! > > On Wed, Jun 24, 2020 at 2:48 AM Erick Erickson > wrote: > > > > As of my push a few minutes ago, Gradle compiling on 9x WILL FAIL if there > > are any warnings in the code. See LUCENE-9411. I’ve finally finished > > suppressing over 8,000 warnings in Solr, so could check this in. Many > > thanks to Dawid for helping me with the Gradle parts. The goal now is to > > not add any _more_ SuppressWarnings if at all possible. I hope we can start > > taking the suppressions out when we’re working on code, so when working on > > code please consider removing some of them. > > > > I was hoping that we could also fail ant builds, but there are some tricky > > dependencies in third party code that weren’t easy to resolve in the ant > > world due to licensing issues, if you’re interested in details, see the > > JIRA or ping me on Slack. One consequence of this is that 8x will NOT fail > > on warnings, neither will Ant builds on 9x. If someone wants to try working > > that out, please feel free but I’m just really tired of banging my head > > against that wall. > > > > So please, Please, PLEASE start compiling 9x with Gradle or cover your ears > > to keep from hearing me complain. And I’ve been taking lessons from my 3 > > 1/2 year old grandson on doing that LOUDLY. > > > > About SuppressWarnings. There were so many of them that there was no hope > > of actually fixing the underlying causes in one go. I’ve enhanced the > > BadApples report to start reporting on the number of SuppressWarnings in > > each file week to week when they increase or decrease. I’ll be nudging > > people if the number of SuppressWarnings starts going up, starting Monday. > > I can’t help but think understanding generics will be improved by working > > through new warnings. > > > > A couple of side notes for IntelliJ users (IDK about other IDEs, but I’d be > > surprised if there weren’t similar capabilities): > > > > - When you just open the project, Gradle is automatically configured. > > There’s no need to execute the “gradlew idea” task. > > > > - You can execute tasks in IntelliJ _really easily_ by clicking on them in > > the gradle window, it’s on the extreme right. It seems much more robust > > than trying the same thing in Ant. > > > > -- The “assemble” task will bring up a convenient window showing errors > > (including warnings) that you can click on and get right to the offending > > code. “classes” and “testClasses” are also very useful tasks to execute in > > this context. > > > > - The “inspections” in IntelliJ point out a lot of things, but not anything > > with SuppressWarnings. It may be worth coming to consensus on which > > inspections are worth enabling. And perhaps distributing a configuration. > > For instance, do we really care for inspections reporting “blah could be > > final”? They’re highlighted in yellow in my setup, and I’ve done nothing > > special. Spend some time looking at those when you’re working on code… the > > number of “method may return null” inspections is scary. Have we’ve ever > > had the released code generate an NPE or anything like that . > > > > - Please do NOT suppress the _inspections_ in IntelliJ. One of the choices > > IntelliJ offers is to suppress an inspection, and it adds a > > “suppressInspection” comme
Re: 8.6 release
Thanks starting this discussion, Cassandra. I reviewed the issues I was involved with and I don't quite see something worth noting. I plan to add a note about a change in defaults within UnifiedHighlighter that could be a significant perf regression. This wasn't introduced in 8.6 but introduced in 8.5 and it's significant enough to bring attention to. I could add it in 8.5's section but then add a short pointer to it in 8.6. ~ David On Wed, Jun 24, 2020 at 2:52 PM Cassandra Targett wrote: > I started looking at the Ref Guide for 8.6 to get it ready, and notice > there are no Upgrade Notes in `solr-upgrade-notes.adoc` for 8.6. Is it > really true that none are needed at all? > > I’ll add what I usually do about new features/changes that maybe wouldn’t > normally make the old Upgrade Notes section, I just find it surprising that > there weren’t any devs who thought any of the 100 or so Solr changes > warrant any user caveats. > On Jun 17, 2020, 12:27 PM -0500, Tomás Fernández Löbbe < > tomasflo...@gmail.com>, wrote: > > +1. Thanks Bruno > > On Wed, Jun 17, 2020 at 6:22 AM Mike Drob wrote: > >> +1 >> >> The release wizard python script should be sufficient for 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 Bruno Roustant >> wrote: >> >>> Hi all, >>> >>> It’s been a while since we released Lucene/Solr 8.5. >>> I’d like to volunteer to be a release manager for an 8.6 release. If >>> there's agreement, then I plan to cut the release branch two weeks today, >>> on June 30th, and then to build the first RC two days later. >>> >>> This will be my first time as release manager so I'll probably need some >>> guidance. Currently I have two resource links on this subject: >>> https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo >>> >>> https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#releasewizardpy >>> If you have more, please share with me. >>> >>> Bruno >>> >>
Re: 8.6 release
I started looking at the Ref Guide for 8.6 to get it ready, and notice there are no Upgrade Notes in `solr-upgrade-notes.adoc` for 8.6. Is it really true that none are needed at all? I’ll add what I usually do about new features/changes that maybe wouldn’t normally make the old Upgrade Notes section, I just find it surprising that there weren’t any devs who thought any of the 100 or so Solr changes warrant any user caveats. On Jun 17, 2020, 12:27 PM -0500, Tomás Fernández Löbbe , wrote: > +1. Thanks Bruno > > > On Wed, Jun 17, 2020 at 6:22 AM Mike Drob wrote: > > > +1 > > > > > > The release wizard python script should be sufficient for 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 Bruno Roustant > > > > wrote: > > > > > Hi all, > > > > > > > > > > It’s been a while since we released Lucene/Solr 8.5. > > > > > I’d like to volunteer to be a release manager for an 8.6 release. If > > > > > there's agreement, then I plan to cut the release branch two weeks > > > > > today, on June 30th, and then to build the first RC two days later. > > > > > > > > > > This will be my first time as release manager so I'll probably need > > > > > some guidance. Currently I have two resource links on this subject: > > > > > https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo > > > > > https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#releasewizardpy > > > > > If you have more, please share with me. > > > > > > > > > > Bruno
Re: The moment you've all been waiting for PLEASE READ, Gradle builds will start failing on warnings on 9x!
Thank you Erick! This is useful and saves time (I was able to set up gradle with the assistance you gave me a while ago). I guess that also means Gradle precommit is no longer optional and likely the text initializing PR's descriptions should mention that in some way... On Wed, Jun 24, 2020 at 9:13 AM Atri Sharma wrote: > Thank you so much, Erick! > > On Wed, Jun 24, 2020 at 2:48 AM Erick Erickson > wrote: > > > > As of my push a few minutes ago, Gradle compiling on 9x WILL FAIL if > there are any warnings in the code. See LUCENE-9411. I’ve finally finished > suppressing over 8,000 warnings in Solr, so could check this in. Many > thanks to Dawid for helping me with the Gradle parts. The goal now is to > not add any _more_ SuppressWarnings if at all possible. I hope we can start > taking the suppressions out when we’re working on code, so when working on > code please consider removing some of them. > > > > I was hoping that we could also fail ant builds, but there are some > tricky dependencies in third party code that weren’t easy to resolve in the > ant world due to licensing issues, if you’re interested in details, see the > JIRA or ping me on Slack. One consequence of this is that 8x will NOT fail > on warnings, neither will Ant builds on 9x. If someone wants to try working > that out, please feel free but I’m just really tired of banging my head > against that wall. > > > > So please, Please, PLEASE start compiling 9x with Gradle or cover your > ears to keep from hearing me complain. And I’ve been taking lessons from my > 3 1/2 year old grandson on doing that LOUDLY. > > > > About SuppressWarnings. There were so many of them that there was no > hope of actually fixing the underlying causes in one go. I’ve enhanced the > BadApples report to start reporting on the number of SuppressWarnings in > each file week to week when they increase or decrease. I’ll be nudging > people if the number of SuppressWarnings starts going up, starting Monday. > I can’t help but think understanding generics will be improved by working > through new warnings. > > > > A couple of side notes for IntelliJ users (IDK about other IDEs, but I’d > be surprised if there weren’t similar capabilities): > > > > - When you just open the project, Gradle is automatically configured. > There’s no need to execute the “gradlew idea” task. > > > > - You can execute tasks in IntelliJ _really easily_ by clicking on them > in the gradle window, it’s on the extreme right. It seems much more robust > than trying the same thing in Ant. > > > > -- The “assemble” task will bring up a convenient window showing errors > (including warnings) that you can click on and get right to the offending > code. “classes” and “testClasses” are also very useful tasks to execute in > this context. > > > > - The “inspections” in IntelliJ point out a lot of things, but not > anything with SuppressWarnings. It may be worth coming to consensus on > which inspections are worth enabling. And perhaps distributing a > configuration. For instance, do we really care for inspections reporting > “blah could be final”? They’re highlighted in yellow in my setup, and I’ve > done nothing special. Spend some time looking at those when you’re working > on code… the number of “method may return null” inspections is scary. Have > we’ve ever had the released code generate an NPE or anything like that > . > > > > - Please do NOT suppress the _inspections_ in IntelliJ. One of the > choices IntelliJ offers is to suppress an inspection, and it adds a > “suppressInspection” comment to the source code specific to IntelliJ. This > is different than Javas’s SuppressWarnings, and we shouldn’t include > comments in the code specific to a particular IDE. > > > > - The motivation here is that we need all the help from the compiler we > can get when it comes to as large and complex a code base as Lucene/Solr. > Yes, it feels constraining. Yes, it means we won’t feel as productive > because we have to take time to address things we’ve been ignoring. The > leap of faith is that if we spend a bit of time up front, we can avoid > having to spend a lot _more_ time fixing errors later in the release cycle. > The time it takes to fix a problem goes up exponentially the farther down > the cycle it’s caught. Fixing something when developing may take T minutes. > Some time later when test start failing, it takes T*X. And when you > consider community-wide implications of releasing code, getting feedback > from the field, filing a JIRA, trying to reproduce the problem, checking > the code, and pushing a fix, the cost of fixing something after it’s > released goes up enormously. I’m not saying that addressing all the > complaints something like IntelliJ’s inspections show will magically make > it unnecessary to make point releases, but avoiding just a few is a win. > > > > > Erick > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene
Re: [jira] [Created] (SOLR-14591) Move JoinQuery in JoinQParserPlugin to its own class
No, it did not fail for me locally. I tracked it from failing build in a PR I had raised. On Wed, 24 Jun 2020 at 18:51, Erick Erickson wrote: > Cool. You want to take over SOLR-14591 then? Or mark it as duplicate if > you already have one. > > Curiosity question: Did you have gradlew check or precommit fail locally? > Because I’m puzzled why > it doesn’t fail locally for me. > > Erick > > > On Jun 24, 2020, at 9:00 AM, Erick Erickson (Jira) > wrote: > > > > Erick Erickson created SOLR-14591: > > - > > > > Summary: Move JoinQuery in JoinQParserPlugin to its own class > > Key: SOLR-14591 > > URL: https://issues.apache.org/jira/browse/SOLR-14591 > > Project: Solr > > Issue Type: Sub-task > >Reporter: Erick Erickson > >Assignee: Erick Erickson > > > > > > Not sure why this isn't being flagged as a warning in master, but it did > cause an error on a Jenkins build, there's no reason NOT to fix it. > > > > > > > > -- > > This message was sent by Atlassian Jira > > (v8.3.4#803005) > > > > - > > To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org > > For additional commands, e-mail: issues-h...@lucene.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Regards, Atri Apache Concerted
Re: [jira] [Created] (SOLR-14591) Move JoinQuery in JoinQParserPlugin to its own class
Cool. You want to take over SOLR-14591 then? Or mark it as duplicate if you already have one. Curiosity question: Did you have gradlew check or precommit fail locally? Because I’m puzzled why it doesn’t fail locally for me. Erick > On Jun 24, 2020, at 9:00 AM, Erick Erickson (Jira) wrote: > > Erick Erickson created SOLR-14591: > - > > Summary: Move JoinQuery in JoinQParserPlugin to its own class > Key: SOLR-14591 > URL: https://issues.apache.org/jira/browse/SOLR-14591 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson > > > Not sure why this isn't being flagged as a warning in master, but it did > cause an error on a Jenkins build, there's no reason NOT to fix it. > > > > -- > This message was sent by Atlassian Jira > (v8.3.4#803005) > > - > To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org > For additional commands, e-mail: issues-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Created] (SOLR-14591) Move JoinQuery in JoinQParserPlugin to its own class
I noticed this today — am testing a patch to fix this right now On Wed, 24 Jun 2020 at 18:30, Erick Erickson (Jira) wrote: > Erick Erickson created SOLR-14591: > - > > Summary: Move JoinQuery in JoinQParserPlugin to its own class > Key: SOLR-14591 > URL: https://issues.apache.org/jira/browse/SOLR-14591 > Project: Solr > Issue Type: Sub-task > Reporter: Erick Erickson > Assignee: Erick Erickson > > > Not sure why this isn't being flagged as a warning in master, but it did > cause an error on a Jenkins build, there's no reason NOT to fix it. > > > > -- > This message was sent by Atlassian Jira > (v8.3.4#803005) > > - > To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org > For additional commands, e-mail: issues-h...@lucene.apache.org > > -- Regards, Atri Apache Concerted
Re: Welcome Ilan Ginzburg as Lucene/Solr committer
I've been to Grenoble once. It is indeed a beautiful city. On Mon, Jun 22, 2020 at 11:45 PM Ilan Ginzburg wrote: > > Thank you, merci, תודה for the trust and the welcome, Noble and everybody! > > I’m based in France near Grenoble, a flat city high tech hub surrounded by > mountains. > > For the past 7 years I’ve been working on Search at Salesforce. Currently > focusing on SolrCloud scaling. > I also work on making Solr nodes stateless, separating compute from storage > to better fit Public Cloud environments (see > Activate '18, Activate '19, SOLR-13101 WIP). > > Past employers include EMC/Documentum, HP Labs Palo Alto, Intel. Earlier > still I created the Apple 2 game Saracen (old timers here might remember?). > > Other activities include a lot of paragliding, cycling, hiking, drumming > (here during COVID) and a few stints working as a photographer. > > I hold a MA in business administration and a PhD in computer science > (parallel computing). > > I’m extremely happy to join the Lucene/Solr community, the future looks > exciting! > > Ilan > > On Mon 22 Jun 2020 at 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 McCandless >>> >>> http://blog.mikemccandless.com >>> >>> >>> On Sun, Jun 21, 2020 at 5:44 AM Noble Paul wrote: 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 -- - Noble Paul - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: The moment you've all been waiting for PLEASE READ, Gradle builds will start failing on warnings on 9x!
Thank you so much, Erick! On Wed, Jun 24, 2020 at 2:48 AM Erick Erickson wrote: > > As of my push a few minutes ago, Gradle compiling on 9x WILL FAIL if there > are any warnings in the code. See LUCENE-9411. I’ve finally finished > suppressing over 8,000 warnings in Solr, so could check this in. Many thanks > to Dawid for helping me with the Gradle parts. The goal now is to not add any > _more_ SuppressWarnings if at all possible. I hope we can start taking the > suppressions out when we’re working on code, so when working on code please > consider removing some of them. > > I was hoping that we could also fail ant builds, but there are some tricky > dependencies in third party code that weren’t easy to resolve in the ant > world due to licensing issues, if you’re interested in details, see the JIRA > or ping me on Slack. One consequence of this is that 8x will NOT fail on > warnings, neither will Ant builds on 9x. If someone wants to try working that > out, please feel free but I’m just really tired of banging my head against > that wall. > > So please, Please, PLEASE start compiling 9x with Gradle or cover your ears > to keep from hearing me complain. And I’ve been taking lessons from my 3 1/2 > year old grandson on doing that LOUDLY. > > About SuppressWarnings. There were so many of them that there was no hope of > actually fixing the underlying causes in one go. I’ve enhanced the BadApples > report to start reporting on the number of SuppressWarnings in each file week > to week when they increase or decrease. I’ll be nudging people if the number > of SuppressWarnings starts going up, starting Monday. I can’t help but think > understanding generics will be improved by working through new warnings. > > A couple of side notes for IntelliJ users (IDK about other IDEs, but I’d be > surprised if there weren’t similar capabilities): > > - When you just open the project, Gradle is automatically configured. There’s > no need to execute the “gradlew idea” task. > > - You can execute tasks in IntelliJ _really easily_ by clicking on them in > the gradle window, it’s on the extreme right. It seems much more robust than > trying the same thing in Ant. > > -- The “assemble” task will bring up a convenient window showing errors > (including warnings) that you can click on and get right to the offending > code. “classes” and “testClasses” are also very useful tasks to execute in > this context. > > - The “inspections” in IntelliJ point out a lot of things, but not anything > with SuppressWarnings. It may be worth coming to consensus on which > inspections are worth enabling. And perhaps distributing a configuration. For > instance, do we really care for inspections reporting “blah could be final”? > They’re highlighted in yellow in my setup, and I’ve done nothing special. > Spend some time looking at those when you’re working on code… the number of > “method may return null” inspections is scary. Have we’ve ever had the > released code generate an NPE or anything like that . > > - Please do NOT suppress the _inspections_ in IntelliJ. One of the choices > IntelliJ offers is to suppress an inspection, and it adds a > “suppressInspection” comment to the source code specific to IntelliJ. This is > different than Javas’s SuppressWarnings, and we shouldn’t include comments in > the code specific to a particular IDE. > > - The motivation here is that we need all the help from the compiler we can > get when it comes to as large and complex a code base as Lucene/Solr. Yes, it > feels constraining. Yes, it means we won’t feel as productive because we have > to take time to address things we’ve been ignoring. The leap of faith is that > if we spend a bit of time up front, we can avoid having to spend a lot _more_ > time fixing errors later in the release cycle. The time it takes to fix a > problem goes up exponentially the farther down the cycle it’s caught. Fixing > something when developing may take T minutes. Some time later when test start > failing, it takes T*X. And when you consider community-wide implications of > releasing code, getting feedback from the field, filing a JIRA, trying to > reproduce the problem, checking the code, and pushing a fix, the cost of > fixing something after it’s released goes up enormously. I’m not saying that > addressing all the complaints something like IntelliJ’s inspections show will > magically make it unnecessary to make point releases, but avoiding just a few > is a win. > > Erick > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- Regards, Atri Apache Concerted - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: The moment you've all been waiting for PLEASE READ, Gradle builds will start failing on warnings on 9x!
Looking forward to it! Thanks Erick! On Wed, 24 Jun, 2020, 7:26 am Erick Erickson, wrote: > re: checkstyle. Feel free to have at that debate ;) > > > On Jun 23, 2020, at 6:51 PM, Michael Sokolov wrote: > > > > +1 thanks huge step forward for code hygiene > > > > Maybe someday we will agree on a minimal check style enforcement too 😮 > ... > > Sorry, too soon? > > > > On Tue, Jun 23, 2020, 6:21 PM Anshum Gupta > wrote: > > Thanks, Erick! This is awesome :) > > > > On Tue, Jun 23, 2020 at 2:18 PM Erick Erickson > wrote: > > As of my push a few minutes ago, Gradle compiling on 9x WILL FAIL if > there are any warnings in the code. See LUCENE-9411. I’ve finally finished > suppressing over 8,000 warnings in Solr, so could check this in. Many > thanks to Dawid for helping me with the Gradle parts. The goal now is to > not add any _more_ SuppressWarnings if at all possible. I hope we can start > taking the suppressions out when we’re working on code, so when working on > code please consider removing some of them. > > > > I was hoping that we could also fail ant builds, but there are some > tricky dependencies in third party code that weren’t easy to resolve in the > ant world due to licensing issues, if you’re interested in details, see the > JIRA or ping me on Slack. One consequence of this is that 8x will NOT fail > on warnings, neither will Ant builds on 9x. If someone wants to try working > that out, please feel free but I’m just really tired of banging my head > against that wall. > > > > So please, Please, PLEASE start compiling 9x with Gradle or cover your > ears to keep from hearing me complain. And I’ve been taking lessons from my > 3 1/2 year old grandson on doing that LOUDLY. > > > > About SuppressWarnings. There were so many of them that there was no > hope of actually fixing the underlying causes in one go. I’ve enhanced the > BadApples report to start reporting on the number of SuppressWarnings in > each file week to week when they increase or decrease. I’ll be nudging > people if the number of SuppressWarnings starts going up, starting Monday. > I can’t help but think understanding generics will be improved by working > through new warnings. > > > > A couple of side notes for IntelliJ users (IDK about other IDEs, but I’d > be surprised if there weren’t similar capabilities): > > > > - When you just open the project, Gradle is automatically configured. > There’s no need to execute the “gradlew idea” task. > > > > - You can execute tasks in IntelliJ _really easily_ by clicking on them > in the gradle window, it’s on the extreme right. It seems much more robust > than trying the same thing in Ant. > > > > -- The “assemble” task will bring up a convenient window showing errors > (including warnings) that you can click on and get right to the offending > code. “classes” and “testClasses” are also very useful tasks to execute in > this context. > > > > - The “inspections” in IntelliJ point out a lot of things, but not > anything with SuppressWarnings. It may be worth coming to consensus on > which inspections are worth enabling. And perhaps distributing a > configuration. For instance, do we really care for inspections reporting > “blah could be final”? They’re highlighted in yellow in my setup, and I’ve > done nothing special. Spend some time looking at those when you’re working > on code… the number of “method may return null” inspections is scary. Have > we’ve ever had the released code generate an NPE or anything like that > . > > > > - Please do NOT suppress the _inspections_ in IntelliJ. One of the > choices IntelliJ offers is to suppress an inspection, and it adds a > “suppressInspection” comment to the source code specific to IntelliJ. This > is different than Javas’s SuppressWarnings, and we shouldn’t include > comments in the code specific to a particular IDE. > > > > - The motivation here is that we need all the help from the compiler we > can get when it comes to as large and complex a code base as Lucene/Solr. > Yes, it feels constraining. Yes, it means we won’t feel as productive > because we have to take time to address things we’ve been ignoring. The > leap of faith is that if we spend a bit of time up front, we can avoid > having to spend a lot _more_ time fixing errors later in the release cycle. > The time it takes to fix a problem goes up exponentially the farther down > the cycle it’s caught. Fixing something when developing may take T minutes. > Some time later when test start failing, it takes T*X. And when you > consider community-wide implications of releasing code, getting feedback > from the field, filing a JIRA, trying to reproduce the problem, checking > the code, and pushing a fix, the cost of fixing something after it’s > released goes up enormously. I’m not saying that addressing all the > complaints something like IntelliJ’s inspections show will magically make > it unnecessary to make point releases, but avoiding just a few is a win. > > > > > Erick > > -
