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<[email protected]> wrote:
On Wed, Nov 26, 2014 at 11:57 AM, Sean Busbey<[email protected]>
wrote:
Responses to a few things below.
On Tue, Nov 25, 2014 at 2:56 PM, Brian Loss<[email protected]>
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<[email protected]>
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<[email protected]>
wrote:
On Tue, Nov 25, 2014 at 5:07 PM, Bill Havanki<
[email protected]>
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<[email protected]>
wrote:
On Tue, Nov 25, 2014 at 3:42 PM, Sean Busbey<[email protected]>
wrote:
On Tue, Nov 25, 2014 at 2:23 PM, Christopher<[email protected]>
wrote:
On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey<[email protected]
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
