Again, I’m going to speak more strongly than Michael. Vladimir,
Even if you are right, that doesn’t give you the right to be uncivil. Over-riding Zoltan’s PR, for which he had asked for a review, but not received, was not OK. If you had just said “Hey Zoltan, I think I’ve come up with a better fix than your PR; do you mind if I commit it?” then Zoltan would have said “Sure”. Please do that next time. If we don’t have civility and trust, this community will fall apart. Maintaining civility is more important than fixing a bug. Julian > On Aug 28, 2018, at 4:32 PM, Michael Mior <[email protected]> wrote: > > Thanks for clarifying. It seems like this is a case where there's a broader > discussion to be had about the merits of the optimization (completely > separate from the issue at hand). > > 1) I'm not opposed to developing a fix that's better than one which was > already proposed although I think it would be good to run it by whoever > originally filed the issue. > 2) I think "backward" here is subjective. I'm not picking a side here, but > certainly there are cases where disabling a buggy optimization is the right > thing to do. > 3) Developing a different fix may sometimes be the right thing to do, but I > think other contributors would appreciate a discussion before their code is > effectively ignored. > > -- > Michael Mior > [email protected] > > > > Le mar. 28 août 2018 à 17:01, Vladimir Sitnikov <[email protected]> > a écrit : > >> Michael>One of the other side effects in this case >> Michael>seems to be (without having examined the technical merit of either >> Michael>solution) that the fix which was ultimately committed still didn't >> solve >> Michael>the original issue. >> >> I'm afraid you did are wrong here. >> My first commit implemented exactly one test. I removed @Ignored from the >> test and implemented a fix. >> >> It turned out Zoltan crafted more complex test that identified a bug in the >> v1 of the implementation. >> Note: that was a new test, and it was not included in PR707. >> Note: there are millions of test cases missing, and I know the proper way >> to cover it. >> However, it looks like everybody here likes "one test per issue" approach >> more, so I follow it somehow: I unlock a single test, so everybody is >> happy. >> >> Michael>In this case, it seems like Zoltan was still willing to help >> provide a >> solution >> >> AFAIK, no-one (including Zoltan) cares to suggest a test case to defeat >> current code in master. >> I treat that as "the feature is good enough". >> >> Michael>see the last activity on both of those before the period of >> inactivity was >> by Zoltan >> >> My point here is >> 1) It takes ~30 min to "develop+test" the fix >> 2) PR707 goes in opposite direction: it disables the optimization instead >> of just unlocking a single @Ignore test >> 3) The bug does bother me >> ==> I just fix it and merge it. >> On top of that, I see nothing I could reuse from PR707, so I had to just >> discard it. >> >> Vladimir >>
