It passes for me all the time Erick Can you please test with the branch https://github.com/apache/lucene-solr/tree/jira/solr14879
On Sun, Sep 20, 2020 at 7:14 AM Erick Erickson <erickerick...@gmail.com> wrote: > > This seems to be a reproducing seed, at least 2/2 > > ant test -Dtestcase=TestPackages -Dtests.seed=C29471044D369FD3 > -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=et-EE > -Dtests.timezone=Europe/Mariehamn -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 > > > On Sep 19, 2020, at 6:40 AM, Eric Pugh <ep...@opensourceconnections.com> > > wrote: > > > > 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 <noble.p...@gmail.com> wrote: > >> > >> I shall revert the changes and work on a solution > >> > >> On Sat, Sep 19, 2020, 6:54 AM Jason Gerlowski <gerlowsk...@gmail.com> > >> 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 > >> <tomasflo...@gmail.com> 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 <dawid.we...@gmail.com> > >> > 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 > >> >> > >> >> <tomasflo...@gmail.com> 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 > >> >> > <gerlowsk...@gmail.com> 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 > >> >> > >> >> >> <tomasflo...@gmail.com> wrote: > >> >> > >> >> >> > > >> >> > >> >> >> > I believe these failures are associated to > >> >> >> > 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 <a...@apache.org> > >> >> >> > 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 > >> >> >> >> <erickerick...@gmail.com> 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 <a...@apache.org> > >> >> >> >>> > 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 > >> >> >> >>> > <erickerick...@gmail.com> wrote: > >> >> > >> >> >> >>> > >> >> > >> >> >> >>> > 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: 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 > >> >> > >> >> >> >>> > >> >> > >> >> >> >>> > >> >> > >> >> >> >>> > >> >> > >> >> >> >> -- > >> >> > >> >> >> >> Regards, > >> >> > >> >> >> >> > >> >> > >> >> >> >> Atri > >> >> > >> >> >> >> Apache Concerted > >> >> > >> >> >> > >> >> > >> >> >> --------------------------------------------------------------------- > >> >> > >> >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> >> > >> >> >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> >> > >> >> >> > >> >> > >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> > >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> >> > >> >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> >> > >> >> > >> >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > _______________________ > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > > http://www.opensourceconnections.com | My Free/Busy > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > > 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. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
