You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Christopher <ct...@apache.org> on 2014/12/01 20:59:03 UTC
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 <ct...@apache.org> wrote:
> On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> Responses to a few things below.
>>
>>
>> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss <bf...@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 <bu...@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 <ct...@apache.org> wrote:
>>
>> > On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki <
>> bhavanki@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
> majority vote might be considered to be.
>
>
>> That said, I am generally a proponent of not letting "where discussion
>> should happen" get in the way of reaching consensus. However, in this case
>> I don't think we have sufficient time to work through the details of why I
>> don't find API sprawl a compelling fix for my concerns. I know I
>> definitely
>> don't have the spoons for it.
>>
>> I'm sorry, but if you are unwilling to defend your veto further, I don't
> see how you can expect it to be binding. Please address why this change
> could not be introduced with the compromise proposed.
>
>
>> I have offered a reasonable compromise position that addresses both my
>> concerns while adding the feature you want. Please take it.
>>
>> Another reasonable compromise has also been proposed that seems to
> address all of your concerns. Please explain why it does not.
>
> I would also like to add that inclusion of this now would greatly help me
> add the wiring necessary for the new API.
>
>
>> I don't think I'll have time to be on email again before the vote closes.
>> You may consider my -1 withdrawn if the change is restricted to 2.0
>>
>>
>> On Tue, Nov 25, 2014 at 3:07 PM, Christopher <ct...@apache.org> wrote:
>>
>> > On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey <bu...@cloudera.com>
>> wrote:
>> >
>> > > On Tue, Nov 25, 2014 at 2:23 PM, Christopher <ct...@apache.org>
>> > wrote:
>> > >
>> > > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey <bu...@cloudera.com>
>> > > wrote:
>> > > >
>> > > >
>> > > >
>> > > I understand that the use cases enabled by this patch are sufficiently
>> > > compelling for you. They are not sufficiently compelling for me,
>> hence my
>> > > veto.
>> > >
>> > >
>> > I don't know that there is a requirement to make every code addition
>> > sufficiently compelling to every developer, in order to include it. If
>> that
>> > were the case, I don't think many features would have made it in. This
>> > seems to be an anti-progress position if we allow it to become the
>> norm. It
>> > seems to me that there should be compelling reasons to reject a
>> > contribution that does not break or affect existing functionality.
>> >
>>
>> This VOTE thread is also not the place to get into a discussion of our
>> governance model. However, what you are saying is directly opposed to the
>> fundamental way code changes work in Apache projects; it's the "Review"
>> part of Commit Then Review and Review Then Commit. We use the former
>> because we presume that most changes will be compelling. Because every
>> part
>> of "compelling" and "cost" is hugely subjective we require that vetoes
>> come
>> with a rationale.
>>
>> It is indeed very anti-progress. That's one of the overheads of being in a
>> community. It's also why I have previously stated that these change votes
>> should be Majority Approval instead of Consensus Approval.
>>
>> > Also, since you can only veto
>> > changesets, and not release candidates, I don't see what would stop a
>> > release manager from backporting this changeset to 1.7 prior to its
>> release
>> > if we push it to a 2.0 branch. I don't see why this improvement must be
>> > postponed.
>>
>> The thing that would stop them is that we are a community. It would be
>> incredibly rude for a release manager to do this after the restriction to
>> 2.0 was the end compromise reached. We are not in a state of nature and
>> the
>> bylaws are not our leviathan. We are a group working towards common goals.
>>
>>
>> --
>> Sean
>>
>
>
Re: [VOTE] ACCUMULO-3176
Posted by Keith Turner <ke...@deenlo.com>.
On Mon, Dec 1, 2014 at 3:29 PM, Sean Busbey <bu...@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 <ct...@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 <ct...@apache.org>
> wrote:
> >
> > > On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey <bu...@cloudera.com>
> > wrote:
> > >
> > >> Responses to a few things below.
> > >>
> > >>
> > >> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss <bf...@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 <bu...@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 <ct...@apache.org>
> > wrote:
> > >>
> > >> > On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki <
> > >> bhavanki@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
> > > majority vote might be considered to be.
> > >
> > >
> > >> That said, I am generally a proponent of not letting "where discussion
> > >> should happen" get in the way of reaching consensus. However, in this
> > case
> > >> I don't think we have sufficient time to work through the details of
> > why I
> > >> don't find API sprawl a compelling fix for my concerns. I know I
> > >> definitely
> > >> don't have the spoons for it.
> > >>
> > >> I'm sorry, but if you are unwilling to defend your veto further, I
> don't
> > > see how you can expect it to be binding. Please address why this change
> > > could not be introduced with the compromise proposed.
> > >
> > >
> > >> I have offered a reasonable compromise position that addresses both my
> > >> concerns while adding the feature you want. Please take it.
> > >>
> > >> Another reasonable compromise has also been proposed that seems to
> > > address all of your concerns. Please explain why it does not.
> > >
> > > I would also like to add that inclusion of this now would greatly help
> me
> > > add the wiring necessary for the new API.
> > >
> > >
> > >> I don't think I'll have time to be on email again before the vote
> > closes.
> > >> You may consider my -1 withdrawn if the change is restricted to 2.0
> > >>
> > >>
> > >> On Tue, Nov 25, 2014 at 3:07 PM, Christopher <ct...@apache.org>
> > wrote:
> > >>
> > >> > On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey <bu...@cloudera.com>
> > >> wrote:
> > >> >
> > >> > > On Tue, Nov 25, 2014 at 2:23 PM, Christopher <ctubbsii@apache.org
> >
> > >> > wrote:
> > >> > >
> > >> > > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey <
> busbey@cloudera.com
> > >
> > >> > > wrote:
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > I understand that the use cases enabled by this patch are
> > sufficiently
> > >> > > compelling for you. They are not sufficiently compelling for me,
> > >> hence my
> > >> > > veto.
> > >> > >
> > >> > >
> > >> > I don't know that there is a requirement to make every code addition
> > >> > sufficiently compelling to every developer, in order to include it.
> If
> > >> that
> > >> > were the case, I don't think many features would have made it in.
> This
> > >> > seems to be an anti-progress position if we allow it to become the
> > >> norm. It
> > >> > seems to me that there should be compelling reasons to reject a
> > >> > contribution that does not break or affect existing functionality.
> > >> >
> > >>
> > >> This VOTE thread is also not the place to get into a discussion of our
> > >> governance model. However, what you are saying is directly opposed to
> > the
> > >> fundamental way code changes work in Apache projects; it's the
> "Review"
> > >> part of Commit Then Review and Review Then Commit. We use the former
> > >> because we presume that most changes will be compelling. Because every
> > >> part
> > >> of "compelling" and "cost" is hugely subjective we require that vetoes
> > >> come
> > >> with a rationale.
> > >>
> > >> It is indeed very anti-progress. That's one of the overheads of being
> > in a
> > >> community. It's also why I have previously stated that these change
> > votes
> > >> should be Majority Approval instead of Consensus Approval.
> > >>
> > >> > Also, since you can only veto
> > >> > changesets, and not release candidates, I don't see what would stop
> a
> > >> > release manager from backporting this changeset to 1.7 prior to its
> > >> release
> > >> > if we push it to a 2.0 branch. I don't see why this improvement must
> > be
> > >> > postponed.
> > >>
> > >> The thing that would stop them is that we are a community. It would be
> > >> incredibly rude for a release manager to do this after the restriction
> > to
> > >> 2.0 was the end compromise reached. We are not in a state of nature
> and
> > >> the
> > >> bylaws are not our leviathan. We are a group working towards common
> > goals.
> > >>
> > >>
> > >> --
> > >> Sean
> > >>
> > >
> > >
> >
>
>
>
> --
> Sean
>
Re: [VOTE] ACCUMULO-3176
Posted by John Vines <vi...@apache.org>.
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 <cj...@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 <jo...@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, Christopher<ct...@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<ct...@apache.org>
> >>> wrote:
> >>>
> >>> On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey<bu...@cloudera.com>
> >>>>
> >>> wrote:
> >>>
> >>>> Responses to a few things below.
> >>>>>
> >>>>>
> >>>>> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss<bf...@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<bu...@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<ct...@apache.org>
> >>>>>
> >>>> wrote:
> >>>
> >>>> On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki<
> >>>>>>
> >>>>> bhavanki@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
> >>>> majority vote might be considered to be.
> >>>>
> >>>>
> >>>> That said, I am generally a proponent of not letting "where
> discussion
> >>>>> should happen" get in the way of reaching consensus. However, in this
> >>>>>
> >>>> case
> >>>
> >>>> I don't think we have sufficient time to work through the details of
> >>>>>
> >>>> why I
> >>>
> >>>> don't find API sprawl a compelling fix for my concerns. I know I
> >>>>> definitely
> >>>>> don't have the spoons for it.
> >>>>>
> >>>>> I'm sorry, but if you are unwilling to defend your veto further, I
> >>>>> don't
> >>>>>
> >>>> see how you can expect it to be binding. Please address why this
> change
> >>>> could not be introduced with the compromise proposed.
> >>>>
> >>>>
> >>>> I have offered a reasonable compromise position that addresses both
> my
> >>>>> concerns while adding the feature you want. Please take it.
> >>>>>
> >>>>> Another reasonable compromise has also been proposed that seems to
> >>>>>
> >>>> address all of your concerns. Please explain why it does not.
> >>>>
> >>>> I would also like to add that inclusion of this now would greatly help
> >>>> me
> >>>> add the wiring necessary for the new API.
> >>>>
> >>>>
> >>>> I don't think I'll have time to be on email again before the vote
> >>>>>
> >>>> closes.
> >>>
> >>>> You may consider my -1 withdrawn if the change is restricted to 2.0
> >>>>>
> >>>>>
> >>>>> On Tue, Nov 25, 2014 at 3:07 PM, Christopher<ct...@apache.org>
> >>>>>
> >>>> wrote:
> >>>
> >>>> On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey<bu...@cloudera.com>
> >>>>>>
> >>>>> wrote:
> >>>>>
> >>>>>> On Tue, Nov 25, 2014 at 2:23 PM, Christopher<ct...@apache.org>
> >>>>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey<busbey@cloudera.com
> >>>>>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> I understand that the use cases enabled by this patch are
> >>>>>>>
> >>>>>> sufficiently
> >>>
> >>>> compelling for you. They are not sufficiently compelling for me,
> >>>>>>>
> >>>>>> hence my
> >>>>>
> >>>>>> veto.
> >>>>>>>
> >>>>>>>
> >>>>>>> I don't know that there is a requirement to make every code
> addition
> >>>>>> sufficiently compelling to every developer, in order to include it.
> If
> >>>>>>
> >>>>> that
> >>>>>
> >>>>>> were the case, I don't think many features would have made it in.
> This
> >>>>>> seems to be an anti-progress position if we allow it to become the
> >>>>>>
> >>>>> norm. It
> >>>>>
> >>>>>> seems to me that there should be compelling reasons to reject a
> >>>>>> contribution that does not break or affect existing functionality.
> >>>>>>
> >>>>>> This VOTE thread is also not the place to get into a discussion of
> >>>>> our
> >>>>> governance model. However, what you are saying is directly opposed to
> >>>>>
> >>>> the
> >>>
> >>>> fundamental way code changes work in Apache projects; it's the
> "Review"
> >>>>> part of Commit Then Review and Review Then Commit. We use the former
> >>>>> because we presume that most changes will be compelling. Because
> every
> >>>>> part
> >>>>> of "compelling" and "cost" is hugely subjective we require that
> vetoes
> >>>>> come
> >>>>> with a rationale.
> >>>>>
> >>>>> It is indeed very anti-progress. That's one of the overheads of being
> >>>>>
> >>>> in a
> >>>
> >>>> community. It's also why I have previously stated that these change
> >>>>>
> >>>> votes
> >>>
> >>>> should be Majority Approval instead of Consensus Approval.
> >>>>>
> >>>>> Also, since you can only veto
> >>>>>> changesets, and not release candidates, I don't see what would stop
> a
> >>>>>> release manager from backporting this changeset to 1.7 prior to its
> >>>>>>
> >>>>> release
> >>>>>
> >>>>>> if we push it to a 2.0 branch. I don't see why this improvement must
> >>>>>>
> >>>>> be
> >>>
> >>>> postponed.
> >>>>>>
> >>>>> The thing that would stop them is that we are a community. It would
> be
> >>>>> incredibly rude for a release manager to do this after the
> restriction
> >>>>>
> >>>> to
> >>>
> >>>> 2.0 was the end compromise reached. We are not in a state of nature
> and
> >>>>> the
> >>>>> bylaws are not our leviathan. We are a group working towards common
> >>>>>
> >>>> goals.
> >>>
> >>>>
> >>>>> --
> >>>>> Sean
> >>>>>
> >>>>>
> >>>>
> >>
> >>
> >>
>
Re: [VOTE] ACCUMULO-3176
Posted by Corey Nolet <cj...@gmail.com>.
+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 <jo...@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, Christopher<ct...@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<ct...@apache.org>
>>> wrote:
>>>
>>> On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey<bu...@cloudera.com>
>>>>
>>> wrote:
>>>
>>>> Responses to a few things below.
>>>>>
>>>>>
>>>>> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss<bf...@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<bu...@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<ct...@apache.org>
>>>>>
>>>> wrote:
>>>
>>>> On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki<
>>>>>>
>>>>> bhavanki@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
>>>> majority vote might be considered to be.
>>>>
>>>>
>>>> That said, I am generally a proponent of not letting "where discussion
>>>>> should happen" get in the way of reaching consensus. However, in this
>>>>>
>>>> case
>>>
>>>> I don't think we have sufficient time to work through the details of
>>>>>
>>>> why I
>>>
>>>> don't find API sprawl a compelling fix for my concerns. I know I
>>>>> definitely
>>>>> don't have the spoons for it.
>>>>>
>>>>> I'm sorry, but if you are unwilling to defend your veto further, I
>>>>> don't
>>>>>
>>>> see how you can expect it to be binding. Please address why this change
>>>> could not be introduced with the compromise proposed.
>>>>
>>>>
>>>> I have offered a reasonable compromise position that addresses both my
>>>>> concerns while adding the feature you want. Please take it.
>>>>>
>>>>> Another reasonable compromise has also been proposed that seems to
>>>>>
>>>> address all of your concerns. Please explain why it does not.
>>>>
>>>> I would also like to add that inclusion of this now would greatly help
>>>> me
>>>> add the wiring necessary for the new API.
>>>>
>>>>
>>>> I don't think I'll have time to be on email again before the vote
>>>>>
>>>> closes.
>>>
>>>> You may consider my -1 withdrawn if the change is restricted to 2.0
>>>>>
>>>>>
>>>>> On Tue, Nov 25, 2014 at 3:07 PM, Christopher<ct...@apache.org>
>>>>>
>>>> wrote:
>>>
>>>> On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey<bu...@cloudera.com>
>>>>>>
>>>>> wrote:
>>>>>
>>>>>> On Tue, Nov 25, 2014 at 2:23 PM, Christopher<ct...@apache.org>
>>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey<busbey@cloudera.com
>>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I understand that the use cases enabled by this patch are
>>>>>>>
>>>>>> sufficiently
>>>
>>>> compelling for you. They are not sufficiently compelling for me,
>>>>>>>
>>>>>> hence my
>>>>>
>>>>>> veto.
>>>>>>>
>>>>>>>
>>>>>>> I don't know that there is a requirement to make every code addition
>>>>>> sufficiently compelling to every developer, in order to include it. If
>>>>>>
>>>>> that
>>>>>
>>>>>> were the case, I don't think many features would have made it in. This
>>>>>> seems to be an anti-progress position if we allow it to become the
>>>>>>
>>>>> norm. It
>>>>>
>>>>>> seems to me that there should be compelling reasons to reject a
>>>>>> contribution that does not break or affect existing functionality.
>>>>>>
>>>>>> This VOTE thread is also not the place to get into a discussion of
>>>>> our
>>>>> governance model. However, what you are saying is directly opposed to
>>>>>
>>>> the
>>>
>>>> fundamental way code changes work in Apache projects; it's the "Review"
>>>>> part of Commit Then Review and Review Then Commit. We use the former
>>>>> because we presume that most changes will be compelling. Because every
>>>>> part
>>>>> of "compelling" and "cost" is hugely subjective we require that vetoes
>>>>> come
>>>>> with a rationale.
>>>>>
>>>>> It is indeed very anti-progress. That's one of the overheads of being
>>>>>
>>>> in a
>>>
>>>> community. It's also why I have previously stated that these change
>>>>>
>>>> votes
>>>
>>>> should be Majority Approval instead of Consensus Approval.
>>>>>
>>>>> Also, since you can only veto
>>>>>> changesets, and not release candidates, I don't see what would stop a
>>>>>> release manager from backporting this changeset to 1.7 prior to its
>>>>>>
>>>>> release
>>>>>
>>>>>> if we push it to a 2.0 branch. I don't see why this improvement must
>>>>>>
>>>>> be
>>>
>>>> postponed.
>>>>>>
>>>>> The thing that would stop them is that we are a community. It would be
>>>>> incredibly rude for a release manager to do this after the restriction
>>>>>
>>>> to
>>>
>>>> 2.0 was the end compromise reached. We are not in a state of nature and
>>>>> the
>>>>> bylaws are not our leviathan. We are a group working towards common
>>>>>
>>>> goals.
>>>
>>>>
>>>>> --
>>>>> Sean
>>>>>
>>>>>
>>>>
>>
>>
>>
Re: [VOTE] ACCUMULO-3176
Posted by Josh Elser <jo...@gmail.com>.
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, Christopher<ct...@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<ct...@apache.org> wrote:
>>
>>> On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey<bu...@cloudera.com>
>> wrote:
>>>> Responses to a few things below.
>>>>
>>>>
>>>> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss<bf...@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<bu...@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<ct...@apache.org>
>> wrote:
>>>>> On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki<
>>>> bhavanki@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
>>> majority vote might be considered to be.
>>>
>>>
>>>> That said, I am generally a proponent of not letting "where discussion
>>>> should happen" get in the way of reaching consensus. However, in this
>> case
>>>> I don't think we have sufficient time to work through the details of
>> why I
>>>> don't find API sprawl a compelling fix for my concerns. I know I
>>>> definitely
>>>> don't have the spoons for it.
>>>>
>>>> I'm sorry, but if you are unwilling to defend your veto further, I don't
>>> see how you can expect it to be binding. Please address why this change
>>> could not be introduced with the compromise proposed.
>>>
>>>
>>>> I have offered a reasonable compromise position that addresses both my
>>>> concerns while adding the feature you want. Please take it.
>>>>
>>>> Another reasonable compromise has also been proposed that seems to
>>> address all of your concerns. Please explain why it does not.
>>>
>>> I would also like to add that inclusion of this now would greatly help me
>>> add the wiring necessary for the new API.
>>>
>>>
>>>> I don't think I'll have time to be on email again before the vote
>> closes.
>>>> You may consider my -1 withdrawn if the change is restricted to 2.0
>>>>
>>>>
>>>> On Tue, Nov 25, 2014 at 3:07 PM, Christopher<ct...@apache.org>
>> wrote:
>>>>> On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey<bu...@cloudera.com>
>>>> wrote:
>>>>>> On Tue, Nov 25, 2014 at 2:23 PM, Christopher<ct...@apache.org>
>>>>> wrote:
>>>>>>> On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey<busbey@cloudera.com
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>> I understand that the use cases enabled by this patch are
>> sufficiently
>>>>>> compelling for you. They are not sufficiently compelling for me,
>>>> hence my
>>>>>> veto.
>>>>>>
>>>>>>
>>>>> I don't know that there is a requirement to make every code addition
>>>>> sufficiently compelling to every developer, in order to include it. If
>>>> that
>>>>> were the case, I don't think many features would have made it in. This
>>>>> seems to be an anti-progress position if we allow it to become the
>>>> norm. It
>>>>> seems to me that there should be compelling reasons to reject a
>>>>> contribution that does not break or affect existing functionality.
>>>>>
>>>> This VOTE thread is also not the place to get into a discussion of our
>>>> governance model. However, what you are saying is directly opposed to
>> the
>>>> fundamental way code changes work in Apache projects; it's the "Review"
>>>> part of Commit Then Review and Review Then Commit. We use the former
>>>> because we presume that most changes will be compelling. Because every
>>>> part
>>>> of "compelling" and "cost" is hugely subjective we require that vetoes
>>>> come
>>>> with a rationale.
>>>>
>>>> It is indeed very anti-progress. That's one of the overheads of being
>> in a
>>>> community. It's also why I have previously stated that these change
>> votes
>>>> should be Majority Approval instead of Consensus Approval.
>>>>
>>>>> Also, since you can only veto
>>>>> changesets, and not release candidates, I don't see what would stop a
>>>>> release manager from backporting this changeset to 1.7 prior to its
>>>> release
>>>>> if we push it to a 2.0 branch. I don't see why this improvement must
>> be
>>>>> postponed.
>>>> The thing that would stop them is that we are a community. It would be
>>>> incredibly rude for a release manager to do this after the restriction
>> to
>>>> 2.0 was the end compromise reached. We are not in a state of nature and
>>>> the
>>>> bylaws are not our leviathan. We are a group working towards common
>> goals.
>>>>
>>>> --
>>>> Sean
>>>>
>>>
>
>
>
Re: [VOTE] ACCUMULO-3176
Posted by Christopher <ct...@apache.org>.
If it helps, I've just initiated a vote for adopting guidelines for API
changes in 1.x versions to deal with the concerns Sean has raised. If we
can agree on a set of guidelines there, perhaps it might help clarify the
right way to move forward on this issue.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Dec 2, 2014 at 2:59 PM, Josh Elser <jo...@gmail.com> wrote:
> Thanks, Dave. I took his remark in the context of the original veto --
> both sides have differing opinions, we have clearly hashed this out now.
>
> I assume that Sean is still willing to work through finding something
> amenable to everyone (as he would be obligated to do as long as he
> considers the changeset veto'ed), but we need to change the discussion
> focus onto what needs to change rather than rehashing the same disagreement
> over again.
>
>
> dlmarion@comcast.net wrote:
>
>> I took Sean's comment (below) to mean the discussion was over. By his
>> comments, I think he intends to stop discussing this sooner rather than
>> later without resolution. I think it's fair to point out that he had an
>> opposite opinion 6 months ago. I wrote it as nicely as possible given my
>> mood about the subject.
>>
>>
>> "While I agree that objections are the start of a conversation, votes are
>> meant to be provide closure so the community can move on to other work.
>> I'd
>> ask that we try to bring this thread to a close."
>>
>>
>>
>>
>> ----- Original Message -----
>>
>> From: "Josh Elser"<jo...@gmail.com>
>> To: dev@accumulo.apache.org
>> Sent: Tuesday, December 2, 2014 2:34:12 PM
>> Subject: Re: [VOTE] ACCUMULO-3176
>>
>> Let's please try to not get snarky here, Dave. We're all trying to have
>> a reasonable discussion, get to the real issues, and figure out how we
>> can work through them without stomping on anyone. As always, you are
>> welcome to fork for you personal reasons -- I don't want to force you
>> down that path, but this is going to take some more time to resolve.
>>
>> Obligatory thank you to Sean for writing up his opinions: it helps us
>> all understand what would be acceptable presently for him to retract his
>> veto in addition to what he sees as the current issues.
>>
>> What I took away from his response: we need to (re)visit what 1.7.0 is
>> really going to be. Rightfully so, we left 1.7 as a intermediate release
>> to let us continue to develop, with the intent to do 2.0.0 as the next
>> fancy thing. Assuming that is still the plan (which has not been
>> otherwise changed), Sean's objection is reasonable. API changes
>> definitely doesn't seem to be in scope for something that was to be a
>> very minor "major" release.
>>
>> That being said, in my opinion, 2.0.0 seems quite a ways off still. I've
>> started considering 1.7.0 to be another "normal" major release, rather
>> than a "minor" one. If we're all in agreement here, I think it would
>> make sense to apply our normal API rules to 1.7.0 and then make sure we
>> minimize churn between 1.7.0 and 2.0.0 for any additions.
>>
>> Sean, is that an acceptable avenue to redirect this discussion? Have I
>> missed any other sticking points? That the above wouldn't address?
>>
>> dlmarion@comcast.net wrote:
>>
>>> The impetus for these changes comes from the discussion in ACCUMULO-118.
>>> This API change and the issues surrounding the per-table Volume Chooser is
>>> a follow-on feature to Multi-Volume support that was added in 1.5. I
>>> want/need these changes.
>>>
>>> In ACCUMULO-2844 you wanted, if not demanded, to make a breaking API
>>> change (changing the name of the Master) in the development and all bug fix
>>> branches without discussion. Here we have a non-breaking API change in a
>>> major release and all of a sudden it's an issue. By that logic, we should
>>> scrub 1.7 for all API changes and revert them.
>>>
>>> At this point I would much rather have these changes committed in 2.0
>>> just so we can stop having this ridiculous discussion. I'm happy to fork
>>> Accumulo and backport these fixes to the version I need.
>>>
>>> ----- Original Message -----
>>>
>>> From: "Sean Busbey"<bu...@cloudera.com>
>>> To: "dev@accumulo apache. org"<de...@accumulo.apache.org>
>>> Sent: Tuesday, December 2, 2014 1:14:50 PM
>>> Subject: Re: [VOTE] ACCUMULO-3176
>>>
>>> Responses below. I feel like most of these questions (with the noted
>>> exception of details on my issue with one of the late compromise
>>> positions)
>>> were previously answered, but I've tried to add additional detail below
>>> where I may have been unclear in prior exchanges.
>>>
>>> While I agree that objections are the start of a conversation, votes are
>>> meant to be provide closure so the community can move on to other work.
>>> I'd
>>> ask that we try to bring this thread to a close.
>>>
>>>
>>> On Mon, Dec 1, 2014 at 2:40 PM, Keith Turner<ke...@deenlo.com> wrote:
>>>
>>> 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.
>>>>
>>>> As a matter of background, over time I have become more convinced of
>>> the
>>> need for a stable, coherent API. Too many of the end users I have seen
>>> endure substantial work because of our altering of the API. This applies
>>> equally for forwards and backwards compatibility. When someone has a
>>> requirement to use our software and they find that the particular version
>>> they need to integrate with is different than they initially expected, I
>>> would like them to not have to endure project delays merely for updating
>>> use of our API.
>>>
>>> For 2.0, we already have broad consensus around improving our API in
>>> ACCUMULO-2589 despite the cost it puts on our user base; both because of
>>> a
>>> better delineation of what is and is not expected to stay constant and
>>> because we'll have a better formulation of a lifecycle for Accumulo
>>> related
>>> resources. In that particular matter, it's the proper lifecycle that I
>>> personally find compelling enough to broadly cause a burden. This is
>>> probably colored by my having dealt with ACCUMULO-2128 and its ilk.
>>>
>>> So, given that we're going to be asking our users to deal with a headache
>>> come 2.0 (which will hopefully be in the next 6-9 months) I would prefer
>>> to
>>> minimize asking them to take on dealing with changes in versions prior to
>>> that. There may be some future issue that fixes something severe enough
>>> to
>>> warrant changing my position on the matter. This issue did not.
>>>
>>> I talked previously about my position on API changes in general in the
>>> background info for Josh’s message:
>>>
>>> http://s.apache.org/HJg
>>>
>>> and I had meant to cover the "we already agreed to break things in 2.0"
>>> side in this admittedly short offer of compromise:
>>>
>>> http://s.apache.org/imf
>>>
>>>
>>>
>>> On Mon, Dec 1, 2014 at 4:25 PM, Christopher<ct...@apache.org> wrote:
>>>
>>> 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?
>>>>
>>>> My general preference, as mentioned above and previously in the
>>> background
>>> info Josh asked for, is to avoid API changes prior to 2.0. I am not
>>> arguing
>>> that this stance be taken on as a matter of course through this
>>> particular
>>> vote.
>>>
>>> I think any change to our API, prior to 2.0 or after, should be carefully
>>> considered. How we plan for users to interact with our software over time
>>> matters. Through removals we will be directly impacting the ability of
>>> operational users to adopt our newer versions. Through additions we will
>>> be
>>> impacting how system integrators go about building applications above us.
>>> It does neither us nor them any good for our API to change merely because
>>> it improves our abstractions or condenses our support footprint.
>>>
>>> In the consideration of the above and the nice-to-have fixes this
>>> particular patch brings, I think it can wait for the API overhaul in 2.0.
>>>
>>> The same two previous mailings I mentioned above to Keith are where I
>>> went
>>> through this previously.
>>>
>>>
>>>
>>> -> Please address the fact that there is no breakage here...
>>>>
>>> -> Another reasonable compromise has also been proposed that seems to
>>>
>>> address all of your concerns. Please explain why it does not.
>>>
>>>
>>> I think these are the same question, presuming your "other compromise" is
>>> the one of adding the new API and leaving the extant create methods
>>> undeprecated. If not, please let me know what other compromise I missed
>>> so
>>> that I can respond accordingly.
>>>
>>> I covered the breakage part of this explicitly in my response to Keith's
>>> question about which part of the API move I was concerned with:
>>>
>>> http://s.apache.org/nn5
>>>
>>> Essentially, moving our table creation API to use a configuration object
>>> instead of the myriad of different arguments is a shift in how we expect
>>> users to interact with Accumulo. Even if the breakage doesn't happen
>>> right
>>> now, this change is setting downstream users up for pain when the break
>>> happens. To that same end, users attempting to proactively stay up to
>>> date
>>> on our API will break if they have to move backwards. Yes, this a normal
>>> part of API evolution. Yes, users will have to do this at some point. I'm
>>> merely stating that we have already reached consensus on that point being
>>> 2.0 and we should reserve using up the good will of our end users.
>>>
>>> Similarly, simply expanding our API to have multiple long term ways of
>>> doing table creation isn't tenable. For one, downstream users will ask
>>> which method to use. Deprecation is how we normally offer them clear
>>> guidance on where the API is going in the future. Without that, we'll
>>> just
>>> be using some proxy for deprecation (either a javadoc or emails on user@
>>> ).
>>> Additionally, since the version that takes a single configuration object
>>> is
>>> clearly the most sustainable approach, the other methods are likely to be
>>> deprecated and then removed should we end up with additional major
>>> versions
>>> prior to 2.0.
>>>
>>> I covered some of this concern in my response to Brian in the first part
>>> of
>>> my last response:
>>>
>>> http://s.apache.org/0um
>>>
>>>
>>>
>>> -> 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).
>>>>
>>>
>>> I believe I covered this through a combination of the above explanations
>>> to
>>> Keith and my response to Brian in the first part of my last response:
>>>
>>> http://s.apache.org/0um
>>>
>>> That we are having a 1.7 release at all is a matter of scheduling. There
>>> are already too many things different in that development line for us to
>>> release it as a follow on to 1.6 but not enough of our goals for 2.0 are
>>> done to get that release out. That doesn't mean we should feel free to
>>> pack
>>> as many breaking changes as we want into the release.
>>>
>>>
>>>
>>> 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?
>>>>
>>>>
>>> I think this is covered above. In summary, when we alter our API we need
>>> to
>>> consider long term impact rather than just the immediate release. We are
>>> already going to ask our users to handle major changes in a relatively
>>> short time period.
>>>
>>>
>>>
>>> -> 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?
>>>>
>>>>
>>> I believe the rest of this message restates in detail my concerns about
>>> our
>>> API evolution and specifically why I am on board with the planned
>>> breakage
>>> in the 2.0 release. Let me know where there are particular gaps so I can
>>> help clarify.
>>>
>>> Please everyone stop this divisive tactic of continuing to claim my veto
>>> is
>>> invalid. The surface of our API and our impact on downstream users are
>>> valid technical considerations. Our bylaws clearly state what is needed
>>> for
>>> a veto to be sustained and I have already passed that bar. Let’s focus
>>> our
>>> discussion on the underlying problem rather than technicalities of our
>>> governance.
>>>
>>>
>>
>>
Re: [VOTE] ACCUMULO-3176
Posted by Josh Elser <jo...@gmail.com>.
Thanks, Dave. I took his remark in the context of the original veto --
both sides have differing opinions, we have clearly hashed this out now.
I assume that Sean is still willing to work through finding something
amenable to everyone (as he would be obligated to do as long as he
considers the changeset veto'ed), but we need to change the discussion
focus onto what needs to change rather than rehashing the same
disagreement over again.
dlmarion@comcast.net wrote:
> I took Sean's comment (below) to mean the discussion was over. By his comments, I think he intends to stop discussing this sooner rather than later without resolution. I think it's fair to point out that he had an opposite opinion 6 months ago. I wrote it as nicely as possible given my mood about the subject.
>
>
> "While I agree that objections are the start of a conversation, votes are
> meant to be provide closure so the community can move on to other work. I'd
> ask that we try to bring this thread to a close."
>
>
>
>
> ----- Original Message -----
>
> From: "Josh Elser"<jo...@gmail.com>
> To: dev@accumulo.apache.org
> Sent: Tuesday, December 2, 2014 2:34:12 PM
> Subject: Re: [VOTE] ACCUMULO-3176
>
> Let's please try to not get snarky here, Dave. We're all trying to have
> a reasonable discussion, get to the real issues, and figure out how we
> can work through them without stomping on anyone. As always, you are
> welcome to fork for you personal reasons -- I don't want to force you
> down that path, but this is going to take some more time to resolve.
>
> Obligatory thank you to Sean for writing up his opinions: it helps us
> all understand what would be acceptable presently for him to retract his
> veto in addition to what he sees as the current issues.
>
> What I took away from his response: we need to (re)visit what 1.7.0 is
> really going to be. Rightfully so, we left 1.7 as a intermediate release
> to let us continue to develop, with the intent to do 2.0.0 as the next
> fancy thing. Assuming that is still the plan (which has not been
> otherwise changed), Sean's objection is reasonable. API changes
> definitely doesn't seem to be in scope for something that was to be a
> very minor "major" release.
>
> That being said, in my opinion, 2.0.0 seems quite a ways off still. I've
> started considering 1.7.0 to be another "normal" major release, rather
> than a "minor" one. If we're all in agreement here, I think it would
> make sense to apply our normal API rules to 1.7.0 and then make sure we
> minimize churn between 1.7.0 and 2.0.0 for any additions.
>
> Sean, is that an acceptable avenue to redirect this discussion? Have I
> missed any other sticking points? That the above wouldn't address?
>
> dlmarion@comcast.net wrote:
>> The impetus for these changes comes from the discussion in ACCUMULO-118. This API change and the issues surrounding the per-table Volume Chooser is a follow-on feature to Multi-Volume support that was added in 1.5. I want/need these changes.
>>
>> In ACCUMULO-2844 you wanted, if not demanded, to make a breaking API change (changing the name of the Master) in the development and all bug fix branches without discussion. Here we have a non-breaking API change in a major release and all of a sudden it's an issue. By that logic, we should scrub 1.7 for all API changes and revert them.
>>
>> At this point I would much rather have these changes committed in 2.0 just so we can stop having this ridiculous discussion. I'm happy to fork Accumulo and backport these fixes to the version I need.
>>
>> ----- Original Message -----
>>
>> From: "Sean Busbey"<bu...@cloudera.com>
>> To: "dev@accumulo apache. org"<de...@accumulo.apache.org>
>> Sent: Tuesday, December 2, 2014 1:14:50 PM
>> Subject: Re: [VOTE] ACCUMULO-3176
>>
>> Responses below. I feel like most of these questions (with the noted
>> exception of details on my issue with one of the late compromise positions)
>> were previously answered, but I've tried to add additional detail below
>> where I may have been unclear in prior exchanges.
>>
>> While I agree that objections are the start of a conversation, votes are
>> meant to be provide closure so the community can move on to other work. I'd
>> ask that we try to bring this thread to a close.
>>
>>
>> On Mon, Dec 1, 2014 at 2:40 PM, Keith Turner<ke...@deenlo.com> wrote:
>>
>>> 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.
>>>
>> As a matter of background, over time I have become more convinced of the
>> need for a stable, coherent API. Too many of the end users I have seen
>> endure substantial work because of our altering of the API. This applies
>> equally for forwards and backwards compatibility. When someone has a
>> requirement to use our software and they find that the particular version
>> they need to integrate with is different than they initially expected, I
>> would like them to not have to endure project delays merely for updating
>> use of our API.
>>
>> For 2.0, we already have broad consensus around improving our API in
>> ACCUMULO-2589 despite the cost it puts on our user base; both because of a
>> better delineation of what is and is not expected to stay constant and
>> because we'll have a better formulation of a lifecycle for Accumulo related
>> resources. In that particular matter, it's the proper lifecycle that I
>> personally find compelling enough to broadly cause a burden. This is
>> probably colored by my having dealt with ACCUMULO-2128 and its ilk.
>>
>> So, given that we're going to be asking our users to deal with a headache
>> come 2.0 (which will hopefully be in the next 6-9 months) I would prefer to
>> minimize asking them to take on dealing with changes in versions prior to
>> that. There may be some future issue that fixes something severe enough to
>> warrant changing my position on the matter. This issue did not.
>>
>> I talked previously about my position on API changes in general in the
>> background info for Josh’s message:
>>
>> http://s.apache.org/HJg
>>
>> and I had meant to cover the "we already agreed to break things in 2.0"
>> side in this admittedly short offer of compromise:
>>
>> http://s.apache.org/imf
>>
>>
>>
>> On Mon, Dec 1, 2014 at 4:25 PM, Christopher<ct...@apache.org> wrote:
>>
>>> 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?
>>>
>> My general preference, as mentioned above and previously in the background
>> info Josh asked for, is to avoid API changes prior to 2.0. I am not arguing
>> that this stance be taken on as a matter of course through this particular
>> vote.
>>
>> I think any change to our API, prior to 2.0 or after, should be carefully
>> considered. How we plan for users to interact with our software over time
>> matters. Through removals we will be directly impacting the ability of
>> operational users to adopt our newer versions. Through additions we will be
>> impacting how system integrators go about building applications above us.
>> It does neither us nor them any good for our API to change merely because
>> it improves our abstractions or condenses our support footprint.
>>
>> In the consideration of the above and the nice-to-have fixes this
>> particular patch brings, I think it can wait for the API overhaul in 2.0.
>>
>> The same two previous mailings I mentioned above to Keith are where I went
>> through this previously.
>>
>>
>>
>>> -> Please address the fact that there is no breakage here...
>> -> Another reasonable compromise has also been proposed that seems to
>>
>> address all of your concerns. Please explain why it does not.
>>
>>
>> I think these are the same question, presuming your "other compromise" is
>> the one of adding the new API and leaving the extant create methods
>> undeprecated. If not, please let me know what other compromise I missed so
>> that I can respond accordingly.
>>
>> I covered the breakage part of this explicitly in my response to Keith's
>> question about which part of the API move I was concerned with:
>>
>> http://s.apache.org/nn5
>>
>> Essentially, moving our table creation API to use a configuration object
>> instead of the myriad of different arguments is a shift in how we expect
>> users to interact with Accumulo. Even if the breakage doesn't happen right
>> now, this change is setting downstream users up for pain when the break
>> happens. To that same end, users attempting to proactively stay up to date
>> on our API will break if they have to move backwards. Yes, this a normal
>> part of API evolution. Yes, users will have to do this at some point. I'm
>> merely stating that we have already reached consensus on that point being
>> 2.0 and we should reserve using up the good will of our end users.
>>
>> Similarly, simply expanding our API to have multiple long term ways of
>> doing table creation isn't tenable. For one, downstream users will ask
>> which method to use. Deprecation is how we normally offer them clear
>> guidance on where the API is going in the future. Without that, we'll just
>> be using some proxy for deprecation (either a javadoc or emails on user@).
>> Additionally, since the version that takes a single configuration object is
>> clearly the most sustainable approach, the other methods are likely to be
>> deprecated and then removed should we end up with additional major versions
>> prior to 2.0.
>>
>> I covered some of this concern in my response to Brian in the first part of
>> my last response:
>>
>> http://s.apache.org/0um
>>
>>
>>
>>> -> 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).
>>
>> I believe I covered this through a combination of the above explanations to
>> Keith and my response to Brian in the first part of my last response:
>>
>> http://s.apache.org/0um
>>
>> That we are having a 1.7 release at all is a matter of scheduling. There
>> are already too many things different in that development line for us to
>> release it as a follow on to 1.6 but not enough of our goals for 2.0 are
>> done to get that release out. That doesn't mean we should feel free to pack
>> as many breaking changes as we want into the release.
>>
>>
>>
>>> 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?
>>>
>>
>> I think this is covered above. In summary, when we alter our API we need to
>> consider long term impact rather than just the immediate release. We are
>> already going to ask our users to handle major changes in a relatively
>> short time period.
>>
>>
>>
>>> -> 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?
>>>
>>
>> I believe the rest of this message restates in detail my concerns about our
>> API evolution and specifically why I am on board with the planned breakage
>> in the 2.0 release. Let me know where there are particular gaps so I can
>> help clarify.
>>
>> Please everyone stop this divisive tactic of continuing to claim my veto is
>> invalid. The surface of our API and our impact on downstream users are
>> valid technical considerations. Our bylaws clearly state what is needed for
>> a veto to be sustained and I have already passed that bar. Let’s focus our
>> discussion on the underlying problem rather than technicalities of our
>> governance.
>>
>
>
Re: [VOTE] ACCUMULO-3176
Posted by dl...@comcast.net.
I took Sean's comment (below) to mean the discussion was over. By his comments, I think he intends to stop discussing this sooner rather than later without resolution. I think it's fair to point out that he had an opposite opinion 6 months ago. I wrote it as nicely as possible given my mood about the subject.
"While I agree that objections are the start of a conversation, votes are
meant to be provide closure so the community can move on to other work. I'd
ask that we try to bring this thread to a close."
----- Original Message -----
From: "Josh Elser" <jo...@gmail.com>
To: dev@accumulo.apache.org
Sent: Tuesday, December 2, 2014 2:34:12 PM
Subject: Re: [VOTE] ACCUMULO-3176
Let's please try to not get snarky here, Dave. We're all trying to have
a reasonable discussion, get to the real issues, and figure out how we
can work through them without stomping on anyone. As always, you are
welcome to fork for you personal reasons -- I don't want to force you
down that path, but this is going to take some more time to resolve.
Obligatory thank you to Sean for writing up his opinions: it helps us
all understand what would be acceptable presently for him to retract his
veto in addition to what he sees as the current issues.
What I took away from his response: we need to (re)visit what 1.7.0 is
really going to be. Rightfully so, we left 1.7 as a intermediate release
to let us continue to develop, with the intent to do 2.0.0 as the next
fancy thing. Assuming that is still the plan (which has not been
otherwise changed), Sean's objection is reasonable. API changes
definitely doesn't seem to be in scope for something that was to be a
very minor "major" release.
That being said, in my opinion, 2.0.0 seems quite a ways off still. I've
started considering 1.7.0 to be another "normal" major release, rather
than a "minor" one. If we're all in agreement here, I think it would
make sense to apply our normal API rules to 1.7.0 and then make sure we
minimize churn between 1.7.0 and 2.0.0 for any additions.
Sean, is that an acceptable avenue to redirect this discussion? Have I
missed any other sticking points? That the above wouldn't address?
dlmarion@comcast.net wrote:
> The impetus for these changes comes from the discussion in ACCUMULO-118. This API change and the issues surrounding the per-table Volume Chooser is a follow-on feature to Multi-Volume support that was added in 1.5. I want/need these changes.
>
> In ACCUMULO-2844 you wanted, if not demanded, to make a breaking API change (changing the name of the Master) in the development and all bug fix branches without discussion. Here we have a non-breaking API change in a major release and all of a sudden it's an issue. By that logic, we should scrub 1.7 for all API changes and revert them.
>
> At this point I would much rather have these changes committed in 2.0 just so we can stop having this ridiculous discussion. I'm happy to fork Accumulo and backport these fixes to the version I need.
>
> ----- Original Message -----
>
> From: "Sean Busbey"<bu...@cloudera.com>
> To: "dev@accumulo apache. org"<de...@accumulo.apache.org>
> Sent: Tuesday, December 2, 2014 1:14:50 PM
> Subject: Re: [VOTE] ACCUMULO-3176
>
> Responses below. I feel like most of these questions (with the noted
> exception of details on my issue with one of the late compromise positions)
> were previously answered, but I've tried to add additional detail below
> where I may have been unclear in prior exchanges.
>
> While I agree that objections are the start of a conversation, votes are
> meant to be provide closure so the community can move on to other work. I'd
> ask that we try to bring this thread to a close.
>
>
> On Mon, Dec 1, 2014 at 2:40 PM, Keith Turner<ke...@deenlo.com> wrote:
>
>>
>> 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.
>>
>
> As a matter of background, over time I have become more convinced of the
> need for a stable, coherent API. Too many of the end users I have seen
> endure substantial work because of our altering of the API. This applies
> equally for forwards and backwards compatibility. When someone has a
> requirement to use our software and they find that the particular version
> they need to integrate with is different than they initially expected, I
> would like them to not have to endure project delays merely for updating
> use of our API.
>
> For 2.0, we already have broad consensus around improving our API in
> ACCUMULO-2589 despite the cost it puts on our user base; both because of a
> better delineation of what is and is not expected to stay constant and
> because we'll have a better formulation of a lifecycle for Accumulo related
> resources. In that particular matter, it's the proper lifecycle that I
> personally find compelling enough to broadly cause a burden. This is
> probably colored by my having dealt with ACCUMULO-2128 and its ilk.
>
> So, given that we're going to be asking our users to deal with a headache
> come 2.0 (which will hopefully be in the next 6-9 months) I would prefer to
> minimize asking them to take on dealing with changes in versions prior to
> that. There may be some future issue that fixes something severe enough to
> warrant changing my position on the matter. This issue did not.
>
> I talked previously about my position on API changes in general in the
> background info for Josh’s message:
>
> http://s.apache.org/HJg
>
> and I had meant to cover the "we already agreed to break things in 2.0"
> side in this admittedly short offer of compromise:
>
> http://s.apache.org/imf
>
>
>
> On Mon, Dec 1, 2014 at 4:25 PM, Christopher<ct...@apache.org> wrote:
>
>> 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?
>>
>
> My general preference, as mentioned above and previously in the background
> info Josh asked for, is to avoid API changes prior to 2.0. I am not arguing
> that this stance be taken on as a matter of course through this particular
> vote.
>
> I think any change to our API, prior to 2.0 or after, should be carefully
> considered. How we plan for users to interact with our software over time
> matters. Through removals we will be directly impacting the ability of
> operational users to adopt our newer versions. Through additions we will be
> impacting how system integrators go about building applications above us.
> It does neither us nor them any good for our API to change merely because
> it improves our abstractions or condenses our support footprint.
>
> In the consideration of the above and the nice-to-have fixes this
> particular patch brings, I think it can wait for the API overhaul in 2.0.
>
> The same two previous mailings I mentioned above to Keith are where I went
> through this previously.
>
>
>
>> -> Please address the fact that there is no breakage here...
>
> -> Another reasonable compromise has also been proposed that seems to
>
> address all of your concerns. Please explain why it does not.
>
>
> I think these are the same question, presuming your "other compromise" is
> the one of adding the new API and leaving the extant create methods
> undeprecated. If not, please let me know what other compromise I missed so
> that I can respond accordingly.
>
> I covered the breakage part of this explicitly in my response to Keith's
> question about which part of the API move I was concerned with:
>
> http://s.apache.org/nn5
>
> Essentially, moving our table creation API to use a configuration object
> instead of the myriad of different arguments is a shift in how we expect
> users to interact with Accumulo. Even if the breakage doesn't happen right
> now, this change is setting downstream users up for pain when the break
> happens. To that same end, users attempting to proactively stay up to date
> on our API will break if they have to move backwards. Yes, this a normal
> part of API evolution. Yes, users will have to do this at some point. I'm
> merely stating that we have already reached consensus on that point being
> 2.0 and we should reserve using up the good will of our end users.
>
> Similarly, simply expanding our API to have multiple long term ways of
> doing table creation isn't tenable. For one, downstream users will ask
> which method to use. Deprecation is how we normally offer them clear
> guidance on where the API is going in the future. Without that, we'll just
> be using some proxy for deprecation (either a javadoc or emails on user@).
> Additionally, since the version that takes a single configuration object is
> clearly the most sustainable approach, the other methods are likely to be
> deprecated and then removed should we end up with additional major versions
> prior to 2.0.
>
> I covered some of this concern in my response to Brian in the first part of
> my last response:
>
> http://s.apache.org/0um
>
>
>
>> -> 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).
>
>
> I believe I covered this through a combination of the above explanations to
> Keith and my response to Brian in the first part of my last response:
>
> http://s.apache.org/0um
>
> That we are having a 1.7 release at all is a matter of scheduling. There
> are already too many things different in that development line for us to
> release it as a follow on to 1.6 but not enough of our goals for 2.0 are
> done to get that release out. That doesn't mean we should feel free to pack
> as many breaking changes as we want into the release.
>
>
>
>> 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?
>>
>
>
> I think this is covered above. In summary, when we alter our API we need to
> consider long term impact rather than just the immediate release. We are
> already going to ask our users to handle major changes in a relatively
> short time period.
>
>
>
>> -> 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?
>>
>
>
> I believe the rest of this message restates in detail my concerns about our
> API evolution and specifically why I am on board with the planned breakage
> in the 2.0 release. Let me know where there are particular gaps so I can
> help clarify.
>
> Please everyone stop this divisive tactic of continuing to claim my veto is
> invalid. The surface of our API and our impact on downstream users are
> valid technical considerations. Our bylaws clearly state what is needed for
> a veto to be sustained and I have already passed that bar. Let’s focus our
> discussion on the underlying problem rather than technicalities of our
> governance.
>
Re: [VOTE] ACCUMULO-3176
Posted by Christopher <ct...@apache.org>.
On Sat, Dec 13, 2014 at 9:45 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> On Sat, Dec 13, 2014 at 1:33 PM, Christopher <ct...@apache.org> wrote:
>
> > Sean-
> >
> > Are all your concerns about API stability addressed now that we have
> > established semver for our versioning standards?
> >
>
> Sure.
>
>
>
> > Do you have any remaining concerns (unrelated to API) about adding the
> > create table method to the master branch?
> > Are there any specific modifications to the patch you'd prefer seen
> before
> > you'd be okay with adding the desired functionality for initial table
> > properties to the master branch?
> >
> >
> Nope.
>
>
>
Excellent.
I'm not afraid to admit that this was a somewhat painful process, but I
think that, ultimately, good things came out of it; for instance, it forced
us to make a decision about versioning and API stability, which is a
conversation we'd been procrastinating on, as a community. Hopefully, there
will be other benefits, as well (lessons learned in dispute resolution,
general communication, or compromise, perhaps?). At the very least, it is
my sincere hope that neither the length of this conversation, nor the
painful process, has done any irreparable harm to the community and that
we'll grow from it as we put it behind us.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
Re: [VOTE] ACCUMULO-3176
Posted by Sean Busbey <bu...@cloudera.com>.
On Sat, Dec 13, 2014 at 1:33 PM, Christopher <ct...@apache.org> wrote:
> Sean-
>
> Are all your concerns about API stability addressed now that we have
> established semver for our versioning standards?
>
Sure.
> Do you have any remaining concerns (unrelated to API) about adding the
> create table method to the master branch?
> Are there any specific modifications to the patch you'd prefer seen before
> you'd be okay with adding the desired functionality for initial table
> properties to the master branch?
>
>
Nope.
--
Sean
Re: [VOTE] ACCUMULO-3176
Posted by Christopher <ct...@apache.org>.
Sean-
Are all your concerns about API stability addressed now that we have
established semver for our versioning standards?
Do you have any remaining concerns (unrelated to API) about adding the
create table method to the master branch?
Are there any specific modifications to the patch you'd prefer seen before
you'd be okay with adding the desired functionality for initial table
properties to the master branch?
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
Re: [VOTE] ACCUMULO-3176
Posted by Josh Elser <jo...@gmail.com>.
On Dec 3, 2014 9:32 AM, "Sean Busbey" <bu...@cloudera.com> wrote:
>
> On Tue, Dec 2, 2014 at 1:34 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > Let's please try to not get snarky here, Dave. We're all trying to have
a
> > reasonable discussion, get to the real issues, and figure out how we can
> > work through them without stomping on anyone. As always, you are
welcome to
> > fork for you personal reasons -- I don't want to force you down that
path,
> > but this is going to take some more time to resolve.
> >
> > Obligatory thank you to Sean for writing up his opinions: it helps us
all
> > understand what would be acceptable presently for him to retract his
veto
> > in addition to what he sees as the current issues.
> >
> > What I took away from his response: we need to (re)visit what 1.7.0 is
> > really going to be. Rightfully so, we left 1.7 as a intermediate
release to
> > let us continue to develop, with the intent to do 2.0.0 as the next
fancy
> > thing. Assuming that is still the plan (which has not been otherwise
> > changed), Sean's objection is reasonable. API changes definitely doesn't
> > seem to be in scope for something that was to be a very minor "major"
> > release.
> >
> > That being said, in my opinion, 2.0.0 seems quite a ways off still. I've
> > started considering 1.7.0 to be another "normal" major release, rather
than
> > a "minor" one. If we're all in agreement here, I think it would make
sense
> > to apply our normal API rules to 1.7.0 and then make sure we minimize
churn
> > between 1.7.0 and 2.0.0 for any additions.
> >
> > Sean, is that an acceptable avenue to redirect this discussion? Have I
> > missed any other sticking points? That the above wouldn't address?
> >
> >
>
> Yes, that's reasonable.
Great. Thanks.
Re: [VOTE] ACCUMULO-3176
Posted by Sean Busbey <bu...@cloudera.com>.
On Tue, Dec 2, 2014 at 1:34 PM, Josh Elser <jo...@gmail.com> wrote:
> Let's please try to not get snarky here, Dave. We're all trying to have a
> reasonable discussion, get to the real issues, and figure out how we can
> work through them without stomping on anyone. As always, you are welcome to
> fork for you personal reasons -- I don't want to force you down that path,
> but this is going to take some more time to resolve.
>
> Obligatory thank you to Sean for writing up his opinions: it helps us all
> understand what would be acceptable presently for him to retract his veto
> in addition to what he sees as the current issues.
>
> What I took away from his response: we need to (re)visit what 1.7.0 is
> really going to be. Rightfully so, we left 1.7 as a intermediate release to
> let us continue to develop, with the intent to do 2.0.0 as the next fancy
> thing. Assuming that is still the plan (which has not been otherwise
> changed), Sean's objection is reasonable. API changes definitely doesn't
> seem to be in scope for something that was to be a very minor "major"
> release.
>
> That being said, in my opinion, 2.0.0 seems quite a ways off still. I've
> started considering 1.7.0 to be another "normal" major release, rather than
> a "minor" one. If we're all in agreement here, I think it would make sense
> to apply our normal API rules to 1.7.0 and then make sure we minimize churn
> between 1.7.0 and 2.0.0 for any additions.
>
> Sean, is that an acceptable avenue to redirect this discussion? Have I
> missed any other sticking points? That the above wouldn't address?
>
>
Yes, that's reasonable.
--
Sean
Re: [VOTE] ACCUMULO-3176
Posted by Josh Elser <jo...@gmail.com>.
Let's please try to not get snarky here, Dave. We're all trying to have
a reasonable discussion, get to the real issues, and figure out how we
can work through them without stomping on anyone. As always, you are
welcome to fork for you personal reasons -- I don't want to force you
down that path, but this is going to take some more time to resolve.
Obligatory thank you to Sean for writing up his opinions: it helps us
all understand what would be acceptable presently for him to retract his
veto in addition to what he sees as the current issues.
What I took away from his response: we need to (re)visit what 1.7.0 is
really going to be. Rightfully so, we left 1.7 as a intermediate release
to let us continue to develop, with the intent to do 2.0.0 as the next
fancy thing. Assuming that is still the plan (which has not been
otherwise changed), Sean's objection is reasonable. API changes
definitely doesn't seem to be in scope for something that was to be a
very minor "major" release.
That being said, in my opinion, 2.0.0 seems quite a ways off still. I've
started considering 1.7.0 to be another "normal" major release, rather
than a "minor" one. If we're all in agreement here, I think it would
make sense to apply our normal API rules to 1.7.0 and then make sure we
minimize churn between 1.7.0 and 2.0.0 for any additions.
Sean, is that an acceptable avenue to redirect this discussion? Have I
missed any other sticking points? That the above wouldn't address?
dlmarion@comcast.net wrote:
> The impetus for these changes comes from the discussion in ACCUMULO-118. This API change and the issues surrounding the per-table Volume Chooser is a follow-on feature to Multi-Volume support that was added in 1.5. I want/need these changes.
>
> In ACCUMULO-2844 you wanted, if not demanded, to make a breaking API change (changing the name of the Master) in the development and all bug fix branches without discussion. Here we have a non-breaking API change in a major release and all of a sudden it's an issue. By that logic, we should scrub 1.7 for all API changes and revert them.
>
> At this point I would much rather have these changes committed in 2.0 just so we can stop having this ridiculous discussion. I'm happy to fork Accumulo and backport these fixes to the version I need.
>
> ----- Original Message -----
>
> From: "Sean Busbey"<bu...@cloudera.com>
> To: "dev@accumulo apache. org"<de...@accumulo.apache.org>
> Sent: Tuesday, December 2, 2014 1:14:50 PM
> Subject: Re: [VOTE] ACCUMULO-3176
>
> Responses below. I feel like most of these questions (with the noted
> exception of details on my issue with one of the late compromise positions)
> were previously answered, but I've tried to add additional detail below
> where I may have been unclear in prior exchanges.
>
> While I agree that objections are the start of a conversation, votes are
> meant to be provide closure so the community can move on to other work. I'd
> ask that we try to bring this thread to a close.
>
>
> On Mon, Dec 1, 2014 at 2:40 PM, Keith Turner<ke...@deenlo.com> wrote:
>
>>
>> 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.
>>
>
> As a matter of background, over time I have become more convinced of the
> need for a stable, coherent API. Too many of the end users I have seen
> endure substantial work because of our altering of the API. This applies
> equally for forwards and backwards compatibility. When someone has a
> requirement to use our software and they find that the particular version
> they need to integrate with is different than they initially expected, I
> would like them to not have to endure project delays merely for updating
> use of our API.
>
> For 2.0, we already have broad consensus around improving our API in
> ACCUMULO-2589 despite the cost it puts on our user base; both because of a
> better delineation of what is and is not expected to stay constant and
> because we'll have a better formulation of a lifecycle for Accumulo related
> resources. In that particular matter, it's the proper lifecycle that I
> personally find compelling enough to broadly cause a burden. This is
> probably colored by my having dealt with ACCUMULO-2128 and its ilk.
>
> So, given that we're going to be asking our users to deal with a headache
> come 2.0 (which will hopefully be in the next 6-9 months) I would prefer to
> minimize asking them to take on dealing with changes in versions prior to
> that. There may be some future issue that fixes something severe enough to
> warrant changing my position on the matter. This issue did not.
>
> I talked previously about my position on API changes in general in the
> background info for Josh’s message:
>
> http://s.apache.org/HJg
>
> and I had meant to cover the "we already agreed to break things in 2.0"
> side in this admittedly short offer of compromise:
>
> http://s.apache.org/imf
>
>
>
> On Mon, Dec 1, 2014 at 4:25 PM, Christopher<ct...@apache.org> wrote:
>
>> 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?
>>
>
> My general preference, as mentioned above and previously in the background
> info Josh asked for, is to avoid API changes prior to 2.0. I am not arguing
> that this stance be taken on as a matter of course through this particular
> vote.
>
> I think any change to our API, prior to 2.0 or after, should be carefully
> considered. How we plan for users to interact with our software over time
> matters. Through removals we will be directly impacting the ability of
> operational users to adopt our newer versions. Through additions we will be
> impacting how system integrators go about building applications above us.
> It does neither us nor them any good for our API to change merely because
> it improves our abstractions or condenses our support footprint.
>
> In the consideration of the above and the nice-to-have fixes this
> particular patch brings, I think it can wait for the API overhaul in 2.0.
>
> The same two previous mailings I mentioned above to Keith are where I went
> through this previously.
>
>
>
>> -> Please address the fact that there is no breakage here...
>
> -> Another reasonable compromise has also been proposed that seems to
>
> address all of your concerns. Please explain why it does not.
>
>
> I think these are the same question, presuming your "other compromise" is
> the one of adding the new API and leaving the extant create methods
> undeprecated. If not, please let me know what other compromise I missed so
> that I can respond accordingly.
>
> I covered the breakage part of this explicitly in my response to Keith's
> question about which part of the API move I was concerned with:
>
> http://s.apache.org/nn5
>
> Essentially, moving our table creation API to use a configuration object
> instead of the myriad of different arguments is a shift in how we expect
> users to interact with Accumulo. Even if the breakage doesn't happen right
> now, this change is setting downstream users up for pain when the break
> happens. To that same end, users attempting to proactively stay up to date
> on our API will break if they have to move backwards. Yes, this a normal
> part of API evolution. Yes, users will have to do this at some point. I'm
> merely stating that we have already reached consensus on that point being
> 2.0 and we should reserve using up the good will of our end users.
>
> Similarly, simply expanding our API to have multiple long term ways of
> doing table creation isn't tenable. For one, downstream users will ask
> which method to use. Deprecation is how we normally offer them clear
> guidance on where the API is going in the future. Without that, we'll just
> be using some proxy for deprecation (either a javadoc or emails on user@).
> Additionally, since the version that takes a single configuration object is
> clearly the most sustainable approach, the other methods are likely to be
> deprecated and then removed should we end up with additional major versions
> prior to 2.0.
>
> I covered some of this concern in my response to Brian in the first part of
> my last response:
>
> http://s.apache.org/0um
>
>
>
>> -> 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).
>
>
> I believe I covered this through a combination of the above explanations to
> Keith and my response to Brian in the first part of my last response:
>
> http://s.apache.org/0um
>
> That we are having a 1.7 release at all is a matter of scheduling. There
> are already too many things different in that development line for us to
> release it as a follow on to 1.6 but not enough of our goals for 2.0 are
> done to get that release out. That doesn't mean we should feel free to pack
> as many breaking changes as we want into the release.
>
>
>
>> 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?
>>
>
>
> I think this is covered above. In summary, when we alter our API we need to
> consider long term impact rather than just the immediate release. We are
> already going to ask our users to handle major changes in a relatively
> short time period.
>
>
>
>> -> 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?
>>
>
>
> I believe the rest of this message restates in detail my concerns about our
> API evolution and specifically why I am on board with the planned breakage
> in the 2.0 release. Let me know where there are particular gaps so I can
> help clarify.
>
> Please everyone stop this divisive tactic of continuing to claim my veto is
> invalid. The surface of our API and our impact on downstream users are
> valid technical considerations. Our bylaws clearly state what is needed for
> a veto to be sustained and I have already passed that bar. Let’s focus our
> discussion on the underlying problem rather than technicalities of our
> governance.
>
Re: [VOTE] ACCUMULO-3176
Posted by dl...@comcast.net.
The impetus for these changes comes from the discussion in ACCUMULO-118. This API change and the issues surrounding the per-table Volume Chooser is a follow-on feature to Multi-Volume support that was added in 1.5. I want/need these changes.
In ACCUMULO-2844 you wanted, if not demanded, to make a breaking API change (changing the name of the Master) in the development and all bug fix branches without discussion. Here we have a non-breaking API change in a major release and all of a sudden it's an issue. By that logic, we should scrub 1.7 for all API changes and revert them.
At this point I would much rather have these changes committed in 2.0 just so we can stop having this ridiculous discussion. I'm happy to fork Accumulo and backport these fixes to the version I need.
----- Original Message -----
From: "Sean Busbey" <bu...@cloudera.com>
To: "dev@accumulo apache. org" <de...@accumulo.apache.org>
Sent: Tuesday, December 2, 2014 1:14:50 PM
Subject: Re: [VOTE] ACCUMULO-3176
Responses below. I feel like most of these questions (with the noted
exception of details on my issue with one of the late compromise positions)
were previously answered, but I've tried to add additional detail below
where I may have been unclear in prior exchanges.
While I agree that objections are the start of a conversation, votes are
meant to be provide closure so the community can move on to other work. I'd
ask that we try to bring this thread to a close.
On Mon, Dec 1, 2014 at 2:40 PM, Keith Turner <ke...@deenlo.com> wrote:
>
>
> 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.
>
As a matter of background, over time I have become more convinced of the
need for a stable, coherent API. Too many of the end users I have seen
endure substantial work because of our altering of the API. This applies
equally for forwards and backwards compatibility. When someone has a
requirement to use our software and they find that the particular version
they need to integrate with is different than they initially expected, I
would like them to not have to endure project delays merely for updating
use of our API.
For 2.0, we already have broad consensus around improving our API in
ACCUMULO-2589 despite the cost it puts on our user base; both because of a
better delineation of what is and is not expected to stay constant and
because we'll have a better formulation of a lifecycle for Accumulo related
resources. In that particular matter, it's the proper lifecycle that I
personally find compelling enough to broadly cause a burden. This is
probably colored by my having dealt with ACCUMULO-2128 and its ilk.
So, given that we're going to be asking our users to deal with a headache
come 2.0 (which will hopefully be in the next 6-9 months) I would prefer to
minimize asking them to take on dealing with changes in versions prior to
that. There may be some future issue that fixes something severe enough to
warrant changing my position on the matter. This issue did not.
I talked previously about my position on API changes in general in the
background info for Josh’s message:
http://s.apache.org/HJg
and I had meant to cover the "we already agreed to break things in 2.0"
side in this admittedly short offer of compromise:
http://s.apache.org/imf
On Mon, Dec 1, 2014 at 4:25 PM, Christopher <ct...@apache.org> wrote:
> 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?
>
My general preference, as mentioned above and previously in the background
info Josh asked for, is to avoid API changes prior to 2.0. I am not arguing
that this stance be taken on as a matter of course through this particular
vote.
I think any change to our API, prior to 2.0 or after, should be carefully
considered. How we plan for users to interact with our software over time
matters. Through removals we will be directly impacting the ability of
operational users to adopt our newer versions. Through additions we will be
impacting how system integrators go about building applications above us.
It does neither us nor them any good for our API to change merely because
it improves our abstractions or condenses our support footprint.
In the consideration of the above and the nice-to-have fixes this
particular patch brings, I think it can wait for the API overhaul in 2.0.
The same two previous mailings I mentioned above to Keith are where I went
through this previously.
> -> Please address the fact that there is no breakage here...
-> Another reasonable compromise has also been proposed that seems to
address all of your concerns. Please explain why it does not.
I think these are the same question, presuming your "other compromise" is
the one of adding the new API and leaving the extant create methods
undeprecated. If not, please let me know what other compromise I missed so
that I can respond accordingly.
I covered the breakage part of this explicitly in my response to Keith's
question about which part of the API move I was concerned with:
http://s.apache.org/nn5
Essentially, moving our table creation API to use a configuration object
instead of the myriad of different arguments is a shift in how we expect
users to interact with Accumulo. Even if the breakage doesn't happen right
now, this change is setting downstream users up for pain when the break
happens. To that same end, users attempting to proactively stay up to date
on our API will break if they have to move backwards. Yes, this a normal
part of API evolution. Yes, users will have to do this at some point. I'm
merely stating that we have already reached consensus on that point being
2.0 and we should reserve using up the good will of our end users.
Similarly, simply expanding our API to have multiple long term ways of
doing table creation isn't tenable. For one, downstream users will ask
which method to use. Deprecation is how we normally offer them clear
guidance on where the API is going in the future. Without that, we'll just
be using some proxy for deprecation (either a javadoc or emails on user@).
Additionally, since the version that takes a single configuration object is
clearly the most sustainable approach, the other methods are likely to be
deprecated and then removed should we end up with additional major versions
prior to 2.0.
I covered some of this concern in my response to Brian in the first part of
my last response:
http://s.apache.org/0um
> -> 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).
I believe I covered this through a combination of the above explanations to
Keith and my response to Brian in the first part of my last response:
http://s.apache.org/0um
That we are having a 1.7 release at all is a matter of scheduling. There
are already too many things different in that development line for us to
release it as a follow on to 1.6 but not enough of our goals for 2.0 are
done to get that release out. That doesn't mean we should feel free to pack
as many breaking changes as we want into the release.
>
> 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?
>
I think this is covered above. In summary, when we alter our API we need to
consider long term impact rather than just the immediate release. We are
already going to ask our users to handle major changes in a relatively
short time period.
> -> 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?
>
I believe the rest of this message restates in detail my concerns about our
API evolution and specifically why I am on board with the planned breakage
in the 2.0 release. Let me know where there are particular gaps so I can
help clarify.
Please everyone stop this divisive tactic of continuing to claim my veto is
invalid. The surface of our API and our impact on downstream users are
valid technical considerations. Our bylaws clearly state what is needed for
a veto to be sustained and I have already passed that bar. Let’s focus our
discussion on the underlying problem rather than technicalities of our
governance.
--
Sean
Re: [VOTE] ACCUMULO-3176
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Dec 2, 2014 at 2:32 PM, Keith Turner <ke...@deenlo.com> wrote:
> On Tue, Dec 2, 2014 at 1:14 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> Responses below. I feel like most of these questions (with the noted
>> exception of details on my issue with one of the late compromise positions)
>> were previously answered, but I've tried to add additional detail below
>> where I may have been unclear in prior exchanges.
>>
>> While I agree that objections are the start of a conversation, votes are
>> meant to be provide closure so the community can move on to other work. I'd
>> ask that we try to bring this thread to a close.
Whether that's healthy depends on the depth of disagreement remaining
on the topic, and whether the resolution here turns on a veto or not.
I do not personally believe that the PMC power to veto a commit is
appropriately applied over this sort of disagreement. The community
could choose to use a majority vote to amicably resolve a disagreement
about something like this.
However, I also must admit that I've never been very comfortable with
my ability to articulate the principles behind the writings of the
various very-old-timers on the subject of commit vetos. I suggest that
the PMC invite jimjag or Roy to expound, unless someone else here
feels that they've internalized the Apache conventions well enough to
explain them. At the same time, there's no absolute requirement, as
far as I know, for every community to adopt the voting policies of the
HTTP project; but if the project ends up in an unhappy place then the
board is prone, I suspect, to be unsympathetic.
Since I'm already out on a limb because I don't have time to follow
this in detail, I'm going to exit the conversation here.
>>
>>
>> On Mon, Dec 1, 2014 at 2:40 PM, Keith Turner <ke...@deenlo.com> wrote:
>>
>> >
>> >
>> > 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.
>> >
>>
>> As a matter of background, over time I have become more convinced of the
>> need for a stable, coherent API. Too many of the end users I have seen
>> endure substantial work because of our altering of the API. This applies
>> equally for forwards and backwards compatibility. When someone has a
>> requirement to use our software and they find that the particular version
>> they need to integrate with is different than they initially expected, I
>> would like them to not have to endure project delays merely for updating
>> use of our API.
>>
>> For 2.0, we already have broad consensus around improving our API in
>> ACCUMULO-2589 despite the cost it puts on our user base; both because of a
>> better delineation of what is and is not expected to stay constant and
>> because we'll have a better formulation of a lifecycle for Accumulo related
>> resources. In that particular matter, it's the proper lifecycle that I
>> personally find compelling enough to broadly cause a burden. This is
>> probably colored by my having dealt with ACCUMULO-2128 and its ilk.
>>
>> So, given that we're going to be asking our users to deal with a headache
>> come 2.0 (which will hopefully be in the next 6-9 months) I would prefer to
>> minimize asking them to take on dealing with changes in versions prior to
>> that. There may be some future issue that fixes something severe enough to
>> warrant changing my position on the matter. This issue did not.
>>
>> I talked previously about my position on API changes in general in the
>> background info for Josh’s message:
>>
>> http://s.apache.org/HJg
>>
>> and I had meant to cover the "we already agreed to break things in 2.0"
>> side in this admittedly short offer of compromise:
>>
>> http://s.apache.org/imf
>>
>>
>>
>> On Mon, Dec 1, 2014 at 4:25 PM, Christopher <ct...@apache.org> wrote:
>>
>> > 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?
>> >
>>
>> My general preference, as mentioned above and previously in the background
>> info Josh asked for, is to avoid API changes prior to 2.0. I am not arguing
>> that this stance be taken on as a matter of course through this particular
>> vote.
>>
>> I think any change to our API, prior to 2.0 or after, should be carefully
>> considered. How we plan for users to interact with our software over time
>> matters. Through removals we will be directly impacting the ability of
>> operational users to adopt our newer versions. Through additions we will be
>> impacting how system integrators go about building applications above us.
>> It does neither us nor them any good for our API to change merely because
>> it improves our abstractions or condenses our support footprint.
>>
>> In the consideration of the above and the nice-to-have fixes this
>> particular patch brings, I think it can wait for the API overhaul in 2.0.
>>
>> The same two previous mailings I mentioned above to Keith are where I went
>> through this previously.
>>
>>
>>
>> > -> Please address the fact that there is no breakage here...
>>
>> -> Another reasonable compromise has also been proposed that seems to
>>
>> address all of your concerns. Please explain why it does not.
>>
>>
>> I think these are the same question, presuming your "other compromise" is
>> the one of adding the new API and leaving the extant create methods
>> undeprecated. If not, please let me know what other compromise I missed so
>> that I can respond accordingly.
>>
>> I covered the breakage part of this explicitly in my response to Keith's
>> question about which part of the API move I was concerned with:
>>
>> http://s.apache.org/nn5
>>
>> Essentially, moving our table creation API to use a configuration object
>> instead of the myriad of different arguments is a shift in how we expect
>> users to interact with Accumulo. Even if the breakage doesn't happen right
>> now, this change is setting downstream users up for pain when the break
>> happens. To that same end, users attempting to proactively stay up to date
>> on our API will break if they have to move backwards. Yes, this a normal
>> part of API evolution. Yes, users will have to do this at some point. I'm
>> merely stating that we have already reached consensus on that point being
>> 2.0 and we should reserve using up the good will of our end users.
>>
>> Similarly, simply expanding our API to have multiple long term ways of
>> doing table creation isn't tenable. For one, downstream users will ask
>> which method to use. Deprecation is how we normally offer them clear
>> guidance on where the API is going in the future. Without that, we'll just
>> be using some proxy for deprecation (either a javadoc or emails on user@).
>> Additionally, since the version that takes a single configuration object is
>> clearly the most sustainable approach, the other methods are likely to be
>> deprecated and then removed should we end up with additional major versions
>> prior to 2.0.
>>
>> I covered some of this concern in my response to Brian in the first part of
>> my last response:
>>
>> http://s.apache.org/0um
>>
>>
>>
>> > -> 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).
>>
>>
>> I believe I covered this through a combination of the above explanations to
>> Keith and my response to Brian in the first part of my last response:
>>
>> http://s.apache.org/0um
>>
>> That we are having a 1.7 release at all is a matter of scheduling. There
>> are already too many things different in that development line for us to
>> release it as a follow on to 1.6 but not enough of our goals for 2.0 are
>> done to get that release out. That doesn't mean we should feel free to pack
>> as many breaking changes as we want into the release.
>>
>>
>>
>> >
>> > 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?
>> >
>>
>>
>> I think this is covered above. In summary, when we alter our API we need to
>> consider long term impact rather than just the immediate release. We are
>> already going to ask our users to handle major changes in a relatively
>> short time period.
>>
>>
>>
>> > -> 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?
>> >
>>
>>
>> I believe the rest of this message restates in detail my concerns about our
>> API evolution and specifically why I am on board with the planned breakage
>> in the 2.0 release. Let me know where there are particular gaps so I can
>> help clarify.
>>
>> Please everyone stop this divisive tactic of continuing to claim my veto is
>> invalid. The surface of our API and our impact on downstream users are
>> valid technical considerations. Our bylaws clearly state what is needed for
>> a veto to be sustained and I have already passed that bar. Let’s focus our
>> discussion on the underlying problem rather than technicalities of our
>> governance.
>>
>
> You have raised some good points. I think considering 1.7.0 API changes
> w.r.t 2.0 is a good thing to consider and discuss. Drawing a line in the
> sand w/ a particular 1.7.0 API change doesn't really get us anywhere since
> there are already a few API changes in the 1.7 branch (what the heck is
> ACCUMULO-9998?) Any strategy for this will need to be agreed upon by the
> community and consider the existing API changes. A more positive way to do
> this would be to discuss a plan, write a proposal, and vote on it.
>
> $ git log --oneline -G 'ince\s+1.7.0'
> core/src/main/java/org/apache/accumulo/core/client
> e0fe2ae ACCUMULO-1957 test/whitespace cleanup
> c2d95a1 ACCUMULO-1957 implement per-session Durability
> f0a6718 ACCUMULO-9998 add waitForBalance API call
> baa7a4f ACCUMULO-2583 First stab at setting up the actual wire transfer to
> the replication peer
>
> Also I have had ACCUMULO-1798 up for review for a while and have not hear
> any complaints about API changes. I wanted to finish ACCUMULO-3134 and
> put it up for review before committing 1798.
>
>
>>
>> --
>> Sean
>>
Re: [VOTE] ACCUMULO-3176
Posted by Keith Turner <ke...@deenlo.com>.
On Tue, Dec 2, 2014 at 1:14 PM, Sean Busbey <bu...@cloudera.com> wrote:
> Responses below. I feel like most of these questions (with the noted
> exception of details on my issue with one of the late compromise positions)
> were previously answered, but I've tried to add additional detail below
> where I may have been unclear in prior exchanges.
>
> While I agree that objections are the start of a conversation, votes are
> meant to be provide closure so the community can move on to other work. I'd
> ask that we try to bring this thread to a close.
>
>
> On Mon, Dec 1, 2014 at 2:40 PM, Keith Turner <ke...@deenlo.com> wrote:
>
> >
> >
> > 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.
> >
>
> As a matter of background, over time I have become more convinced of the
> need for a stable, coherent API. Too many of the end users I have seen
> endure substantial work because of our altering of the API. This applies
> equally for forwards and backwards compatibility. When someone has a
> requirement to use our software and they find that the particular version
> they need to integrate with is different than they initially expected, I
> would like them to not have to endure project delays merely for updating
> use of our API.
>
> For 2.0, we already have broad consensus around improving our API in
> ACCUMULO-2589 despite the cost it puts on our user base; both because of a
> better delineation of what is and is not expected to stay constant and
> because we'll have a better formulation of a lifecycle for Accumulo related
> resources. In that particular matter, it's the proper lifecycle that I
> personally find compelling enough to broadly cause a burden. This is
> probably colored by my having dealt with ACCUMULO-2128 and its ilk.
>
> So, given that we're going to be asking our users to deal with a headache
> come 2.0 (which will hopefully be in the next 6-9 months) I would prefer to
> minimize asking them to take on dealing with changes in versions prior to
> that. There may be some future issue that fixes something severe enough to
> warrant changing my position on the matter. This issue did not.
>
> I talked previously about my position on API changes in general in the
> background info for Josh’s message:
>
> http://s.apache.org/HJg
>
> and I had meant to cover the "we already agreed to break things in 2.0"
> side in this admittedly short offer of compromise:
>
> http://s.apache.org/imf
>
>
>
> On Mon, Dec 1, 2014 at 4:25 PM, Christopher <ct...@apache.org> wrote:
>
> > 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?
> >
>
> My general preference, as mentioned above and previously in the background
> info Josh asked for, is to avoid API changes prior to 2.0. I am not arguing
> that this stance be taken on as a matter of course through this particular
> vote.
>
> I think any change to our API, prior to 2.0 or after, should be carefully
> considered. How we plan for users to interact with our software over time
> matters. Through removals we will be directly impacting the ability of
> operational users to adopt our newer versions. Through additions we will be
> impacting how system integrators go about building applications above us.
> It does neither us nor them any good for our API to change merely because
> it improves our abstractions or condenses our support footprint.
>
> In the consideration of the above and the nice-to-have fixes this
> particular patch brings, I think it can wait for the API overhaul in 2.0.
>
> The same two previous mailings I mentioned above to Keith are where I went
> through this previously.
>
>
>
> > -> Please address the fact that there is no breakage here...
>
> -> Another reasonable compromise has also been proposed that seems to
>
> address all of your concerns. Please explain why it does not.
>
>
> I think these are the same question, presuming your "other compromise" is
> the one of adding the new API and leaving the extant create methods
> undeprecated. If not, please let me know what other compromise I missed so
> that I can respond accordingly.
>
> I covered the breakage part of this explicitly in my response to Keith's
> question about which part of the API move I was concerned with:
>
> http://s.apache.org/nn5
>
> Essentially, moving our table creation API to use a configuration object
> instead of the myriad of different arguments is a shift in how we expect
> users to interact with Accumulo. Even if the breakage doesn't happen right
> now, this change is setting downstream users up for pain when the break
> happens. To that same end, users attempting to proactively stay up to date
> on our API will break if they have to move backwards. Yes, this a normal
> part of API evolution. Yes, users will have to do this at some point. I'm
> merely stating that we have already reached consensus on that point being
> 2.0 and we should reserve using up the good will of our end users.
>
> Similarly, simply expanding our API to have multiple long term ways of
> doing table creation isn't tenable. For one, downstream users will ask
> which method to use. Deprecation is how we normally offer them clear
> guidance on where the API is going in the future. Without that, we'll just
> be using some proxy for deprecation (either a javadoc or emails on user@).
> Additionally, since the version that takes a single configuration object is
> clearly the most sustainable approach, the other methods are likely to be
> deprecated and then removed should we end up with additional major versions
> prior to 2.0.
>
> I covered some of this concern in my response to Brian in the first part of
> my last response:
>
> http://s.apache.org/0um
>
>
>
> > -> 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).
>
>
> I believe I covered this through a combination of the above explanations to
> Keith and my response to Brian in the first part of my last response:
>
> http://s.apache.org/0um
>
> That we are having a 1.7 release at all is a matter of scheduling. There
> are already too many things different in that development line for us to
> release it as a follow on to 1.6 but not enough of our goals for 2.0 are
> done to get that release out. That doesn't mean we should feel free to pack
> as many breaking changes as we want into the release.
>
>
>
> >
> > 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?
> >
>
>
> I think this is covered above. In summary, when we alter our API we need to
> consider long term impact rather than just the immediate release. We are
> already going to ask our users to handle major changes in a relatively
> short time period.
>
>
>
> > -> 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?
> >
>
>
> I believe the rest of this message restates in detail my concerns about our
> API evolution and specifically why I am on board with the planned breakage
> in the 2.0 release. Let me know where there are particular gaps so I can
> help clarify.
>
> Please everyone stop this divisive tactic of continuing to claim my veto is
> invalid. The surface of our API and our impact on downstream users are
> valid technical considerations. Our bylaws clearly state what is needed for
> a veto to be sustained and I have already passed that bar. Let’s focus our
> discussion on the underlying problem rather than technicalities of our
> governance.
>
You have raised some good points. I think considering 1.7.0 API changes
w.r.t 2.0 is a good thing to consider and discuss. Drawing a line in the
sand w/ a particular 1.7.0 API change doesn't really get us anywhere since
there are already a few API changes in the 1.7 branch (what the heck is
ACCUMULO-9998?) Any strategy for this will need to be agreed upon by the
community and consider the existing API changes. A more positive way to do
this would be to discuss a plan, write a proposal, and vote on it.
$ git log --oneline -G 'ince\s+1.7.0'
core/src/main/java/org/apache/accumulo/core/client
e0fe2ae ACCUMULO-1957 test/whitespace cleanup
c2d95a1 ACCUMULO-1957 implement per-session Durability
f0a6718 ACCUMULO-9998 add waitForBalance API call
baa7a4f ACCUMULO-2583 First stab at setting up the actual wire transfer to
the replication peer
Also I have had ACCUMULO-1798 up for review for a while and have not hear
any complaints about API changes. I wanted to finish ACCUMULO-3134 and
put it up for review before committing 1798.
>
> --
> Sean
>
Re: [VOTE] ACCUMULO-3176
Posted by Christopher <ct...@apache.org>.
On Tue, Dec 2, 2014 at 1:14 PM, Sean Busbey <bu...@cloudera.com> wrote:
> Responses below. I feel like most of these questions (with the noted
> exception of details on my issue with one of the late compromise positions)
> were previously answered, but I've tried to add additional detail below
> where I may have been unclear in prior exchanges.
>
> While I agree that objections are the start of a conversation, votes are
> meant to be provide closure so the community can move on to other work. I'd
> ask that we try to bring this thread to a close.
>
>
I understand the frustration with a long-running thread, but so long as
your position makes no sense to me (and to the several others who have
commented in this thread who you've also seemed to have failed to
convince), I feel we must address it.
>
> On Mon, Dec 1, 2014 at 2:40 PM, Keith Turner <ke...@deenlo.com> wrote:
>
> >
> >
> > 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.
> >
>
> As a matter of background, over time I have become more convinced of the
> need for a stable, coherent API. Too many of the end users I have seen
> endure substantial work because of our altering of the API. This applies
> equally for forwards and backwards compatibility. When someone has a
> requirement to use our software and they find that the particular version
> they need to integrate with is different than they initially expected, I
> would like them to not have to endure project delays merely for updating
> use of our API.
>
>
Your justification for this veto seems to have steadily shifted away from
the reasoning you originally provided. You becoming more convinced of a
need for a stable, coherent API is a *very* different reason than that
which was initially expressed (that it didn't satisfy an underlying issue
of property updates being consistent across a cluster) which was used to
determine your vetos validity. I agree that API stability is a laudable
goal, but blocking an API improvement on the basis of a forwards
compatibility policy that *we haven't even discussed* or considered for
adoption is ridiculous, in my view. If that is your goal, then we should
revert all the ReplicationOperations API which was added to 1.7.0. Now, it
might be reasonable to prefer forwards compatibility within a major release
line, but between major releases? That is overkill, and effectively blocks
improvements and new features. Now, granted, you might not find the
particular feature very compelling of an addition, but if that were the
burden for accepting contributions (that every developer should find new
features compelling, otherwise veto), then there'd be a lot fewer features
in Accumulo... including the recently added replication features to 1.7.0,
which I personally don't find compelling within our API... but perhaps as
an external function... but I'm not willing to block inclusion of a feature
that others have valid use cases for, simply because I don't find it
compelling enough to use it. I understand that we can have different
metrics for our decisions about what to veto.
Adding one new method to the API does *not* require *any* such endurance on
behalf of users, especially when added to a "major version" 1.7.0. Major
versions are where we can add breaking API changes, so why block a minor
improvement which adds *no* such breakage? I could understand if this
provided no value, and simply changed the look and feel of the API... if
that were the case, I'd agree with you. It's not worth it. However, this
actually provides functionality... important functionality... that
satisfies the specified use cases, and you are preventing those use cases
from being satisfied, and your reasoning for doing so makes no sense.
Would you be okay with this change if it did not introduce the
"NewTableConfiguration" object, and simply added an overloaded createTable
method that took a Map of additional properties? Because that wouldn't
change the look and feel of the API in any way? What I'm trying to
understand by this question is whether you feel the "burden" of adding a
new feature to the API is created by the change in the look-and-feel of the
API, or by the new utility. If it's just the look-and-feel, then we can
address that with a smaller change that adds an overloaded method to
provide the same utility, and we've identified yet another opportunity for
compromise.
> For 2.0, we already have broad consensus around improving our API in
> ACCUMULO-2589 despite the cost it puts on our user base; both because of a
> better delineation of what is and is not expected to stay constant and
> because we'll have a better formulation of a lifecycle for Accumulo related
> resources. In that particular matter, it's the proper lifecycle that I
> personally find compelling enough to broadly cause a burden. This is
> probably colored by my having dealt with ACCUMULO-2128 and its ilk.
>
>
Any conversation about 2.0 is hypothetical. There has been no formally
submitted code for API improvements for 2.0, for consideration in a
release. We cannot block improvements to 1.x on the basis of some
forthcoming changes in the future. We're also talking about a feature that
would be very useful for certain use cases long before 2.0 is ready for
release.
Again, what you find compelling should not be the metric for vetoing
contributions. A more reasonable measure is whether it satisfies valid use
cases without causing some demonstrable harm, and this change does satisfy
valid use cases and can be done without affecting existing API (not even
deprecating them, if we wish), and does so in a major version.
> So, given that we're going to be asking our users to deal with a headache
> come 2.0 (which will hopefully be in the next 6-9 months) I would prefer to
> minimize asking them to take on dealing with changes in versions prior to
> that. There may be some future issue that fixes something severe enough to
> warrant changing my position on the matter. This issue did not.
>
>
Again, I anticipate no such headache. You're speaking hypothetically about
proposed changes for which no code has been submitted for consideration
yet. This reasoning does not make sense.
> I talked previously about my position on API changes in general in the
> background info for Josh’s message:
>
> http://s.apache.org/HJg
>
>
And in that message, you incorrectly suggested that the problem could be
solved by addressing property updates... which is not true, because
assignments and balancing will already be in play before that property
update is issued. This is a completely separate issue being addressed, that
would *still* be a problem, regardless of whether we address property
updates. This issue is about *initial* table configuration, not table
configuration *changes*.
> and I had meant to cover the "we already agreed to break things in 2.0"
> side in this admittedly short offer of compromise:
>
> http://s.apache.org/imf
>
>
Again, hypothetical future code, that (with the exception of the removal of
deprecated API), there is no anticipated breakage. I don't know what you're
talking about.
>
>
> On Mon, Dec 1, 2014 at 4:25 PM, Christopher <ct...@apache.org> wrote:
>
> > 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?
> >
>
> My general preference, as mentioned above and previously in the background
> info Josh asked for, is to avoid API changes prior to 2.0. I am not arguing
> that this stance be taken on as a matter of course through this particular
> vote.
>
> I think any change to our API, prior to 2.0 or after, should be carefully
> considered. How we plan for users to interact with our software over time
> matters. Through removals we will be directly impacting the ability of
> operational users to adopt our newer versions. Through additions we will be
> impacting how system integrators go about building applications above us.
> It does neither us nor them any good for our API to change merely because
> it improves our abstractions or condenses our support footprint.
>
> In the consideration of the above and the nice-to-have fixes this
> particular patch brings, I think it can wait for the API overhaul in 2.0.
>
> The same two previous mailings I mentioned above to Keith are where I went
> through this previously.
>
>
>
> > -> Please address the fact that there is no breakage here...
>
> -> Another reasonable compromise has also been proposed that seems to
>
> address all of your concerns. Please explain why it does not.
>
>
> I think these are the same question, presuming your "other compromise" is
> the one of adding the new API and leaving the extant create methods
> undeprecated. If not, please let me know what other compromise I missed so
> that I can respond accordingly.
>
>
Yes, that is the other compromise I refer to. (compromise #2)
> I covered the breakage part of this explicitly in my response to Keith's
> question about which part of the API move I was concerned with:
>
> http://s.apache.org/nn5
>
> Essentially, moving our table creation API to use a configuration object
> instead of the myriad of different arguments is a shift in how we expect
> users to interact with Accumulo. Even if the breakage doesn't happen right
> now, this change is setting downstream users up for pain when the break
> happens. To that same end, users attempting to proactively stay up to date
> on our API will break if they have to move backwards. Yes, this a normal
> part of API evolution. Yes, users will have to do this at some point. I'm
> merely stating that we have already reached consensus on that point being
> 2.0 and we should reserve using up the good will of our end users.
>
>
Okay, so first, no, we have not reached consensus on this point being 2.0.
We've only reached that in terms of removals... not additions. This entire
paragraph is invalid if we accept compromise #2. Only "moving" would create
that, yes, but "adding" a new method to do that does not. If we had agreed
that no new additions would be added, then we should revert all of the
replication API which was added.
What if we were to add the method with a @Beta or @Experimental annotation
in addition to compromise #2? (compromise #3).
Also, what about an overloaded method which does not add the configuration
object, but only an additional parameter (suggested above)? (compromise #4)
> Similarly, simply expanding our API to have multiple long term ways of
> doing table creation isn't tenable. For one, downstream users will ask
> which method to use. Deprecation is how we normally offer them clear
> guidance on where the API is going in the future. Without that, we'll just
> be using some proxy for deprecation (either a javadoc or emails on user@).
> Additionally, since the version that takes a single configuration object is
> clearly the most sustainable approach, the other methods are likely to be
> deprecated and then removed should we end up with additional major versions
> prior to 2.0.
>
>
I think we could probably reach consensus on the idea that we won't remove
any deprecated APIs prior to 2.0, and we I bet could even reach consensus
on the idea that no methods deprecated in 1.7.0 and later will be removed
until 3.0, giving plenty of time for migration.
> I covered some of this concern in my response to Brian in the first part of
> my last response:
>
> http://s.apache.org/0um
>
>
>
> > -> 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).
>
>
> I believe I covered this through a combination of the above explanations to
> Keith and my response to Brian in the first part of my last response:
>
> http://s.apache.org/0um
>
> That we are having a 1.7 release at all is a matter of scheduling. There
> are already too many things different in that development line for us to
> release it as a follow on to 1.6 but not enough of our goals for 2.0 are
> done to get that release out. That doesn't mean we should feel free to pack
> as many breaking changes as we want into the release.
>
>
>
This is *NOT* a breaking change! You keep using that term, but I've
repeatedly expressed why it is incorrect to do so. Please adjust your mode
of thinking with regard to whether this is breaking or not, and select your
terminology more carefully, to reflect the actual nature of the proposed
patch (which does not break any API or necessarily influence any future
breakage).
>
> >
> > 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?
> >
>
>
> I think this is covered above. In summary, when we alter our API we need to
> consider long term impact rather than just the immediate release. We are
> already going to ask our users to handle major changes in a relatively
> short time period.
>
>
Okay, but we've already addressed a compromise that allows us to address
this (don't deprecate, don't remove until at least 3.0).
>
>
> > -> 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?
> >
>
>
> I believe the rest of this message restates in detail my concerns about our
> API evolution and specifically why I am on board with the planned breakage
> in the 2.0 release. Let me know where there are particular gaps so I can
> help clarify.
>
> Please everyone stop this divisive tactic of continuing to claim my veto is
> invalid. The surface of our API and our impact on downstream users are
> valid technical considerations. Our bylaws clearly state what is needed for
> a veto to be sustained and I have already passed that bar. Let’s focus our
> discussion on the underlying problem rather than technicalities of our
> governance.
>
>
It is not a "tactic", it is our *(at least, my) opinion that your veto is
invalid (at least, the original veto justification). My request for Bill
was to provide clarification to the reasoning, so we can understand
precedence for future validity determinations... it was not a tactic to try
to overturn the validity determination here. We can address that in a
separate thread, if needed, but I thought the clarification might also add
value here.
To be clear, I think your original justification was invalid, but your
concerns about API are valid (albeit insufficient, in my view, to warrant a
veto, and very problematic and inconsistently applied to API additions, as
Keith points out), and completely addressable by several of the proposed
compromises that would still permit the functionality which is required for
several valid use cases.
Re: [VOTE] ACCUMULO-3176
Posted by Sean Busbey <bu...@cloudera.com>.
Responses below. I feel like most of these questions (with the noted
exception of details on my issue with one of the late compromise positions)
were previously answered, but I've tried to add additional detail below
where I may have been unclear in prior exchanges.
While I agree that objections are the start of a conversation, votes are
meant to be provide closure so the community can move on to other work. I'd
ask that we try to bring this thread to a close.
On Mon, Dec 1, 2014 at 2:40 PM, Keith Turner <ke...@deenlo.com> wrote:
>
>
> 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.
>
As a matter of background, over time I have become more convinced of the
need for a stable, coherent API. Too many of the end users I have seen
endure substantial work because of our altering of the API. This applies
equally for forwards and backwards compatibility. When someone has a
requirement to use our software and they find that the particular version
they need to integrate with is different than they initially expected, I
would like them to not have to endure project delays merely for updating
use of our API.
For 2.0, we already have broad consensus around improving our API in
ACCUMULO-2589 despite the cost it puts on our user base; both because of a
better delineation of what is and is not expected to stay constant and
because we'll have a better formulation of a lifecycle for Accumulo related
resources. In that particular matter, it's the proper lifecycle that I
personally find compelling enough to broadly cause a burden. This is
probably colored by my having dealt with ACCUMULO-2128 and its ilk.
So, given that we're going to be asking our users to deal with a headache
come 2.0 (which will hopefully be in the next 6-9 months) I would prefer to
minimize asking them to take on dealing with changes in versions prior to
that. There may be some future issue that fixes something severe enough to
warrant changing my position on the matter. This issue did not.
I talked previously about my position on API changes in general in the
background info for Josh’s message:
http://s.apache.org/HJg
and I had meant to cover the "we already agreed to break things in 2.0"
side in this admittedly short offer of compromise:
http://s.apache.org/imf
On Mon, Dec 1, 2014 at 4:25 PM, Christopher <ct...@apache.org> wrote:
> 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?
>
My general preference, as mentioned above and previously in the background
info Josh asked for, is to avoid API changes prior to 2.0. I am not arguing
that this stance be taken on as a matter of course through this particular
vote.
I think any change to our API, prior to 2.0 or after, should be carefully
considered. How we plan for users to interact with our software over time
matters. Through removals we will be directly impacting the ability of
operational users to adopt our newer versions. Through additions we will be
impacting how system integrators go about building applications above us.
It does neither us nor them any good for our API to change merely because
it improves our abstractions or condenses our support footprint.
In the consideration of the above and the nice-to-have fixes this
particular patch brings, I think it can wait for the API overhaul in 2.0.
The same two previous mailings I mentioned above to Keith are where I went
through this previously.
> -> Please address the fact that there is no breakage here...
-> Another reasonable compromise has also been proposed that seems to
address all of your concerns. Please explain why it does not.
I think these are the same question, presuming your "other compromise" is
the one of adding the new API and leaving the extant create methods
undeprecated. If not, please let me know what other compromise I missed so
that I can respond accordingly.
I covered the breakage part of this explicitly in my response to Keith's
question about which part of the API move I was concerned with:
http://s.apache.org/nn5
Essentially, moving our table creation API to use a configuration object
instead of the myriad of different arguments is a shift in how we expect
users to interact with Accumulo. Even if the breakage doesn't happen right
now, this change is setting downstream users up for pain when the break
happens. To that same end, users attempting to proactively stay up to date
on our API will break if they have to move backwards. Yes, this a normal
part of API evolution. Yes, users will have to do this at some point. I'm
merely stating that we have already reached consensus on that point being
2.0 and we should reserve using up the good will of our end users.
Similarly, simply expanding our API to have multiple long term ways of
doing table creation isn't tenable. For one, downstream users will ask
which method to use. Deprecation is how we normally offer them clear
guidance on where the API is going in the future. Without that, we'll just
be using some proxy for deprecation (either a javadoc or emails on user@).
Additionally, since the version that takes a single configuration object is
clearly the most sustainable approach, the other methods are likely to be
deprecated and then removed should we end up with additional major versions
prior to 2.0.
I covered some of this concern in my response to Brian in the first part of
my last response:
http://s.apache.org/0um
> -> 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).
I believe I covered this through a combination of the above explanations to
Keith and my response to Brian in the first part of my last response:
http://s.apache.org/0um
That we are having a 1.7 release at all is a matter of scheduling. There
are already too many things different in that development line for us to
release it as a follow on to 1.6 but not enough of our goals for 2.0 are
done to get that release out. That doesn't mean we should feel free to pack
as many breaking changes as we want into the release.
>
> 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?
>
I think this is covered above. In summary, when we alter our API we need to
consider long term impact rather than just the immediate release. We are
already going to ask our users to handle major changes in a relatively
short time period.
> -> 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?
>
I believe the rest of this message restates in detail my concerns about our
API evolution and specifically why I am on board with the planned breakage
in the 2.0 release. Let me know where there are particular gaps so I can
help clarify.
Please everyone stop this divisive tactic of continuing to claim my veto is
invalid. The surface of our API and our impact on downstream users are
valid technical considerations. Our bylaws clearly state what is needed for
a veto to be sustained and I have already passed that bar. Let’s focus our
discussion on the underlying problem rather than technicalities of our
governance.
--
Sean
Re: [VOTE] ACCUMULO-3176
Posted by Christopher <ct...@apache.org>.
On Mon, Dec 1, 2014 at 3:29 PM, Sean Busbey <bu...@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 <ct...@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 <ct...@apache.org>
> wrote:
> >
> > > On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey <bu...@cloudera.com>
> > wrote:
> > >
> > >> Responses to a few things below.
> > >>
> > >>
> > >> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss <bf...@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 <bu...@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 <ct...@apache.org>
> > wrote:
> > >>
> > >> > On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki <
> > >> bhavanki@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
> > > majority vote might be considered to be.
> > >
> > >
> > >> That said, I am generally a proponent of not letting "where discussion
> > >> should happen" get in the way of reaching consensus. However, in this
> > case
> > >> I don't think we have sufficient time to work through the details of
> > why I
> > >> don't find API sprawl a compelling fix for my concerns. I know I
> > >> definitely
> > >> don't have the spoons for it.
> > >>
> > >> I'm sorry, but if you are unwilling to defend your veto further, I
> don't
> > > see how you can expect it to be binding. Please address why this change
> > > could not be introduced with the compromise proposed.
> > >
> > >
> > >> I have offered a reasonable compromise position that addresses both my
> > >> concerns while adding the feature you want. Please take it.
> > >>
> > >> Another reasonable compromise has also been proposed that seems to
> > > address all of your concerns. Please explain why it does not.
> > >
> > > I would also like to add that inclusion of this now would greatly help
> me
> > > add the wiring necessary for the new API.
> > >
> > >
> > >> I don't think I'll have time to be on email again before the vote
> > closes.
> > >> You may consider my -1 withdrawn if the change is restricted to 2.0
> > >>
> > >>
> > >> On Tue, Nov 25, 2014 at 3:07 PM, Christopher <ct...@apache.org>
> > wrote:
> > >>
> > >> > On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey <bu...@cloudera.com>
> > >> wrote:
> > >> >
> > >> > > On Tue, Nov 25, 2014 at 2:23 PM, Christopher <ctubbsii@apache.org
> >
> > >> > wrote:
> > >> > >
> > >> > > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey <
> busbey@cloudera.com
> > >
> > >> > > wrote:
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > I understand that the use cases enabled by this patch are
> > sufficiently
> > >> > > compelling for you. They are not sufficiently compelling for me,
> > >> hence my
> > >> > > veto.
> > >> > >
> > >> > >
> > >> > I don't know that there is a requirement to make every code addition
> > >> > sufficiently compelling to every developer, in order to include it.
> If
> > >> that
> > >> > were the case, I don't think many features would have made it in.
> This
> > >> > seems to be an anti-progress position if we allow it to become the
> > >> norm. It
> > >> > seems to me that there should be compelling reasons to reject a
> > >> > contribution that does not break or affect existing functionality.
> > >> >
> > >>
> > >> This VOTE thread is also not the place to get into a discussion of our
> > >> governance model. However, what you are saying is directly opposed to
> > the
> > >> fundamental way code changes work in Apache projects; it's the
> "Review"
> > >> part of Commit Then Review and Review Then Commit. We use the former
> > >> because we presume that most changes will be compelling. Because every
> > >> part
> > >> of "compelling" and "cost" is hugely subjective we require that vetoes
> > >> come
> > >> with a rationale.
> > >>
> > >> It is indeed very anti-progress. That's one of the overheads of being
> > in a
> > >> community. It's also why I have previously stated that these change
> > votes
> > >> should be Majority Approval instead of Consensus Approval.
> > >>
> > >> > Also, since you can only veto
> > >> > changesets, and not release candidates, I don't see what would stop
> a
> > >> > release manager from backporting this changeset to 1.7 prior to its
> > >> release
> > >> > if we push it to a 2.0 branch. I don't see why this improvement must
> > be
> > >> > postponed.
> > >>
> > >> The thing that would stop them is that we are a community. It would be
> > >> incredibly rude for a release manager to do this after the restriction
> > to
> > >> 2.0 was the end compromise reached. We are not in a state of nature
> and
> > >> the
> > >> bylaws are not our leviathan. We are a group working towards common
> > goals.
> > >>
> > >>
> > >> --
> > >> Sean
> > >>
> > >
> > >
> >
>
>
>
> --
> Sean
>
Re: [VOTE] ACCUMULO-3176
Posted by Sean Busbey <bu...@cloudera.com>.
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 <ct...@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 <ct...@apache.org> wrote:
>
> > On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey <bu...@cloudera.com>
> wrote:
> >
> >> Responses to a few things below.
> >>
> >>
> >> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss <bf...@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 <bu...@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 <ct...@apache.org>
> wrote:
> >>
> >> > On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki <
> >> bhavanki@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
> > majority vote might be considered to be.
> >
> >
> >> That said, I am generally a proponent of not letting "where discussion
> >> should happen" get in the way of reaching consensus. However, in this
> case
> >> I don't think we have sufficient time to work through the details of
> why I
> >> don't find API sprawl a compelling fix for my concerns. I know I
> >> definitely
> >> don't have the spoons for it.
> >>
> >> I'm sorry, but if you are unwilling to defend your veto further, I don't
> > see how you can expect it to be binding. Please address why this change
> > could not be introduced with the compromise proposed.
> >
> >
> >> I have offered a reasonable compromise position that addresses both my
> >> concerns while adding the feature you want. Please take it.
> >>
> >> Another reasonable compromise has also been proposed that seems to
> > address all of your concerns. Please explain why it does not.
> >
> > I would also like to add that inclusion of this now would greatly help me
> > add the wiring necessary for the new API.
> >
> >
> >> I don't think I'll have time to be on email again before the vote
> closes.
> >> You may consider my -1 withdrawn if the change is restricted to 2.0
> >>
> >>
> >> On Tue, Nov 25, 2014 at 3:07 PM, Christopher <ct...@apache.org>
> wrote:
> >>
> >> > On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey <bu...@cloudera.com>
> >> wrote:
> >> >
> >> > > On Tue, Nov 25, 2014 at 2:23 PM, Christopher <ct...@apache.org>
> >> > wrote:
> >> > >
> >> > > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey <busbey@cloudera.com
> >
> >> > > wrote:
> >> > > >
> >> > > >
> >> > > >
> >> > > I understand that the use cases enabled by this patch are
> sufficiently
> >> > > compelling for you. They are not sufficiently compelling for me,
> >> hence my
> >> > > veto.
> >> > >
> >> > >
> >> > I don't know that there is a requirement to make every code addition
> >> > sufficiently compelling to every developer, in order to include it. If
> >> that
> >> > were the case, I don't think many features would have made it in. This
> >> > seems to be an anti-progress position if we allow it to become the
> >> norm. It
> >> > seems to me that there should be compelling reasons to reject a
> >> > contribution that does not break or affect existing functionality.
> >> >
> >>
> >> This VOTE thread is also not the place to get into a discussion of our
> >> governance model. However, what you are saying is directly opposed to
> the
> >> fundamental way code changes work in Apache projects; it's the "Review"
> >> part of Commit Then Review and Review Then Commit. We use the former
> >> because we presume that most changes will be compelling. Because every
> >> part
> >> of "compelling" and "cost" is hugely subjective we require that vetoes
> >> come
> >> with a rationale.
> >>
> >> It is indeed very anti-progress. That's one of the overheads of being
> in a
> >> community. It's also why I have previously stated that these change
> votes
> >> should be Majority Approval instead of Consensus Approval.
> >>
> >> > Also, since you can only veto
> >> > changesets, and not release candidates, I don't see what would stop a
> >> > release manager from backporting this changeset to 1.7 prior to its
> >> release
> >> > if we push it to a 2.0 branch. I don't see why this improvement must
> be
> >> > postponed.
> >>
> >> The thing that would stop them is that we are a community. It would be
> >> incredibly rude for a release manager to do this after the restriction
> to
> >> 2.0 was the end compromise reached. We are not in a state of nature and
> >> the
> >> bylaws are not our leviathan. We are a group working towards common
> goals.
> >>
> >>
> >> --
> >> Sean
> >>
> >
> >
>
--
Sean