On Wed, Dec 2, 2015 at 4:24 PM, Julian Hyde <jh...@apache.org> wrote: > “No explicit commit policy” means that only committers can commit. > It is each committer’s discretion whether they ask for others to review > the change before they commit it, whether they check in code that doesn’t > build, whether they run the test suite before committing. > > This policy is the bare constitutional minimum. We would all hope and expect > that the community would quickly agree on some policies, but that is up the > community. > They are not stupid, they want to produce high-quality software, and they > want to grow > their community, and they will figure out a policy that achieves these goals.
If that's the expectation that is internalized by the podling community than I guess my concerns are somewhat taken care of to a point where I'd be comfortable giving the proposal a +0. Let me explain why it is a +0 instead of +1. This will also be an opportunity for me to clarify my seemingly inconsistent position with Kudu proposal (which I deliberately +1ed). It all comes back to trust and inclusiveness. I thought that Greg was super convincing at articulating that CTR policy is an indication, a proxy if you will for those qualities. If CTR is there -- I know that the community is trusting and inclusive. My -1 for Impala was based on their strong resistance to CTR as a proxy measure of how ready they are to accept the "Apache Way". Them fighting the idea of CTR gave me a strong indication that they are resisting to being trusting and inclusive. Now, of course, as any astute student of logic will know, necessity and sufficiency is not the same thing. While a presence of CTR policy is a strong indication of the community getting the "Apache Way" the lack of it is not necessarily an indication of them not getting it. Impala community, however has one extra strike against it that wasn't allowing me to give it the same benefit of the doubt that Kudu community got (hence +1 for Kudu despite their instance on RTC). Impala and its existing community are *not* new to Open Source. They've been out on GitHub since late 2012 and they have operated under a very explicit BDFL model. Based on their past attitude towards external contributions (personalized via statement of the project lead) I have strong reasons to believe that they are going to have really tough time adjusting to the Apache governance model AND when I saw that strong resistance to CTR that was it for me. That said, this thread and the expectations articulated by Tom and others make me more comfortable. However, the lack of *actionable* suggestion for how they are going to integrate with Apache governance model makes it +0 and not +1. Thanks, Roman. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
