Sanjay, I never threaten to -1 https://github.com/apache/apex-core/pull/607 <https://github.com/apache/apex-core/pull/607>. The -1 would apply to the proposal to drop SSL support and your suggestion to check on user@apex. The discussion regarding SSL including backward compatibility needs to be brought to dev@apex. Apex is not an enterprise project and it requires the community consensus prior to dropping SSL support or moving forward with incompatible changes.
Badly written code, missing and failing unit tests make it harder for everyone to contribute. It is the case that Aaron now faces when he tried to upgrade Hadoop version in the PR https://github.com/apache/apex-core/pull/607 <https://github.com/apache/apex-core/pull/607>. Travis CI and Jenkins PR builds must pass before a PR can be merged. This applies to all PRs including https://github.com/apache/apex-core/pull/607 <https://github.com/apache/apex-core/pull/607> and https://github.com/apache/apex-core/pull/569 <https://github.com/apache/apex-core/pull/569> that you mentioned. I put -1 on it as you asked to merge the PR while unit tests were still failing. Amol, when you mentioned that -1 are not rare, can you provide examples of 10 PRs that have vetos. Justin, -1 are infrequent during PR reviews in Apex. Discussions and long list of comments and suggestions to improve code is a common practice and equally applies to Apex. For example Drill (https://github.com/apache/drill/pull/1504 <https://github.com/apache/drill/pull/1504>) and Flink (https://github.com/apache/flink/pull/7351 <https://github.com/apache/flink/pull/7351>). Thank you, Vlad > On Jan 29, 2019, at 17:34, Sanjay Pujare <sanjay.puj...@gmail.com> wrote: > > I too agree with the sentiments expressed here and good to know there are > people who think like me. > > In terms of examples, you can see the PR > https://github.com/apache/apex-core/pull/569 which has a long discussion > about failing tests and who has the onus to prove what etc. In a recent PR > that abossert > <https://github.com/apache/apex-core/issues?q=is%3Apr+is%3Aopen+author%3Aabossert> > opened, > Vlad threatened to -1 an idea that was not even suggested ( > https://github.com/apache/apex-core/pull/607#discussion_r248498412) . As > Amol mentioned vetoes are not rare here and I didn't have to wait too long > for an example to turn up. > > > On Tue, Jan 29, 2019 at 3:14 PM amol kekre <amolhke...@gmail.com> wrote: > >> Justin, >> I agree with your thoughts. Vetos are not rare in Apex. We are trying to >> figure a way to get there. >> >> Amol >> >> On Tue, Jan 29, 2019 at 3:01 PM Justin Mclean <jus...@classsoftware.com> >> wrote: >> >>> Hi, >>> >>> If someone submits what you think is poor quality code just point it out >>> to them and ask them to fix it or even better fix it yourself to show >> them >>> what is expected. Vetoing something list that seems a little heavy handed >>> and is not the best way to encourage community growth. It’s better to >>> improve the quality of others contributions rather than blocking them >> from >>> contributing. Vetos in practice are very rare, how many have actually >>> occurred in this project? Wouldn't it be better to focus on practical >> ways >>> to get people involved and increase contribution rather than hypothetical >>> situations of when to veto a code change? >>> >>> Thanks, >>> Justin >>
