accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Thu, 04 Dec 2014 20:51:05 GMT
On Thu, Dec 4, 2014 at 3:44 PM, Josh Elser <josh.elser@gmail.com> wrote:

> Mike Drob wrote:
>
>> It looks like we've had several proposed amendments to the original
>>>> >  >  proposal, but I am very unclear on if we are voting on any of
>>>> them or if
>>>> >  >  they are simply brought up as nice discussion points. There's
>>>> been so
>>>>
>>> >  much
>>>
>>>> >  >  discussion in this VOTE thread (a strange complaint, I know)
that
>>>> I don't
>>>> >  >  have a clear picture of what is up for decision any more.
>>>> >  >  There has been so much negotiating and back and forth that I
>>>> don't know
>>>> >  >  which amendments are part of the vote, which ones are intended
to
>>>> be a
>>>> >  >  follow on vote, and which ones are wild ideas that only a
>>>> splinter group
>>>> >  >  supports.
>>>> >  >
>>>>
>>> >
>>> >  I think votes should only be considered as for or against the original
>>> >  proposal, discussion can happen after someone votes.
>>> >
>>> >  Sounds like you're saying that none of them apply. That's fine. In
>>> that
>>>
>> case:
>>
>> -1.  The language in the initial proposal is vague and imprecise.
>>
>> Mechanically, where do we apply these guidelines? Are these changes to our
>> governance model?
>>
>> Why are we forcing ourselves to commit to the1.7  API in2.0,  if there is
>> a
>> 1.8  that deprecates things? What is so special about1.7  at all?
>>
>

Do you want to relax this and say that as long an API method was deprecated
in a 1.X release,made before 2.0.0, that it can be dropped in 2.0.0?


>
>> I agree with John's concerns.
>>
>> I don't think that we can make practical progress on this issue until we
>> have a real proposal in hand. I'd rather not speculate and vote about
>> hypothetical APIs.
>>
>>
> The point of trying to prevent any removals/changes was to satisfy the
> concerns that Sean had raised about ACCUMULO-3176. That's the entire basis
> for this discussion if that helps.
>

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