I am not familiar with this part of the code, but this is perhaps a good thing, as this is a matter of policy, not who introduced which bug (I suspect that the policy issue was Robert's motivation for starting a thread at the dev list)
So, I think we have two issues: (1) Pull request https://github.com/apache/flink/pull/895 was merged without addressing Gyula's comment. (2) Commit https://github.com/apache/flink/commit/78fd2146dd00da1130910d9f23f09e2504854ef7 was merged but consensus was not reached. Let's keep the two issues separate, as tracing back whose bug a PR is fixing (recursively :-) will not lead anywhere. Now, back to the original question: I think that commits should be subject to consensus in a similar way as PRs. The right to commit does not mean that consensus should not be reached, and this is a clear case of not having consensus. Kostas On Tue, Jul 28, 2015 at 8:30 PM, Gyula Fóra <gyula.f...@gmail.com> wrote: > What concerns me here is that for FLINK-2419 I clearly indicated that there > is a test in my other PR, and since the fix was actually trivial, which > didn't break the current functionality according my test, I wanted to push > it in before my PR because that is pending on something else. I could have > added a test here that is true. > > With FLINK-2423 I was fixing some else's mistake who disregarded my message > when merging a PR. We could now revert that PR that introduced that bug, > but instead we are reverting my fix for that mistake. > > > > > Gyula Fóra <gyula.f...@gmail.com> ezt írta (időpont: 2015. júl. 28., K, > 20:19): > > > Hey, > > > > I am sorry that you feel bad about this, I only did not add a test case > > for FLINK-2419 because I am adding a test in my upcoming PR which > > verified the behaviour. > > > > As for FLINK-2423, it is actually very bad that issue is still there. You > > introduced this in your PR https://github.com/apache/flink/pull/895 > which > > I commented but no one fixed it before merging. As developing a test > takes > > quite much time here as it is tricky, I wanted to push the fix, which was > > in fact trivial. > > > > Regards, > > Gyula > > > > Robert Metzger <rmetz...@apache.org> ezt írta (időpont: 2015. júl. 28., > > K, 20:01): > > > >> Hi, > >> > >> I'm a bit unhappy how we were handling > >> https://issues.apache.org/jira/browse/FLINK-2419 today. > >> > >> I raised a concern in the JIRA because the commit for the fix didn't > >> contain any tests. Our coding guidelines [1] imply that every feature > >> should have tests. Apparently there were not enough tests for the two > bugs > >> fixed with commit 78fd2146dd. > >> > >> Also, Gyula's answer sounds like he is not willing to add tests right > now. > >> > >> I can not remember if we ever reverted a commit in the Flink community, > >> but > >> in my understanding, this is how ASF projects are doing lazy consensus > for > >> commits-without-PR. > >> So if there is a disagreement in the associated JIRA, we revert the fix > >> until there is an agreement. > >> > >> In this case, I did not immediately revert the commit, because I would > >> like > >> to see whether others in the community agree with me. > >> > >> > >> What do you think how we should handle cases like this one in the > future? > >> > >> I think its very important for committers and PMC members to be a good > >> example when it comes to following our own rules. Otherwise, how can we > >> ask > >> our contributors to adhere to these rules? > >> > >> > >> My suggestion to resolve this situation is the following: > >> - Revert commit 78fd2146dd > >> - open pull requests for FLINK-2419 and FLINK-2423 (with tests of > course), > >> review and merge them. > >> > >> > >> > >> Best, > >> Robert > >> > >> [1] http://flink.apache.org/coding-guidelines.html > >> > > >
