I’ll try and help with testing this feature more, as I have a specific package that needs this feature.
We are somewhat stuck in a weird time, as we’re doing some great stuff, like the packages, to make core Solr foot print smaller, which means we need to add more complexity to core Solr, yet at the same time, we don’t have the (hopefully!) cleaner structure that is being worked on in the reference_impl_dev to properly support the complexity. Don’t get discouraged! > On Sep 18, 2020, at 11:21 PM, Noble Paul <[email protected] > <mailto:[email protected]>> wrote: > > I shall revert the changes and work on a solution > > On Sat, Sep 19, 2020, 6:54 AM Jason Gerlowski <[email protected] > <mailto:[email protected]>> wrote: > > I don't think it is along the Apache way to revert somebody's commit > > without an explicit permission to do so > Interesting, I made the Devil's Advocate argument above with the > Apache Way specifically in mind. > > "Community over Code" comes up most often in terms of navigating > interpersonal conflict and fostering contributors; that's valid and > important. But broken builds cause concrete "Community harm" as well. > 100%-fails slow down every developer working on Solr for whatever > length of time the project is in that state. Established committers, > first-PR contributors, Github forks, everyone. Leaving 100%-fails out > there while waiting for a committer to respond or fix an issue > prolongs that period: slowing down development and turning off new > potential contributors all the while. So I think there's a concrete > Apache Way argument for reverting early. > > Obviously the revert has to be done diplomatically or it risks > alienating committers and undermining the other Apache Way benefits. > But that's a question of execution not of approach. There are > tactful, inoffensive ways to roll back a change without implying > negligence, impugning skill-sets, etc. It's also not a concern > that's specific to reverts - any JIRA comment or dev-list discussion > pointing out issues runs into that. > > All that said, this is a Devil's Advocate argument I'm making here. I > have no plans to go around reverting other's commits; I was just > curious where others were on this in case it came up again later. > > Best, > > Jason > > On Fri, Sep 18, 2020 at 3:59 PM Tomás Fernández Löbbe > <[email protected] <mailto:[email protected]>> wrote: > > > > I thought we were talking about reverting your own commits, not someone > > else’s... > > > > On Fri, Sep 18, 2020 at 12:31 PM Dawid Weiss <[email protected] > > <mailto:[email protected]>> wrote: > >> > >> I don't think it is along the Apache way to revert somebody's commit > >> > >> without an explicit permission to do so... Not that I would personally > >> > >> mind if somebody did it for me. > >> > >> > >> > >> On Fri, Sep 18, 2020 at 9:06 PM Tomás Fernández Löbbe > >> > >> <[email protected] <mailto:[email protected]>> wrote: > >> > >> > > >> > >> > Sometimes Jenkins may take hours to take your commit, may fail in the > >> > middle of your night, may not fail consistently, etc. That's why I don't > >> > think giving specific timeframes makes sense, but yes, as soon as you > >> > notice it's failing, it's either fix immediately or revert IMO. > >> > >> > > >> > >> > On Fri, Sep 18, 2020 at 12:03 PM Jason Gerlowski <[email protected] > >> > <mailto:[email protected]>> wrote: > >> > >> >> > >> > >> >> > If it’s inadvertently added, we either fix it within an hour or so or > >> >> > revert the offending commit > >> > >> >> > >> > >> >> > I don't want to set specific time frames, > >> > >> >> > >> > >> >> To play Devil's Advocate here: why wait even an hour to revert a 100% > >> > >> >> test failure? Reverts are usually trivial to do, unblock others > >> > >> >> immediately, and don't interfere with the fix process at all. > >> > >> >> Remembering the times I've broken the build myself, reverts even seem > >> > >> >> preferable from that position - reverting up front takes all the > >> > >> >> time-pressure off of getting out a fix. Why work under the gun when > >> > >> >> you don't have to? > >> > >> >> > >> > >> >> On Fri, Sep 18, 2020 at 1:14 PM Tomás Fernández Löbbe > >> > >> >> <[email protected] <mailto:[email protected]>> wrote: > >> > >> >> > > >> > >> >> > I believe these failures are associated to > >> >> > https://issues.apache.org/jira/browse/SOLR-14151 > >> >> > <https://issues.apache.org/jira/browse/SOLR-14151> > >> > >> >> > > >> > >> >> > • FAILED: org.apache.solr.pkg.TestPackages.classMethod > >> > >> >> > • FAILED: > >> >> > org.apache.solr.schema.PreAnalyzedFieldManagedSchemaCloudTest.testAdd2Fields > >> > >> >> > • FAILED: > >> >> > org.apache.solr.schema.ManagedSchemaRoundRobinCloudTest.testAddFieldsRoundRobin > >> > >> >> > > >> > >> >> > > IMO if a temporary instability is to be introduced deliberately, it > >> >> > > should be published on the list. If it’s inadvertently added, we > >> >> > > either fix it within an hour or so or revert the offending commit > >> > >> >> > I don't want to set specific time frames, but sometimes it's > >> >> > obviously too much time. > >> > >> >> > > >> > >> >> > On Fri, Sep 18, 2020 at 8:48 AM Atri Sharma <[email protected] > >> >> > <mailto:[email protected]>> wrote: > >> > >> >> >> > >> > >> >> >> When I said temporary, I meant 3-4 hours. Definitely not more than > >> >> >> that. > >> > >> >> >> > >> > >> >> >> IMO we should just roll back offending commits if they are easily > >> >> >> identifiable. I agree with you — we all have been guilty of breaking > >> >> >> builds (mea culpa as well). The bad part here is the longevity of > >> >> >> the failures. > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> On Fri, 18 Sep 2020 at 21:05, Erick Erickson > >> >> >> <[email protected] <mailto:[email protected]>> wrote: > >> > >> >> >>> > >> > >> >> >>> bq. IMO if a temporary instability is to be introduced > >> >> >>> deliberately, it should be published on the list > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> Actually, I disagree. Having anything in the tests that fail 100% > >> >> >>> of the time is just unacceptable since it becomes a barrier for > >> >> >>> everyone else. AFAIK, if the problem can be identified to a > >> >> >>> particular push, I have no problems with that push being > >> >> >>> unilaterally rolled back. > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> The exception for me is when the problem is addressed immediately, > >> >> >>> I’ve certainly been the source of that kind of problem, as have > >> >> >>> others. > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> What I take great exception to is the fact that some of these tests > >> >> >>> have been failing 100% of the time for the last seven days! If it’s > >> >> >>> the case that the full test suite was never run before the push > >> >> >>> that’s another discussion. Yeah, it takes a long time but… > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> Erick > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > On Sep 18, 2020, at 11:28 AM, Atri Sharma <[email protected] > >> >> >>> > <mailto:[email protected]>> wrote: > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > IMO if a temporary instability is to be introduced deliberately, > >> >> >>> > it should be published on the list. If it’s inadvertently added, > >> >> >>> > we either fix it within an hour or so or revert the offending > >> >> >>> > commit. > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > On Fri, 18 Sep 2020 at 20:26, Erick Erickson > >> >> >>> > <[email protected] <mailto:[email protected]>> wrote: > >> > >> >> >>> > >> > >> >> >>> > http://fucit.org/solr-jenkins-reports/failure-report.html > >> >> >>> > <http://fucit.org/solr-jenkins-reports/failure-report.html> > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > HdfsAutoAddReplicasTest failing 100% of the time. > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > TestPackages.classMethod failing 100% of the time > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > 3-4 AutoAddReplicas tests failing 98% of the time. > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > Is anyone looking at these? I realize the code base is changing a > >> >> >>> > lot, and some temporary instability is to be expected. What I’d > >> >> >>> > like is for some indication that people are actively addressing > >> >> >>> > these. > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > Erick > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > --------------------------------------------------------------------- > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > To unsubscribe, e-mail: [email protected] > >> >> >>> > <mailto:[email protected]> > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > For additional commands, e-mail: [email protected] > >> >> >>> > <mailto:[email protected]> > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > -- > >> > >> >> >>> > >> > >> >> >>> > Regards, > >> > >> >> >>> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > Atri > >> > >> >> >>> > >> > >> >> >>> > Apache Concerted > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> --------------------------------------------------------------------- > >> > >> >> >>> > >> > >> >> >>> To unsubscribe, e-mail: [email protected] > >> >> >>> <mailto:[email protected]> > >> > >> >> >>> > >> > >> >> >>> For additional commands, e-mail: [email protected] > >> >> >>> <mailto:[email protected]> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >> -- > >> > >> >> >> Regards, > >> > >> >> >> > >> > >> >> >> Atri > >> > >> >> >> Apache Concerted > >> > >> >> > >> > >> >> --------------------------------------------------------------------- > >> > >> >> To unsubscribe, e-mail: [email protected] > >> >> <mailto:[email protected]> > >> > >> >> For additional commands, e-mail: [email protected] > >> >> <mailto:[email protected]> > >> > >> >> > >> > >> > >> > >> --------------------------------------------------------------------- > >> > >> To unsubscribe, e-mail: [email protected] > >> <mailto:[email protected]> > >> > >> For additional commands, e-mail: [email protected] > >> <mailto:[email protected]> > >> > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > _______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
