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
