I shall revert the changes and work on a solution On Sat, Sep 19, 2020, 6:54 AM Jason Gerlowski <[email protected]> wrote:
> > 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 > <[email protected]> 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 <[email protected]> > 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 > >> > >> <[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] > >> > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
