accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [VOTE] ACCUMULO-3176
Date Mon, 01 Dec 2014 21:12:17 GMT
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 <cjnolet@gmail.com> wrote:

> +1 in case it wasn't inferred from my previous comments. As Josh stated,
> I'm still confused how the veto still holds technical justification- the
> changes being made aren't removing methods from the public API.
>
> On Mon, Dec 1, 2014 at 3:42 PM, Josh Elser <josh.elser@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<ctubbsii@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<ctubbsii@apache.org>
> >>> wrote:
> >>>
> >>>  On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey<busbey@cloudera.com>
> >>>>
> >>> wrote:
> >>>
> >>>> Responses to a few things below.
> >>>>>
> >>>>>
> >>>>> On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss<bfloss@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<busbey@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<ctubbsii@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<ctubbsii@apache.org>
> >>>>>
> >>>> wrote:
> >>>
> >>>> On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey<busbey@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
> >>>>>
> >>>>>
> >>>>
> >>
> >>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message