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 <[email protected]> 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 <[email protected]> > 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 >> <[email protected]> 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 <[email protected]> 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 <[email protected]> >> >> 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 <[email protected]> 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 <[email protected]> >> >>> > 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: [email protected] >> >>> >> >>> > >> >>> >> >>> > For additional commands, e-mail: [email protected] >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> > >> >>> >> >>> > -- >> >>> >> >>> > Regards, >> >>> >> >>> > >> >>> >> >>> > Atri >> >>> >> >>> > Apache Concerted >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> --------------------------------------------------------------------- >> >>> >> >>> To unsubscribe, e-mail: [email protected] >> >>> >> >>> For additional commands, e-mail: [email protected] >> >>> >> >>> >> >>> >> >> -- >> >> Regards, >> >> >> >> Atri >> >> Apache Concerted >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
