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 > > > >
