> I don't think it is along the Apache way to revert somebody's commit without > an explicit permission to do so Interesting, I made the Devil's Advocate argument above with the Apache Way specifically in mind.
"Community over Code" comes up most often in terms of navigating interpersonal conflict and fostering contributors; that's valid and important. But broken builds cause concrete "Community harm" as well. 100%-fails slow down every developer working on Solr for whatever length of time the project is in that state. Established committers, first-PR contributors, Github forks, everyone. Leaving 100%-fails out there while waiting for a committer to respond or fix an issue prolongs that period: slowing down development and turning off new potential contributors all the while. So I think there's a concrete Apache Way argument for reverting early. Obviously the revert has to be done diplomatically or it risks alienating committers and undermining the other Apache Way benefits. But that's a question of execution not of approach. There are tactful, inoffensive ways to roll back a change without implying negligence, impugning skill-sets, etc. It's also not a concern that's specific to reverts - any JIRA comment or dev-list discussion pointing out issues runs into that. All that said, this is a Devil's Advocate argument I'm making here. I have no plans to go around reverting other's commits; I was just curious where others were on this in case it came up again later. Best, Jason On Fri, Sep 18, 2020 at 3:59 PM Tomás Fernández Löbbe <tomasflo...@gmail.com> wrote: > > 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 >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
