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
