> 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
