Re: [VOTE] ACCUMULO-3176
So, it's been 5 days since last activity here, and there are still some questions/requests for response left unanswered regarding the veto. I'd really like a response to these questions so we can put this issue to rest. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Nov 26, 2014 at 1:21 PM, Christopher ctubb...@apache.org wrote: On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey bus...@cloudera.com wrote: Responses to a few things below. On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss bfl...@praxiseng.com wrote: Aren’t API-breaking changes allowed in 1.7? If this change is ok for 2.0, then what is the technical reason why it is ok for version 2.0 but vetoed for version 1.7? On Nov 25, 2014, at 3:48 PM, Sean Busbey bus...@cloudera.com wrote: How about if we push this change in the API out to the client reworking in 2.0? Everything will break there anyways so users will already have to deal with the change. As I previously mentioned, API breaking changes are allowed on major revisions. Currently, 1.7 is a major revision (and I have consistently argued for it to remain classified as such). That doesn't mean we shouldn't consider the cost to end users of making said changes. There is no way to know that there won't be a 1.8 or later version after 1.7 and before 2.0. We already have consensus to do a sweeping overhaul of the API for that later release and have had that consensus for quite some time. Since users will already have to deal with that breakage in 2.0 I don't see this improvement as worth making them deal with changes prior to that. So, are you arguing for no more API additions until 2.0? Because, that's what it sounds like. As is, your general objection to the API seems to be independent of this change, but reflective of an overall policy for API additions. Please address why your argument applies to this specific change, and wouldn't to other API additions. Otherwise, this seems to be a case of special pleading. Please address the fact that there is no breakage here, and we can ensure that there won't be any more removal (except in exceptional circumstances) of deprecated APIs until 2.0 to ease changes. (I actually think that would be a very reasonable policy to adopt today.) In addition, I fully expect that 2.0 will be fully compatible with 1.7, and will also not introduce any breakage except removal of things already deprecated in 1.7. If we make this change without marking the previous createTable methods as deprecated, this new API addition AND the previous createTable API will still be available in 2.0 (as deprecated), and will not be removed until 3.0. You have also previously argued for more intermediate releases between major releases. Please explain how you see omitting this API addition is compatible with that goal. Please also explain why, if you consider 1.7 to be a major (expected) release, why such an addition would not be appropriate, but would be appropriate for a future major release (2.0). On Tue, Nov 25, 2014 at 4:18 PM, Christopher ctubb...@apache.org wrote: On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki bhava...@clouderagovt.com wrote: In my interpretation of Sean's veto, what he says is bad - using the ASF word here - is not that the change leaves the property update unsolved. It's that it changes the API without completely solving it. The purpose of the change is not explicitly to alter the API, but it does cause that to happen, and it is that aspect that is bad (with the given justification). I just want to clarify my reasoning. That is my current understanding, as well. Additionally, it seems to me that the two things that make it bad is that it A) doesn't achieve an additional purpose (which can be achieved with additional work), and that B) it deprecates existing methods (which can be avoided). Unless there's some other reason that makes it a bad change, or something else that we still need to discuss, I would urge Sean to retract his veto with the proposed compromise to not deprecate and the creation of an independent JIRA issue to address the concerns about update race conditions. Back and forth negotiation to find a solution that addresses both the concerns of an objector and the proposer of a change should happen on the jira and/or reviewboard for that change. They should not happen on a formal VOTE thread following that objection; they most certainly should not only happen after an attempt to use process to ignore the concerns has failed. Nobody is ignoring the concerns raised. We are attempting to resolve those through reasonable dialogue and are attempting to lobby you to retract your veto, after addressing your concerns, in accordance with the section of the bylaws which describes vetoes. This is the appropriate place to do that, because a consensus vote is not simply a number tallying action, as a
Re: [VOTE] ACCUMULO-3176
I'm not sure what questions weren't previously answered in my explanations, could you please restate which ever ones you want clarification on? The vote is closed and only has 2 binding +1s. That means it fails under consensus rules regardless of my veto, so the issue seems moot. On Mon, Dec 1, 2014 at 1:59 PM, Christopher ctubb...@apache.org wrote: So, it's been 5 days since last activity here, and there are still some questions/requests for response left unanswered regarding the veto. I'd really like a response to these questions so we can put this issue to rest. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Nov 26, 2014 at 1:21 PM, Christopher ctubb...@apache.org wrote: On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey bus...@cloudera.com wrote: Responses to a few things below. On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss bfl...@praxiseng.com wrote: Aren’t API-breaking changes allowed in 1.7? If this change is ok for 2.0, then what is the technical reason why it is ok for version 2.0 but vetoed for version 1.7? On Nov 25, 2014, at 3:48 PM, Sean Busbey bus...@cloudera.com wrote: How about if we push this change in the API out to the client reworking in 2.0? Everything will break there anyways so users will already have to deal with the change. As I previously mentioned, API breaking changes are allowed on major revisions. Currently, 1.7 is a major revision (and I have consistently argued for it to remain classified as such). That doesn't mean we shouldn't consider the cost to end users of making said changes. There is no way to know that there won't be a 1.8 or later version after 1.7 and before 2.0. We already have consensus to do a sweeping overhaul of the API for that later release and have had that consensus for quite some time. Since users will already have to deal with that breakage in 2.0 I don't see this improvement as worth making them deal with changes prior to that. So, are you arguing for no more API additions until 2.0? Because, that's what it sounds like. As is, your general objection to the API seems to be independent of this change, but reflective of an overall policy for API additions. Please address why your argument applies to this specific change, and wouldn't to other API additions. Otherwise, this seems to be a case of special pleading. Please address the fact that there is no breakage here, and we can ensure that there won't be any more removal (except in exceptional circumstances) of deprecated APIs until 2.0 to ease changes. (I actually think that would be a very reasonable policy to adopt today.) In addition, I fully expect that 2.0 will be fully compatible with 1.7, and will also not introduce any breakage except removal of things already deprecated in 1.7. If we make this change without marking the previous createTable methods as deprecated, this new API addition AND the previous createTable API will still be available in 2.0 (as deprecated), and will not be removed until 3.0. You have also previously argued for more intermediate releases between major releases. Please explain how you see omitting this API addition is compatible with that goal. Please also explain why, if you consider 1.7 to be a major (expected) release, why such an addition would not be appropriate, but would be appropriate for a future major release (2.0). On Tue, Nov 25, 2014 at 4:18 PM, Christopher ctubb...@apache.org wrote: On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki bhava...@clouderagovt.com wrote: In my interpretation of Sean's veto, what he says is bad - using the ASF word here - is not that the change leaves the property update unsolved. It's that it changes the API without completely solving it. The purpose of the change is not explicitly to alter the API, but it does cause that to happen, and it is that aspect that is bad (with the given justification). I just want to clarify my reasoning. That is my current understanding, as well. Additionally, it seems to me that the two things that make it bad is that it A) doesn't achieve an additional purpose (which can be achieved with additional work), and that B) it deprecates existing methods (which can be avoided). Unless there's some other reason that makes it a bad change, or something else that we still need to discuss, I would urge Sean to retract his veto with the proposed compromise to not deprecate and the creation of an independent JIRA issue to address the concerns about update race conditions. Back and forth negotiation to find a solution that addresses both the concerns of an objector and the proposer of a change should happen on the jira and/or reviewboard for that change. They should not happen on a formal VOTE thread following that objection; they
Re: [VOTE] ACCUMULO-3176
On Mon, Dec 1, 2014 at 3:29 PM, Sean Busbey bus...@cloudera.com wrote: I'm not sure what questions weren't previously answered in my explanations, could you please restate which ever ones you want clarification on? The question I was most curious about was why you are ok w/ making this API change in 2.0 but not 1.7.0. I do not understand the reasoning behind this. The vote is closed and only has 2 binding +1s. That means it fails under consensus rules regardless of my veto, so the issue seems moot. Well shame on me for not voting. Better late than never. +1 On Mon, Dec 1, 2014 at 1:59 PM, Christopher ctubb...@apache.org wrote: So, it's been 5 days since last activity here, and there are still some questions/requests for response left unanswered regarding the veto. I'd really like a response to these questions so we can put this issue to rest. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Nov 26, 2014 at 1:21 PM, Christopher ctubb...@apache.org wrote: On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey bus...@cloudera.com wrote: Responses to a few things below. On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss bfl...@praxiseng.com wrote: Aren’t API-breaking changes allowed in 1.7? If this change is ok for 2.0, then what is the technical reason why it is ok for version 2.0 but vetoed for version 1.7? On Nov 25, 2014, at 3:48 PM, Sean Busbey bus...@cloudera.com wrote: How about if we push this change in the API out to the client reworking in 2.0? Everything will break there anyways so users will already have to deal with the change. As I previously mentioned, API breaking changes are allowed on major revisions. Currently, 1.7 is a major revision (and I have consistently argued for it to remain classified as such). That doesn't mean we shouldn't consider the cost to end users of making said changes. There is no way to know that there won't be a 1.8 or later version after 1.7 and before 2.0. We already have consensus to do a sweeping overhaul of the API for that later release and have had that consensus for quite some time. Since users will already have to deal with that breakage in 2.0 I don't see this improvement as worth making them deal with changes prior to that. So, are you arguing for no more API additions until 2.0? Because, that's what it sounds like. As is, your general objection to the API seems to be independent of this change, but reflective of an overall policy for API additions. Please address why your argument applies to this specific change, and wouldn't to other API additions. Otherwise, this seems to be a case of special pleading. Please address the fact that there is no breakage here, and we can ensure that there won't be any more removal (except in exceptional circumstances) of deprecated APIs until 2.0 to ease changes. (I actually think that would be a very reasonable policy to adopt today.) In addition, I fully expect that 2.0 will be fully compatible with 1.7, and will also not introduce any breakage except removal of things already deprecated in 1.7. If we make this change without marking the previous createTable methods as deprecated, this new API addition AND the previous createTable API will still be available in 2.0 (as deprecated), and will not be removed until 3.0. You have also previously argued for more intermediate releases between major releases. Please explain how you see omitting this API addition is compatible with that goal. Please also explain why, if you consider 1.7 to be a major (expected) release, why such an addition would not be appropriate, but would be appropriate for a future major release (2.0). On Tue, Nov 25, 2014 at 4:18 PM, Christopher ctubb...@apache.org wrote: On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki bhava...@clouderagovt.com wrote: In my interpretation of Sean's veto, what he says is bad - using the ASF word here - is not that the change leaves the property update unsolved. It's that it changes the API without completely solving it. The purpose of the change is not explicitly to alter the API, but it does cause that to happen, and it is that aspect that is bad (with the given justification). I just want to clarify my reasoning. That is my current understanding, as well. Additionally, it seems to me that the two things that make it bad is that it A) doesn't achieve an additional purpose (which can be achieved with additional work), and that B) it deprecates existing methods (which can be avoided). Unless there's some other reason that makes it a bad change, or something else that we still need to discuss, I would urge Sean to retract his veto
Re: [VOTE] ACCUMULO-3176
I still don't understand what could even be changed to help you retract your veto. A number of people here have made suggestions about altering the changes to the public API WRT to the major version. I think Brian was the most recent, but I recall asking the same question on the original JIRA issue too. Sean Busbey wrote: I'm not sure what questions weren't previously answered in my explanations, could you please restate which ever ones you want clarification on? The vote is closed and only has 2 binding +1s. That means it fails under consensus rules regardless of my veto, so the issue seems moot. On Mon, Dec 1, 2014 at 1:59 PM, Christopherctubb...@apache.org wrote: So, it's been 5 days since last activity here, and there are still some questions/requests for response left unanswered regarding the veto. I'd really like a response to these questions so we can put this issue to rest. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Nov 26, 2014 at 1:21 PM, Christopherctubb...@apache.org wrote: On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbeybus...@cloudera.com wrote: Responses to a few things below. On Tue, Nov 25, 2014 at 2:56 PM, Brian Lossbfl...@praxiseng.com wrote: Aren’t API-breaking changes allowed in 1.7? If this change is ok for 2.0, then what is the technical reason why it is ok for version 2.0 but vetoed for version 1.7? On Nov 25, 2014, at 3:48 PM, Sean Busbeybus...@cloudera.com wrote: How about if we push this change in the API out to the client reworking in 2.0? Everything will break there anyways so users will already have to deal with the change. As I previously mentioned, API breaking changes are allowed on major revisions. Currently, 1.7 is a major revision (and I have consistently argued for it to remain classified as such). That doesn't mean we shouldn't consider the cost to end users of making said changes. There is no way to know that there won't be a 1.8 or later version after 1.7 and before 2.0. We already have consensus to do a sweeping overhaul of the API for that later release and have had that consensus for quite some time. Since users will already have to deal with that breakage in 2.0 I don't see this improvement as worth making them deal with changes prior to that. So, are you arguing for no more API additions until 2.0? Because, that's what it sounds like. As is, your general objection to the API seems to be independent of this change, but reflective of an overall policy for API additions. Please address why your argument applies to this specific change, and wouldn't to other API additions. Otherwise, this seems to be a case of special pleading. Please address the fact that there is no breakage here, and we can ensure that there won't be any more removal (except in exceptional circumstances) of deprecated APIs until 2.0 to ease changes. (I actually think that would be a very reasonable policy to adopt today.) In addition, I fully expect that 2.0 will be fully compatible with 1.7, and will also not introduce any breakage except removal of things already deprecated in 1.7. If we make this change without marking the previous createTable methods as deprecated, this new API addition AND the previous createTable API will still be available in 2.0 (as deprecated), and will not be removed until 3.0. You have also previously argued for more intermediate releases between major releases. Please explain how you see omitting this API addition is compatible with that goal. Please also explain why, if you consider 1.7 to be a major (expected) release, why such an addition would not be appropriate, but would be appropriate for a future major release (2.0). On Tue, Nov 25, 2014 at 4:18 PM, Christopherctubb...@apache.org wrote: On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki bhava...@clouderagovt.com wrote: In my interpretation of Sean's veto, what he says is bad - using the ASF word here - is not that the change leaves the property update unsolved. It's that it changes the API without completely solving it. The purpose of the change is not explicitly to alter the API, but it does cause that to happen, and it is that aspect that is bad (with the given justification). I just want to clarify my reasoning. That is my current understanding, as well. Additionally, it seems to me that the two things that make it bad is that it A) doesn't achieve an additional purpose (which can be achieved with additional work), and that B) it deprecates existing methods (which can be avoided). Unless there's some other reason that makes it a bad change, or something else that we still need to discuss, I would urge Sean to retract his veto with the proposed compromise to not deprecate and the creation of an independent JIRA issue to address the concerns about update race conditions. Back and forth negotiation to find a solution that addresses both the concerns of an objector and the proposer of a change
Re: [VOTE] ACCUMULO-3176
+1 in case it wasn't inferred from my previous comments. As Josh stated, I'm still confused how the veto still holds technical justification- the changes being made aren't removing methods from the public API. On Mon, Dec 1, 2014 at 3:42 PM, Josh Elser josh.el...@gmail.com wrote: I still don't understand what could even be changed to help you retract your veto. A number of people here have made suggestions about altering the changes to the public API WRT to the major version. I think Brian was the most recent, but I recall asking the same question on the original JIRA issue too. Sean Busbey wrote: I'm not sure what questions weren't previously answered in my explanations, could you please restate which ever ones you want clarification on? The vote is closed and only has 2 binding +1s. That means it fails under consensus rules regardless of my veto, so the issue seems moot. On Mon, Dec 1, 2014 at 1:59 PM, Christopherctubb...@apache.org wrote: So, it's been 5 days since last activity here, and there are still some questions/requests for response left unanswered regarding the veto. I'd really like a response to these questions so we can put this issue to rest. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Nov 26, 2014 at 1:21 PM, Christopherctubb...@apache.org wrote: On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbeybus...@cloudera.com wrote: Responses to a few things below. On Tue, Nov 25, 2014 at 2:56 PM, Brian Lossbfl...@praxiseng.com wrote: Aren’t API-breaking changes allowed in 1.7? If this change is ok for 2.0, then what is the technical reason why it is ok for version 2.0 but vetoed for version 1.7? On Nov 25, 2014, at 3:48 PM, Sean Busbeybus...@cloudera.com wrote: How about if we push this change in the API out to the client reworking in 2.0? Everything will break there anyways so users will already have to deal with the change. As I previously mentioned, API breaking changes are allowed on major revisions. Currently, 1.7 is a major revision (and I have consistently argued for it to remain classified as such). That doesn't mean we shouldn't consider the cost to end users of making said changes. There is no way to know that there won't be a 1.8 or later version after 1.7 and before 2.0. We already have consensus to do a sweeping overhaul of the API for that later release and have had that consensus for quite some time. Since users will already have to deal with that breakage in 2.0 I don't see this improvement as worth making them deal with changes prior to that. So, are you arguing for no more API additions until 2.0? Because, that's what it sounds like. As is, your general objection to the API seems to be independent of this change, but reflective of an overall policy for API additions. Please address why your argument applies to this specific change, and wouldn't to other API additions. Otherwise, this seems to be a case of special pleading. Please address the fact that there is no breakage here, and we can ensure that there won't be any more removal (except in exceptional circumstances) of deprecated APIs until 2.0 to ease changes. (I actually think that would be a very reasonable policy to adopt today.) In addition, I fully expect that 2.0 will be fully compatible with 1.7, and will also not introduce any breakage except removal of things already deprecated in 1.7. If we make this change without marking the previous createTable methods as deprecated, this new API addition AND the previous createTable API will still be available in 2.0 (as deprecated), and will not be removed until 3.0. You have also previously argued for more intermediate releases between major releases. Please explain how you see omitting this API addition is compatible with that goal. Please also explain why, if you consider 1.7 to be a major (expected) release, why such an addition would not be appropriate, but would be appropriate for a future major release (2.0). On Tue, Nov 25, 2014 at 4:18 PM, Christopherctubb...@apache.org wrote: On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki bhava...@clouderagovt.com wrote: In my interpretation of Sean's veto, what he says is bad - using the ASF word here - is not that the change leaves the property update unsolved. It's that it changes the API without completely solving it. The purpose of the change is not explicitly to alter the API, but it does cause that to happen, and it is that aspect that is bad (with the given justification). I just want to clarify my reasoning. That is my current understanding, as well. Additionally, it seems to me that the two things that make it bad is that it A) doesn't achieve an additional purpose (which can be achieved with additional work), and that B) it deprecates existing methods (which can be avoided). Unless there's some other reason that
Re: [VOTE] ACCUMULO-3176
I was having issues with apache's mail forwarding. I would have been +1. I don't consider adding a new api breaking it. It would be nice to have the root synchronization of config updates settled, but that was outside the scope of the ticket. On Mon, Dec 1, 2014, 3:55 PM Corey Nolet cjno...@gmail.com wrote: +1 in case it wasn't inferred from my previous comments. As Josh stated, I'm still confused how the veto still holds technical justification- the changes being made aren't removing methods from the public API. On Mon, Dec 1, 2014 at 3:42 PM, Josh Elser josh.el...@gmail.com wrote: I still don't understand what could even be changed to help you retract your veto. A number of people here have made suggestions about altering the changes to the public API WRT to the major version. I think Brian was the most recent, but I recall asking the same question on the original JIRA issue too. Sean Busbey wrote: I'm not sure what questions weren't previously answered in my explanations, could you please restate which ever ones you want clarification on? The vote is closed and only has 2 binding +1s. That means it fails under consensus rules regardless of my veto, so the issue seems moot. On Mon, Dec 1, 2014 at 1:59 PM, Christopherctubb...@apache.org wrote: So, it's been 5 days since last activity here, and there are still some questions/requests for response left unanswered regarding the veto. I'd really like a response to these questions so we can put this issue to rest. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Nov 26, 2014 at 1:21 PM, Christopherctubb...@apache.org wrote: On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbeybus...@cloudera.com wrote: Responses to a few things below. On Tue, Nov 25, 2014 at 2:56 PM, Brian Lossbfl...@praxiseng.com wrote: Aren’t API-breaking changes allowed in 1.7? If this change is ok for 2.0, then what is the technical reason why it is ok for version 2.0 but vetoed for version 1.7? On Nov 25, 2014, at 3:48 PM, Sean Busbeybus...@cloudera.com wrote: How about if we push this change in the API out to the client reworking in 2.0? Everything will break there anyways so users will already have to deal with the change. As I previously mentioned, API breaking changes are allowed on major revisions. Currently, 1.7 is a major revision (and I have consistently argued for it to remain classified as such). That doesn't mean we shouldn't consider the cost to end users of making said changes. There is no way to know that there won't be a 1.8 or later version after 1.7 and before 2.0. We already have consensus to do a sweeping overhaul of the API for that later release and have had that consensus for quite some time. Since users will already have to deal with that breakage in 2.0 I don't see this improvement as worth making them deal with changes prior to that. So, are you arguing for no more API additions until 2.0? Because, that's what it sounds like. As is, your general objection to the API seems to be independent of this change, but reflective of an overall policy for API additions. Please address why your argument applies to this specific change, and wouldn't to other API additions. Otherwise, this seems to be a case of special pleading. Please address the fact that there is no breakage here, and we can ensure that there won't be any more removal (except in exceptional circumstances) of deprecated APIs until 2.0 to ease changes. (I actually think that would be a very reasonable policy to adopt today.) In addition, I fully expect that 2.0 will be fully compatible with 1.7, and will also not introduce any breakage except removal of things already deprecated in 1.7. If we make this change without marking the previous createTable methods as deprecated, this new API addition AND the previous createTable API will still be available in 2.0 (as deprecated), and will not be removed until 3.0. You have also previously argued for more intermediate releases between major releases. Please explain how you see omitting this API addition is compatible with that goal. Please also explain why, if you consider 1.7 to be a major (expected) release, why such an addition would not be appropriate, but would be appropriate for a future major release (2.0). On Tue, Nov 25, 2014 at 4:18 PM, Christopherctubb...@apache.org wrote: On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki bhava...@clouderagovt.com wrote: In my interpretation of Sean's veto, what he says is bad - using the ASF word here - is not that the change leaves the property update unsolved. It's that it changes the API without completely solving it. The purpose of the change is not explicitly
Re: [VOTE] ACCUMULO-3176
On Mon, Dec 1, 2014 at 3:29 PM, Sean Busbey bus...@cloudera.com wrote: I'm not sure what questions weren't previously answered in my explanations, could you please restate which ever ones you want clarification on? Explicit questions and outstanding requests for clarification since your last response (see previous emails for details and context): - So, are you arguing for no more API additions until 2.0? - Please address the fact that there is no breakage here... - Please explain how you see omitting this API addition is compatible with [the goal of supporting non-major intermediate releases]. Please also explain why, if you consider 1.7 to be a major (expected) release, why such an addition would not be appropriate, but would be appropriate for a future major release (2.0). - Another reasonable compromise has also been proposed that seems to address all of your concerns. Please explain why it does not. Brian also asked: - I don’t see what breakage users would be required to deal with if the proposed changes were made. A new method would be added to the API and some existing methods deprecated (presumably to be removed in 2.0). So how would this hurt our users? - Given that you are ok with with the change in 2.0, it seems that your objection is not to the content of the change but rather the timing of it. Given that users aren’t required to use the new API method added by the change, this objection and the veto seem invalid to me. Am I missing something? The vote is closed and only has 2 binding +1s. That means it fails under consensus rules regardless of my veto, so the issue seems moot. The issue is not moot. As multiple people have emphasized, a veto is the start of dialogue, not the end of it. Addressing these questions/requests pertaining to your veto will help establish consensus moving forward, and provide background for future votes on this (and perhaps other) issues. You also cannot reasonably expect the community to be bound by vetoes which are not defended against when questioned. Leaving questions unanswered in regards to your veto simply because the time has elapsed sets a very bad precedent for how to handle vetoes. On Mon, Dec 1, 2014 at 1:59 PM, Christopher ctubb...@apache.org wrote: So, it's been 5 days since last activity here, and there are still some questions/requests for response left unanswered regarding the veto. I'd really like a response to these questions so we can put this issue to rest. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Wed, Nov 26, 2014 at 1:21 PM, Christopher ctubb...@apache.org wrote: On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey bus...@cloudera.com wrote: Responses to a few things below. On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss bfl...@praxiseng.com wrote: Aren’t API-breaking changes allowed in 1.7? If this change is ok for 2.0, then what is the technical reason why it is ok for version 2.0 but vetoed for version 1.7? On Nov 25, 2014, at 3:48 PM, Sean Busbey bus...@cloudera.com wrote: How about if we push this change in the API out to the client reworking in 2.0? Everything will break there anyways so users will already have to deal with the change. As I previously mentioned, API breaking changes are allowed on major revisions. Currently, 1.7 is a major revision (and I have consistently argued for it to remain classified as such). That doesn't mean we shouldn't consider the cost to end users of making said changes. There is no way to know that there won't be a 1.8 or later version after 1.7 and before 2.0. We already have consensus to do a sweeping overhaul of the API for that later release and have had that consensus for quite some time. Since users will already have to deal with that breakage in 2.0 I don't see this improvement as worth making them deal with changes prior to that. So, are you arguing for no more API additions until 2.0? Because, that's what it sounds like. As is, your general objection to the API seems to be independent of this change, but reflective of an overall policy for API additions. Please address why your argument applies to this specific change, and wouldn't to other API additions. Otherwise, this seems to be a case of special pleading. Please address the fact that there is no breakage here, and we can ensure that there won't be any more removal (except in exceptional circumstances) of deprecated APIs until 2.0 to ease changes. (I actually think that would be a very reasonable policy to adopt today.) In addition, I fully expect that 2.0 will be fully compatible with 1.7, and will also not introduce any breakage except removal of things already deprecated in 1.7. If we make this change without marking the previous createTable methods as deprecated, this new API addition
