You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Benedict Elliott Smith <be...@apache.org> on 2023/02/02 09:29:33 UTC
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Closing the loop on seeking consensus for UX/UI/API changes, I see a few options. Can we rank choice vote please?
A - Jira suffices
B - Post a DISCUSS API thread prior to making changes
C - Periodically publish a list of API changes for retrospective consideration by the community
Points raised in the discussion included: lowering the bar for participation and avoiding unnecessary burden to developers.
I vote B (only) because I think broader participation is most important for these topics.
> On 7 Dec 2022, at 15:43, Mick Semb Wever <mc...@apache.org> wrote:
>
>> I think it makes sense to look into improving visibility of API changes, so people can more easily review a summary of API changes versus reading through the whole changelog (perhaps we need a summarized API change log?).
>
>
> Agree Paulo.
>
> Observers should be able to see all API changes early. We can do better than telling downstream users/devs "you have to listen to all jira tickets" or "you have to watch the code and pick up changes". Watching CHANGES.txt or NEWS.txt or CEPs doesn't solve the need either.
>
> Observing such changes as early as possible can save a significant amount of effort and headache later on, and should be encouraged. If done correctly I can imagine it will help welcome more contributors.
>
> I can also see that we can improve at, and have a better shared understanding of, categorising the types of API changes: addition/change/deprecation/removal, signature/output/behavioural, API/SPI. So I can see value here for both observers and for ourselves.
>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Benedict <be...@apache.org>.
If we expose internal mechanics to public APIs, we should probably document
what our promises are - ie none, even between patch versions.
So we can close out this discussion, let’s assume we’re only discussing any
interfaces we want to make promises for. We can have a separate discussion
about which those are if there is any disagreement.
> On 2 Feb 2023, at 10:16, Andrés de la Peña <ad...@apache.org> wrote:
>
>
>
>
> I guess that depends on the type of change, and what we consider an API.
>
> If it's a breaking change, like removing a method or property, I think we
> would need a DISCUSS API thread prior to making changes. However, if the
> change is an addition, like adding a new yaml property or a JMX method, I
> think JIRA suffices.
>
> As for what we consider a public API, we usually include extensible
> interfaces on this. For example, we can agree that the Index interface for
> secondary indexes is a public API. However, that interface exposes many
> other interfaces and classes through its methods. For example, that Index
> interface exposes ColumnFamillyStore, SSTableReader, ColumnMetadata,
> AbstractType, PartitionUpdate, etc. Changes into those indirectly exposed
> classes can easily break custom index implementations out there. Should we
> consider them public APIs too, and require a DISCUSS thread for every change
> on them? Should that include new methods that wouldn't break compatibility?
>
>
>
>
>
> On Thu, 2 Feb 2023 at 09:29, Benedict Elliott Smith
> <[benedict@apache.org](mailto:benedict@apache.org)> wrote:
>
>
>> Closing the loop on seeking consensus for UX/UI/API changes, I see a few
options. Can we rank choice vote please?
>>
>>
>
>>
>> A - Jira suffices
>>
>> B - Post a DISCUSS API thread prior to making changes
>>
>> C - Periodically publish a list of API changes for retrospective
consideration by the community
>>
>>
>
>>
>> Points raised in the discussion included: lowering the bar for
participation and avoiding unnecessary burden to developers.
>>
>>
>
>>
>> I vote B (only) because I think broader participation is most important for
these topics.
>>
>>
>
>>
>>
>
>>
>>> On 7 Dec 2022, at 15:43, Mick Semb Wever
<[mck@apache.org](mailto:mck@apache.org)> wrote:
>>>
>>>
>
>>>
>>>> I think it makes sense to look into improving visibility of API changes,
so people can more easily review a summary of API changes versus reading
through the whole changelog (perhaps we need a summarized API change log?).
>
>>>
>>>
>
>>>
>>>
>
>>>
>>> Agree Paulo.
>>>
>>>
>
>>>
>>> Observers should be able to see all API changes early. We can do better
than telling downstream users/devs "you have to listen to all jira tickets" or
"you have to watch the code and pick up changes". Watching CHANGES.txt or
NEWS.txt or CEPs doesn't solve the need either.
>>>
>>>
>
>>>
>>> Observing such changes as early as possible can save a significant amount
of effort and headache later on, and should be encouraged. If done correctly I
can imagine it will help welcome more contributors.
>>>
>>>
>
>>>
>>> I can also see that we can improve at, and have a better shared
understanding of, categorising the types of API changes:
addition/change/deprecation/removal, signature/output/behavioural, API/SPI. So
I can see value here for both observers and for ourselves.
>>>
>>>
>
>>
>>
>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Berenguer Blasi <be...@gmail.com>.
Hi All,
I don't think we can be 100% prescriptive here. There will always be
gray areas on where API changes start or end. Even on what is an API
change and discussions about why a change was forgotten, not
communicated, etc. I think we should rely on people's judgement on when
to hit the ML/CEP when a significant change is about to come. Smaller
changes could be caught by a weekly git digest of changes to a set of
files, where any challenged commits should be easy to amend/revert
within the week of the commit. What 'significant change', 'small
change', etc means is left open to the criteria of the people involved
and with time we will all align and learn.
Also would it be correct to assume it will be way way cheaper to address
the seldom rare offenders than to CEP/ML every single change feeling the
weight of the process? Think also on process burden for newcomers and
the on boarding experience.
It doesn't 100% fit A, B or C but a bit from each.
On 2/2/23 17:54, Benedict wrote:
> I’m inclined to agree with Jeremiah and Patrick, even if it might be a
> steep jump from what we’ve been used to. CQL needs to be treated with
> the utmost care and attention to detail. Would we apply the same
> standard to semantic bug fixes too? Perhaps we should, where there
> isn’t an urgent timeline at least.
>
> Once the dust settles from this vote, depending how it tabulates, we
> can see what topics like this we might need another round to nail down.
>
>> On 2 Feb 2023, at 15:56, Jeremiah D Jordan
>> <je...@gmail.com> wrote:
>>
>> I think we need a DISCUSS thread at minimum for API changes. And
>> for anything changing CQL syntax, I think a CEP is warranted. Even
>> if it is only a small change to the syntax.
>>
>>> On Feb 2, 2023, at 9:32 AM, Patrick McFadin <pm...@gmail.com> wrote:
>>>
>>> API changes are near and dear to my world. The scope of changes
>>> could be minor or major, so I think B is the right way forward.
>>>
>>> Not to throw off the momentum, but could this even warrant a
>>> separate CEP in some cases? For example, CEP-15 is a huge change,
>>> but the CQL syntax will continuously evolve with more use. Being
>>> judicious in those changes is good for end users. It's also a good
>>> reference to point back to after the fact.
>>>
>>> Patrick
>>>
>>> On Thu, Feb 2, 2023 at 6:01 AM Ekaterina Dimitrova
>>> <e....@gmail.com> wrote:
>>>
>>> “ Only that it locks out of the conversation anyone without a
>>> Jira login”
>>> Very valid point I forgot about - since recently people need
>>> invitation in order to create account…
>>> Then I would say C until we clarify the scope. Thanks
>>>
>>> On Thu, 2 Feb 2023 at 8:54, Benedict <be...@apache.org> wrote:
>>>
>>> I think lazy consensus is fine for all of these things. If a
>>> DISCUSS thread is crickets, or just positive responses, then
>>> definitely it can proceed without further ceremony.
>>>
>>> I think “with heads-up to the mailing list” is very close to
>>> B? Only that it locks out of the conversation anyone without
>>> a Jira login.
>>>
>>>> On 2 Feb 2023, at 13:46, Ekaterina Dimitrova
>>>> <e....@gmail.com> wrote:
>>>>
>>>>
>>>> While I do agree with you, I am thinking that if we include
>>>> many things that we would expect lazy consensus on I would
>>>> probably have different preference.
>>>>
>>>> I definitely don’t mean to stall this though so in that case:
>>>> I’d say combination of A+C (jira with heads up on the ML if
>>>> someone is interested into the jira) and regular log on API
>>>> changes separate from CHANGES.txt or we can just add labels
>>>> to entries in CHANGES.txt as some other projects. (I guess
>>>> this is a detail we can agree on later on, how to implement
>>>> it, if we decide to move into that direction)
>>>>
>>>> On Thu, 2 Feb 2023 at 8:12, Benedict <be...@apache.org>
>>>> wrote:
>>>>
>>>> I think it’s fine to separate the systems from the
>>>> policy? We are agreeing a policy for systems we want to
>>>> make guarantees about to our users (regarding
>>>> maintenance and compatibility)
>>>>
>>>> For me, this is (at minimum) CQL and virtual tables.
>>>> But I don’t think the policy differs based on the
>>>> contents of the list, and given how long this topic
>>>> stalled for. Given the primary point of contention
>>>> seems to be the *policy* and not the list, I think it’s
>>>> time to express our opinions numerically so we can move
>>>> the conversation forwards.
>>>>
>>>> This isn’t binding, it just reifies the community
>>>> sentiment.
>>>>
>>>>> On 2 Feb 2023, at 13:02, Ekaterina Dimitrova
>>>>> <e....@gmail.com> wrote:
>>>>>
>>>>>
>>>>> “ So we can close out this discussion, let’s assume
>>>>> we’re only discussing any interfaces we want to make
>>>>> promises for. We can have a separate discussion about
>>>>> which those are if there is any disagreement.”
>>>>> May I suggest we first clear this topic and then move
>>>>> to voting? I would say I see confusion, not that much
>>>>> of a disagreement. Should we raise a discussion for
>>>>> every feature flag for example? In another thread
>>>>> virtual tables were brought in. I saw also other
>>>>> examples where people expressed uncertainty. I
>>>>> personally feel I’ll be able to take a more informed
>>>>> decision and vote if I first see this clarified.
>>>>>
>>>>> I will be happy to put down a document and bring it
>>>>> for discussion if people agree with that
>>>>>
>>>>>
>>>>>
>>>>> On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko
>>>>> <al...@apple.com> wrote:
>>>>>
>>>>> Bringing light to new proposed APIs no less
>>>>> important - if not more, for reasons already
>>>>> mentioned in this thread. For it’s not easy to
>>>>> change them later.
>>>>>
>>>>> Voting B.
>>>>>
>>>>>
>>>>>> On 2 Feb 2023, at 10:15, Andrés de la Peña
>>>>>> <ad...@apache.org> wrote:
>>>>>>
>>>>>> If it's a breaking change, like removing a method
>>>>>> or property, I think we would need a DISCUSS API
>>>>>> thread prior to making changes. However, if the
>>>>>> change is an addition, like adding a new yaml
>>>>>> property or a JMX method, I think JIRA suffices.
>>>>>
>>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Benedict <be...@apache.org>.
I’m inclined to agree with Jeremiah and Patrick, even if it might be a steep
jump from what we’ve been used to. CQL needs to be treated with the utmost
care and attention to detail. Would we apply the same standard to semantic bug
fixes too? Perhaps we should, where there isn’t an urgent timeline at least.
Once the dust settles from this vote, depending how it tabulates, we can see
what topics like this we might need another round to nail down.
> On 2 Feb 2023, at 15:56, Jeremiah D Jordan <je...@gmail.com>
> wrote:
>
>
> I think we need a DISCUSS thread at minimum for API changes. And for
> anything changing CQL syntax, I think a CEP is warranted. Even if it is
> only a small change to the syntax.
>
>
>
>
>
>> On Feb 2, 2023, at 9:32 AM, Patrick McFadin <pm...@gmail.com> wrote:
>>
>>
>
>>
>> API changes are near and dear to my world. The scope of changes could be
minor or major, so I think B is the right way forward.
>>
>>
>
>>
>> Not to throw off the momentum, but could this even warrant a separate CEP
in some cases? For example, CEP-15 is a huge change, but the CQL syntax will
continuously evolve with more use. Being judicious in those changes is good
for end users. It's also a good reference to point back to after the fact.
>>
>>
>
>>
>> Patrick
>>
>>
>
>>
>> On Thu, Feb 2, 2023 at 6:01 AM Ekaterina Dimitrova
<[e.dimitrova@gmail.com](mailto:e.dimitrova@gmail.com)> wrote:
>
>>
>>> “ Only that it locks out of the conversation anyone without a Jira login”
>>>
>>> Very valid point I forgot about - since recently people need invitation in
order to create account…
>>>
>>> Then I would say C until we clarify the scope. Thanks
>>>
>>>
>
>>>
>>> On Thu, 2 Feb 2023 at 8:54, Benedict
<[benedict@apache.org](mailto:benedict@apache.org)> wrote:
>
>>>
>>>> I think lazy consensus is fine for all of these things. If a DISCUSS
thread is crickets, or just positive responses, then definitely it can proceed
without further ceremony.
>>>>
>>>>
>
>>>>
>>>> I think “with heads-up to the mailing list” is very close to B? Only that
it locks out of the conversation anyone without a Jira login.
>>>>
>>>>
>
>>>>
>>>>> On 2 Feb 2023, at 13:46, Ekaterina Dimitrova
<[e.dimitrova@gmail.com](mailto:e.dimitrova@gmail.com)> wrote:
>
>
>>>>
>>>>>
>>>>
>>>>> While I do agree with you, I am thinking that if we include many things
that we would expect lazy consensus on I would probably have different
preference.
>>>>>
>>>>>
>
>>>>>
>>>>> I definitely don’t mean to stall this though so in that case:
>>>>>
>>>>> I’d say combination of A+C (jira with heads up on the ML if someone is
interested into the jira) and regular log on API changes separate from
CHANGES.txt or we can just add labels to entries in CHANGES.txt as some other
projects. (I guess this is a detail we can agree on later on, how to implement
it, if we decide to move into that direction)
>>>>>
>>>>>
>
>>>>>
>>>>> On Thu, 2 Feb 2023 at 8:12, Benedict
<[benedict@apache.org](mailto:benedict@apache.org)> wrote:
>
>>>>>
>>>>>> I think it’s fine to separate the systems from the policy? We are
agreeing a policy for systems we want to make guarantees about to our users
(regarding maintenance and compatibility)
>>>>>>
>>>>>>
>
>>>>>>
>>>>>> For me, this is (at minimum) CQL and virtual tables. But I don’t think
the policy differs based on the contents of the list, and given how long this
topic stalled for. Given the primary point of contention seems to be the
*policy* and not the list, I think it’s time to express our opinions
numerically so we can move the conversation forwards.
>>>>>>
>>>>>>
>
>>>>>>
>>>>>> This isn’t binding, it just reifies the community sentiment.
>>>>>>
>>>>>>
>
>>>>>>
>>>>>>> On 2 Feb 2023, at 13:02, Ekaterina Dimitrova
<[e.dimitrova@gmail.com](mailto:e.dimitrova@gmail.com)> wrote:
>
>
>>>>>>
>>>>>>>
>>>>>>
>>>>>>> “ So we can close out this discussion, let’s assume we’re only
discussing any interfaces we want to make promises for. We can have a separate
discussion about which those are if there is any disagreement.”
>>>>>>>
>>>>>>> May I suggest we first clear this topic and then move to voting? I
would say I see confusion, not that much of a disagreement. Should we raise a
discussion for every feature flag for example? In another thread virtual
tables were brought in. I saw also other examples where people expressed
uncertainty. I personally feel I’ll be able to take a more informed decision
and vote if I first see this clarified.
>>>>>>>
>>>>>>>
>
>>>>>>>
>>>>>>> I will be happy to put down a document and bring it for discussion if
people agree with that
>>>>>>>
>>>>>>>
>
>>>>>>>
>>>>>>>
>
>>>>>>>
>>>>>>>
>
>>>>>>>
>>>>>>> On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko
<[aleksey@apple.com](mailto:aleksey@apple.com)> wrote:
>
>>>>>>>
>>>>>>>> Bringing light to new proposed APIs no less important - if not more,
for reasons already mentioned in this thread. For it’s not easy to change them
later.
>>>>>>>>
>>>>>>>>
>
>>>>>>>>
>>>>>>>> Voting B.
>>>>>>>>
>>>>>>>>
>
>>>>>>>>
>>>>>>>>
>
>>>>>>>>
>>>>>>>>> On 2 Feb 2023, at 10:15, Andrés de la Peña
<[adelapena@apache.org](mailto:adelapena@apache.org)> wrote:
>>>>>>>>>
>>>>>>>>>
>
>>>>>>>>>
>>>>>>>>> If it's a breaking change, like removing a method or property, I
think we would need a DISCUSS API thread prior to making changes. However, if
the change is an addition, like adding a new yaml property or a JMX method, I
think JIRA suffices.
>>>>>>>>
>>>>>>>>
>
>
>
>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Josh McKenzie <jm...@apache.org>.
> if a patch adds, say, a single JMX method to expose the
> metric, having an ML thread for it may seem redundant
My fear is someone missing that there's an idiom or pattern within the codebase for metrics they miss then we end up with inconsistent metric names / groups exposed to users.
Especially if we move forward with a "vtable + jmx metric" scaffolding we add things on. I think it's worth the tax of a quick email to the dev list to prevent our users from getting further buried as API's continue to evolve and gain complexity.
On Thu, Feb 2, 2023, at 11:03 AM, Maxim Muzafarov wrote:
> Hello everyone,
>
>
> I would say that having a CEP and a well-defined set of major public
> API changes is a must, and the corresponding discussion of CEP is also
> well-defined here [1]. This ensures that we do not miss any important
> changes. Everything related to the public API is also described in the
> CEP template [2].
>
> However, if a patch adds, say, a single JMX method to expose the
> metric, having an ML thread for it may seem redundant, and may shift
> the focus away from the really important issues on the dev list. In
> this case, I think we can add to the JIRA issue the `public API
> changed` label and mention all these issues on a weekly or monthly
> basis in a Cassandra status update e-mail. This will help keep the
> balance between important changes and routine.
>
>
> [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201#CassandraEnhancementProposals(CEP)-TheProcess
> [2] https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-Template#CEPTemplate-NeworChangedPublicInterfaces
>
> On Thu, 2 Feb 2023 at 16:56, Jeremiah D Jordan
> <je...@gmail.com> wrote:
> >
> > I think we need a DISCUSS thread at minimum for API changes. And for anything changing CQL syntax, I think a CEP is warranted. Even if it is only a small change to the syntax.
> >
> > On Feb 2, 2023, at 9:32 AM, Patrick McFadin <pm...@gmail.com> wrote:
> >
> > API changes are near and dear to my world. The scope of changes could be minor or major, so I think B is the right way forward.
> >
> > Not to throw off the momentum, but could this even warrant a separate CEP in some cases? For example, CEP-15 is a huge change, but the CQL syntax will continuously evolve with more use. Being judicious in those changes is good for end users. It's also a good reference to point back to after the fact.
> >
> > Patrick
> >
> > On Thu, Feb 2, 2023 at 6:01 AM Ekaterina Dimitrova <e....@gmail.com> wrote:
> >>
> >> “ Only that it locks out of the conversation anyone without a Jira login”
> >> Very valid point I forgot about - since recently people need invitation in order to create account…
> >> Then I would say C until we clarify the scope. Thanks
> >>
> >> On Thu, 2 Feb 2023 at 8:54, Benedict <be...@apache.org> wrote:
> >>>
> >>> I think lazy consensus is fine for all of these things. If a DISCUSS thread is crickets, or just positive responses, then definitely it can proceed without further ceremony.
> >>>
> >>> I think “with heads-up to the mailing list” is very close to B? Only that it locks out of the conversation anyone without a Jira login.
> >>>
> >>> On 2 Feb 2023, at 13:46, Ekaterina Dimitrova <e....@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>> While I do agree with you, I am thinking that if we include many things that we would expect lazy consensus on I would probably have different preference.
> >>>
> >>> I definitely don’t mean to stall this though so in that case:
> >>> I’d say combination of A+C (jira with heads up on the ML if someone is interested into the jira) and regular log on API changes separate from CHANGES.txt or we can just add labels to entries in CHANGES.txt as some other projects. (I guess this is a detail we can agree on later on, how to implement it, if we decide to move into that direction)
> >>>
> >>> On Thu, 2 Feb 2023 at 8:12, Benedict <be...@apache.org> wrote:
> >>>>
> >>>> I think it’s fine to separate the systems from the policy? We are agreeing a policy for systems we want to make guarantees about to our users (regarding maintenance and compatibility)
> >>>>
> >>>> For me, this is (at minimum) CQL and virtual tables. But I don’t think the policy differs based on the contents of the list, and given how long this topic stalled for. Given the primary point of contention seems to be the *policy* and not the list, I think it’s time to express our opinions numerically so we can move the conversation forwards.
> >>>>
> >>>> This isn’t binding, it just reifies the community sentiment.
> >>>>
> >>>> On 2 Feb 2023, at 13:02, Ekaterina Dimitrova <e....@gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> “ So we can close out this discussion, let’s assume we’re only discussing any interfaces we want to make promises for. We can have a separate discussion about which those are if there is any disagreement.”
> >>>> May I suggest we first clear this topic and then move to voting? I would say I see confusion, not that much of a disagreement. Should we raise a discussion for every feature flag for example? In another thread virtual tables were brought in. I saw also other examples where people expressed uncertainty. I personally feel I’ll be able to take a more informed decision and vote if I first see this clarified.
> >>>>
> >>>> I will be happy to put down a document and bring it for discussion if people agree with that
> >>>>
> >>>>
> >>>>
> >>>> On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko <al...@apple.com> wrote:
> >>>>>
> >>>>> Bringing light to new proposed APIs no less important - if not more, for reasons already mentioned in this thread. For it’s not easy to change them later.
> >>>>>
> >>>>> Voting B.
> >>>>>
> >>>>>
> >>>>> On 2 Feb 2023, at 10:15, Andrés de la Peña <ad...@apache.org> wrote:
> >>>>>
> >>>>> If it's a breaking change, like removing a method or property, I think we would need a DISCUSS API thread prior to making changes. However, if the change is an addition, like adding a new yaml property or a JMX method, I think JIRA suffices.
> >>>>>
> >>>>>
> >
>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Maxim Muzafarov <mm...@apache.org>.
Hello everyone,
I would say that having a CEP and a well-defined set of major public
API changes is a must, and the corresponding discussion of CEP is also
well-defined here [1]. This ensures that we do not miss any important
changes. Everything related to the public API is also described in the
CEP template [2].
However, if a patch adds, say, a single JMX method to expose the
metric, having an ML thread for it may seem redundant, and may shift
the focus away from the really important issues on the dev list. In
this case, I think we can add to the JIRA issue the `public API
changed` label and mention all these issues on a weekly or monthly
basis in a Cassandra status update e-mail. This will help keep the
balance between important changes and routine.
[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201#CassandraEnhancementProposals(CEP)-TheProcess
[2] https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-Template#CEPTemplate-NeworChangedPublicInterfaces
On Thu, 2 Feb 2023 at 16:56, Jeremiah D Jordan
<je...@gmail.com> wrote:
>
> I think we need a DISCUSS thread at minimum for API changes. And for anything changing CQL syntax, I think a CEP is warranted. Even if it is only a small change to the syntax.
>
> On Feb 2, 2023, at 9:32 AM, Patrick McFadin <pm...@gmail.com> wrote:
>
> API changes are near and dear to my world. The scope of changes could be minor or major, so I think B is the right way forward.
>
> Not to throw off the momentum, but could this even warrant a separate CEP in some cases? For example, CEP-15 is a huge change, but the CQL syntax will continuously evolve with more use. Being judicious in those changes is good for end users. It's also a good reference to point back to after the fact.
>
> Patrick
>
> On Thu, Feb 2, 2023 at 6:01 AM Ekaterina Dimitrova <e....@gmail.com> wrote:
>>
>> “ Only that it locks out of the conversation anyone without a Jira login”
>> Very valid point I forgot about - since recently people need invitation in order to create account…
>> Then I would say C until we clarify the scope. Thanks
>>
>> On Thu, 2 Feb 2023 at 8:54, Benedict <be...@apache.org> wrote:
>>>
>>> I think lazy consensus is fine for all of these things. If a DISCUSS thread is crickets, or just positive responses, then definitely it can proceed without further ceremony.
>>>
>>> I think “with heads-up to the mailing list” is very close to B? Only that it locks out of the conversation anyone without a Jira login.
>>>
>>> On 2 Feb 2023, at 13:46, Ekaterina Dimitrova <e....@gmail.com> wrote:
>>>
>>>
>>>
>>> While I do agree with you, I am thinking that if we include many things that we would expect lazy consensus on I would probably have different preference.
>>>
>>> I definitely don’t mean to stall this though so in that case:
>>> I’d say combination of A+C (jira with heads up on the ML if someone is interested into the jira) and regular log on API changes separate from CHANGES.txt or we can just add labels to entries in CHANGES.txt as some other projects. (I guess this is a detail we can agree on later on, how to implement it, if we decide to move into that direction)
>>>
>>> On Thu, 2 Feb 2023 at 8:12, Benedict <be...@apache.org> wrote:
>>>>
>>>> I think it’s fine to separate the systems from the policy? We are agreeing a policy for systems we want to make guarantees about to our users (regarding maintenance and compatibility)
>>>>
>>>> For me, this is (at minimum) CQL and virtual tables. But I don’t think the policy differs based on the contents of the list, and given how long this topic stalled for. Given the primary point of contention seems to be the *policy* and not the list, I think it’s time to express our opinions numerically so we can move the conversation forwards.
>>>>
>>>> This isn’t binding, it just reifies the community sentiment.
>>>>
>>>> On 2 Feb 2023, at 13:02, Ekaterina Dimitrova <e....@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> “ So we can close out this discussion, let’s assume we’re only discussing any interfaces we want to make promises for. We can have a separate discussion about which those are if there is any disagreement.”
>>>> May I suggest we first clear this topic and then move to voting? I would say I see confusion, not that much of a disagreement. Should we raise a discussion for every feature flag for example? In another thread virtual tables were brought in. I saw also other examples where people expressed uncertainty. I personally feel I’ll be able to take a more informed decision and vote if I first see this clarified.
>>>>
>>>> I will be happy to put down a document and bring it for discussion if people agree with that
>>>>
>>>>
>>>>
>>>> On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko <al...@apple.com> wrote:
>>>>>
>>>>> Bringing light to new proposed APIs no less important - if not more, for reasons already mentioned in this thread. For it’s not easy to change them later.
>>>>>
>>>>> Voting B.
>>>>>
>>>>>
>>>>> On 2 Feb 2023, at 10:15, Andrés de la Peña <ad...@apache.org> wrote:
>>>>>
>>>>> If it's a breaking change, like removing a method or property, I think we would need a DISCUSS API thread prior to making changes. However, if the change is an addition, like adding a new yaml property or a JMX method, I think JIRA suffices.
>>>>>
>>>>>
>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Jeremiah D Jordan <je...@gmail.com>.
I think we need a DISCUSS thread at minimum for API changes. And for anything changing CQL syntax, I think a CEP is warranted. Even if it is only a small change to the syntax.
> On Feb 2, 2023, at 9:32 AM, Patrick McFadin <pm...@gmail.com> wrote:
>
> API changes are near and dear to my world. The scope of changes could be minor or major, so I think B is the right way forward.
>
> Not to throw off the momentum, but could this even warrant a separate CEP in some cases? For example, CEP-15 is a huge change, but the CQL syntax will continuously evolve with more use. Being judicious in those changes is good for end users. It's also a good reference to point back to after the fact.
>
> Patrick
>
> On Thu, Feb 2, 2023 at 6:01 AM Ekaterina Dimitrova <e.dimitrova@gmail.com <ma...@gmail.com>> wrote:
>> “ Only that it locks out of the conversation anyone without a Jira login”
>> Very valid point I forgot about - since recently people need invitation in order to create account…
>> Then I would say C until we clarify the scope. Thanks
>>
>> On Thu, 2 Feb 2023 at 8:54, Benedict <benedict@apache.org <ma...@apache.org>> wrote:
>>> I think lazy consensus is fine for all of these things. If a DISCUSS thread is crickets, or just positive responses, then definitely it can proceed without further ceremony.
>>>
>>> I think “with heads-up to the mailing list” is very close to B? Only that it locks out of the conversation anyone without a Jira login.
>>>
>>>> On 2 Feb 2023, at 13:46, Ekaterina Dimitrova <e.dimitrova@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>>
>>>
>>>> While I do agree with you, I am thinking that if we include many things that we would expect lazy consensus on I would probably have different preference.
>>>>
>>>> I definitely don’t mean to stall this though so in that case:
>>>> I’d say combination of A+C (jira with heads up on the ML if someone is interested into the jira) and regular log on API changes separate from CHANGES.txt or we can just add labels to entries in CHANGES.txt as some other projects. (I guess this is a detail we can agree on later on, how to implement it, if we decide to move into that direction)
>>>>
>>>> On Thu, 2 Feb 2023 at 8:12, Benedict <benedict@apache.org <ma...@apache.org>> wrote:
>>>>> I think it’s fine to separate the systems from the policy? We are agreeing a policy for systems we want to make guarantees about to our users (regarding maintenance and compatibility)
>>>>>
>>>>> For me, this is (at minimum) CQL and virtual tables. But I don’t think the policy differs based on the contents of the list, and given how long this topic stalled for. Given the primary point of contention seems to be the *policy* and not the list, I think it’s time to express our opinions numerically so we can move the conversation forwards.
>>>>>
>>>>> This isn’t binding, it just reifies the community sentiment.
>>>>>
>>>>>> On 2 Feb 2023, at 13:02, Ekaterina Dimitrova <e.dimitrova@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>>
>>>>>
>>>>>> “ So we can close out this discussion, let’s assume we’re only discussing any interfaces we want to make promises for. We can have a separate discussion about which those are if there is any disagreement.”
>>>>>> May I suggest we first clear this topic and then move to voting? I would say I see confusion, not that much of a disagreement. Should we raise a discussion for every feature flag for example? In another thread virtual tables were brought in. I saw also other examples where people expressed uncertainty. I personally feel I’ll be able to take a more informed decision and vote if I first see this clarified.
>>>>>>
>>>>>> I will be happy to put down a document and bring it for discussion if people agree with that
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko <aleksey@apple.com <ma...@apple.com>> wrote:
>>>>>>> Bringing light to new proposed APIs no less important - if not more, for reasons already mentioned in this thread. For it’s not easy to change them later.
>>>>>>>
>>>>>>> Voting B.
>>>>>>>
>>>>>>>
>>>>>>>> On 2 Feb 2023, at 10:15, Andrés de la Peña <adelapena@apache.org <ma...@apache.org>> wrote:
>>>>>>>>
>>>>>>>> If it's a breaking change, like removing a method or property, I think we would need a DISCUSS API thread prior to making changes. However, if the change is an addition, like adding a new yaml property or a JMX method, I think JIRA suffices.
>>>>>>>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Patrick McFadin <pm...@gmail.com>.
API changes are near and dear to my world. The scope of changes could be
minor or major, so I think B is the right way forward.
Not to throw off the momentum, but could this even warrant a separate CEP
in some cases? For example, CEP-15 is a huge change, but the CQL syntax
will continuously evolve with more use. Being judicious in those changes is
good for end users. It's also a good reference to point back to after the
fact.
Patrick
On Thu, Feb 2, 2023 at 6:01 AM Ekaterina Dimitrova <e....@gmail.com>
wrote:
> “ Only that it locks out of the conversation anyone without a Jira login”
> Very valid point I forgot about - since recently people need invitation in
> order to create account…
> Then I would say C until we clarify the scope. Thanks
>
> On Thu, 2 Feb 2023 at 8:54, Benedict <be...@apache.org> wrote:
>
>> I think lazy consensus is fine for all of these things. If a DISCUSS
>> thread is crickets, or just positive responses, then definitely it can
>> proceed without further ceremony.
>>
>> I think “with heads-up to the mailing list” is very close to B? Only that
>> it locks out of the conversation anyone without a Jira login.
>>
>> On 2 Feb 2023, at 13:46, Ekaterina Dimitrova <e....@gmail.com>
>> wrote:
>>
>>
>>
>> While I do agree with you, I am thinking that if we include many things
>> that we would expect lazy consensus on I would probably have different
>> preference.
>>
>> I definitely don’t mean to stall this though so in that case:
>> I’d say combination of A+C (jira with heads up on the ML if someone is
>> interested into the jira) and regular log on API changes separate from
>> CHANGES.txt or we can just add labels to entries in CHANGES.txt as some
>> other projects. (I guess this is a detail we can agree on later on, how to
>> implement it, if we decide to move into that direction)
>>
>> On Thu, 2 Feb 2023 at 8:12, Benedict <be...@apache.org> wrote:
>>
>>> I think it’s fine to separate the systems from the policy? We are
>>> agreeing a policy for systems we want to make guarantees about to our users
>>> (regarding maintenance and compatibility)
>>>
>>> For me, this is (at minimum) CQL and virtual tables. But I don’t think
>>> the policy differs based on the contents of the list, and given how long
>>> this topic stalled for. Given the primary point of contention seems to be
>>> the *policy* and not the list, I think it’s time to express our opinions
>>> numerically so we can move the conversation forwards.
>>>
>>> This isn’t binding, it just reifies the community sentiment.
>>>
>>> On 2 Feb 2023, at 13:02, Ekaterina Dimitrova <e....@gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> “ So we can close out this discussion, let’s assume we’re only
>>> discussing any interfaces we want to make promises for. We can have a
>>> separate discussion about which those are if there is any disagreement.”
>>> May I suggest we first clear this topic and then move to voting? I would
>>> say I see confusion, not that much of a disagreement. Should we raise a
>>> discussion for every feature flag for example? In another thread virtual
>>> tables were brought in. I saw also other examples where people expressed
>>> uncertainty. I personally feel I’ll be able to take a more informed
>>> decision and vote if I first see this clarified.
>>>
>>> I will be happy to put down a document and bring it for discussion if
>>> people agree with that
>>>
>>>
>>>
>>> On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko <al...@apple.com>
>>> wrote:
>>>
>>>> Bringing light to new proposed APIs no less important - if not more,
>>>> for reasons already mentioned in this thread. For it’s not easy to change
>>>> them later.
>>>>
>>>> Voting B.
>>>>
>>>>
>>>> On 2 Feb 2023, at 10:15, Andrés de la Peña <ad...@apache.org>
>>>> wrote:
>>>>
>>>> If it's a breaking change, like removing a method or property, I think
>>>> we would need a DISCUSS API thread prior to making changes. However, if the
>>>> change is an addition, like adding a new yaml property or a JMX method, I
>>>> think JIRA suffices.
>>>>
>>>>
>>>>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Josh McKenzie <jm...@apache.org>.
Things I think of as API's:
1. nodetool output (user tooling couples with this)
2. CQL syntax
3. JMX
4. VTables
5. Potential future refactored and deliberately exposed API interfaces (SSTables, custom indexes, etc)
API's persist; I don't think lazy consensus to favor velocity is the right tradeoff for them given their weight. They're effectively one-way doors.
I vote B.
On Thu, Feb 2, 2023, at 9:01 AM, Ekaterina Dimitrova wrote:
> “ Only that it locks out of the conversation anyone without a Jira login”
> Very valid point I forgot about - since recently people need invitation in order to create account…
> Then I would say C until we clarify the scope. Thanks
>
> On Thu, 2 Feb 2023 at 8:54, Benedict <be...@apache.org> wrote:
>>
>> I think lazy consensus is fine for all of these things. If a DISCUSS thread is crickets, or just positive responses, then definitely it can proceed without further ceremony.
>>
>> I think “with heads-up to the mailing list” is very close to B? Only that it locks out of the conversation anyone without a Jira login.
>>
>>
>>> On 2 Feb 2023, at 13:46, Ekaterina Dimitrova <e....@gmail.com> wrote:
>>>
>>> While I do agree with you, I am thinking that if we include many things that we would expect lazy consensus on I would probably have different preference.
>>>
>>> I definitely don’t mean to stall this though so in that case:
>>> I’d say combination of A+C (jira with heads up on the ML if someone is interested into the jira) and regular log on API changes separate from CHANGES.txt or we can just add labels to entries in CHANGES.txt as some other projects. (I guess this is a detail we can agree on later on, how to implement it, if we decide to move into that direction)
>>>
>>> On Thu, 2 Feb 2023 at 8:12, Benedict <be...@apache.org> wrote:
>>>>
>>>> I think it’s fine to separate the systems from the policy? We are agreeing a policy for systems we want to make guarantees about to our users (regarding maintenance and compatibility)
>>>>
>>>> For me, this is (at minimum) CQL and virtual tables. But I don’t think the policy differs based on the contents of the list, and given how long this topic stalled for. Given the primary point of contention seems to be the *policy* and not the list, I think it’s time to express our opinions numerically so we can move the conversation forwards.
>>>>
>>>> This isn’t binding, it just reifies the community sentiment.
>>>>
>>>>
>>>>> On 2 Feb 2023, at 13:02, Ekaterina Dimitrova <e....@gmail.com> wrote:
>>>>>
>>>>> “ So we can close out this discussion, let’s assume we’re only discussing any interfaces we want to make promises for. We can have a separate discussion about which those are if there is any disagreement.”
>>>>> May I suggest we first clear this topic and then move to voting? I would say I see confusion, not that much of a disagreement. Should we raise a discussion for every feature flag for example? In another thread virtual tables were brought in. I saw also other examples where people expressed uncertainty. I personally feel I’ll be able to take a more informed decision and vote if I first see this clarified.
>>>>>
>>>>> I will be happy to put down a document and bring it for discussion if people agree with that
>>>>>
>>>>>
>>>>>
>>>>> On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko <al...@apple.com> wrote:
>>>>>> Bringing light to new proposed APIs no less important - if not more, for reasons already mentioned in this thread. For it’s not easy to change them later.
>>>>>>
>>>>>> Voting B.
>>>>>>
>>>>>>
>>>>>>> On 2 Feb 2023, at 10:15, Andrés de la Peña <ad...@apache.org> wrote:
>>>>>>>
>>>>>>> If it's a breaking change, like removing a method or property, I think we would need a DISCUSS API thread prior to making changes. However, if the change is an addition, like adding a new yaml property or a JMX method, I think JIRA suffices.
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Ekaterina Dimitrova <e....@gmail.com>.
“ Only that it locks out of the conversation anyone without a Jira login”
Very valid point I forgot about - since recently people need invitation in
order to create account…
Then I would say C until we clarify the scope. Thanks
On Thu, 2 Feb 2023 at 8:54, Benedict <be...@apache.org> wrote:
> I think lazy consensus is fine for all of these things. If a DISCUSS
> thread is crickets, or just positive responses, then definitely it can
> proceed without further ceremony.
>
> I think “with heads-up to the mailing list” is very close to B? Only that
> it locks out of the conversation anyone without a Jira login.
>
> On 2 Feb 2023, at 13:46, Ekaterina Dimitrova <e....@gmail.com>
> wrote:
>
>
>
> While I do agree with you, I am thinking that if we include many things
> that we would expect lazy consensus on I would probably have different
> preference.
>
> I definitely don’t mean to stall this though so in that case:
> I’d say combination of A+C (jira with heads up on the ML if someone is
> interested into the jira) and regular log on API changes separate from
> CHANGES.txt or we can just add labels to entries in CHANGES.txt as some
> other projects. (I guess this is a detail we can agree on later on, how to
> implement it, if we decide to move into that direction)
>
> On Thu, 2 Feb 2023 at 8:12, Benedict <be...@apache.org> wrote:
>
>> I think it’s fine to separate the systems from the policy? We are
>> agreeing a policy for systems we want to make guarantees about to our users
>> (regarding maintenance and compatibility)
>>
>> For me, this is (at minimum) CQL and virtual tables. But I don’t think
>> the policy differs based on the contents of the list, and given how long
>> this topic stalled for. Given the primary point of contention seems to be
>> the *policy* and not the list, I think it’s time to express our opinions
>> numerically so we can move the conversation forwards.
>>
>> This isn’t binding, it just reifies the community sentiment.
>>
>> On 2 Feb 2023, at 13:02, Ekaterina Dimitrova <e....@gmail.com>
>> wrote:
>>
>>
>>
>> “ So we can close out this discussion, let’s assume we’re only
>> discussing any interfaces we want to make promises for. We can have a
>> separate discussion about which those are if there is any disagreement.”
>> May I suggest we first clear this topic and then move to voting? I would
>> say I see confusion, not that much of a disagreement. Should we raise a
>> discussion for every feature flag for example? In another thread virtual
>> tables were brought in. I saw also other examples where people expressed
>> uncertainty. I personally feel I’ll be able to take a more informed
>> decision and vote if I first see this clarified.
>>
>> I will be happy to put down a document and bring it for discussion if
>> people agree with that
>>
>>
>>
>> On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko <al...@apple.com> wrote:
>>
>>> Bringing light to new proposed APIs no less important - if not more, for
>>> reasons already mentioned in this thread. For it’s not easy to change them
>>> later.
>>>
>>> Voting B.
>>>
>>>
>>> On 2 Feb 2023, at 10:15, Andrés de la Peña <ad...@apache.org> wrote:
>>>
>>> If it's a breaking change, like removing a method or property, I think
>>> we would need a DISCUSS API thread prior to making changes. However, if the
>>> change is an addition, like adding a new yaml property or a JMX method, I
>>> think JIRA suffices.
>>>
>>>
>>>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Benedict <be...@apache.org>.
I think lazy consensus is fine for all of these things. If a DISCUSS thread is
crickets, or just positive responses, then definitely it can proceed without
further ceremony.
I think “with heads-up to the mailing list” is very close to B? Only that it
locks out of the conversation anyone without a Jira login.
> On 2 Feb 2023, at 13:46, Ekaterina Dimitrova <e....@gmail.com> wrote:
>
>
>
>
> While I do agree with you, I am thinking that if we include many things that
> we would expect lazy consensus on I would probably have different
> preference.
>
>
>
>
> I definitely don’t mean to stall this though so in that case:
>
> I’d say combination of A+C (jira with heads up on the ML if someone is
> interested into the jira) and regular log on API changes separate from
> CHANGES.txt or we can just add labels to entries in CHANGES.txt as some
> other projects. (I guess this is a detail we can agree on later on, how to
> implement it, if we decide to move into that direction)
>
>
>
>
> On Thu, 2 Feb 2023 at 8:12, Benedict
> <[benedict@apache.org](mailto:benedict@apache.org)> wrote:
>
>
>> I think it’s fine to separate the systems from the policy? We are agreeing
a policy for systems we want to make guarantees about to our users (regarding
maintenance and compatibility)
>>
>>
>
>>
>> For me, this is (at minimum) CQL and virtual tables. But I don’t think the
policy differs based on the contents of the list, and given how long this
topic stalled for. Given the primary point of contention seems to be the
*policy* and not the list, I think it’s time to express our opinions
numerically so we can move the conversation forwards.
>>
>>
>
>>
>> This isn’t binding, it just reifies the community sentiment.
>>
>>
>
>>
>>> On 2 Feb 2023, at 13:02, Ekaterina Dimitrova
<[e.dimitrova@gmail.com](mailto:e.dimitrova@gmail.com)> wrote:
>
>
>>
>>>
>>
>>> “ So we can close out this discussion, let’s assume we’re only discussing
any interfaces we want to make promises for. We can have a separate discussion
about which those are if there is any disagreement.”
>>>
>>> May I suggest we first clear this topic and then move to voting? I would
say I see confusion, not that much of a disagreement. Should we raise a
discussion for every feature flag for example? In another thread virtual
tables were brought in. I saw also other examples where people expressed
uncertainty. I personally feel I’ll be able to take a more informed decision
and vote if I first see this clarified.
>>>
>>>
>
>>>
>>> I will be happy to put down a document and bring it for discussion if
people agree with that
>>>
>>>
>
>>>
>>>
>
>>>
>>>
>
>>>
>>> On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko
<[aleksey@apple.com](mailto:aleksey@apple.com)> wrote:
>
>>>
>>>> Bringing light to new proposed APIs no less important - if not more, for
reasons already mentioned in this thread. For it’s not easy to change them
later.
>>>>
>>>>
>
>>>>
>>>> Voting B.
>>>>
>>>>
>
>>>>
>>>>
>
>>>>
>>>>> On 2 Feb 2023, at 10:15, Andrés de la Peña
<[adelapena@apache.org](mailto:adelapena@apache.org)> wrote:
>>>>>
>>>>>
>
>>>>>
>>>>> If it's a breaking change, like removing a method or property, I think
we would need a DISCUSS API thread prior to making changes. However, if the
change is an addition, like adding a new yaml property or a JMX method, I
think JIRA suffices.
>>>>
>>>>
>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Ekaterina Dimitrova <e....@gmail.com>.
While I do agree with you, I am thinking that if we include many things
that we would expect lazy consensus on I would probably have different
preference.
I definitely don’t mean to stall this though so in that case:
I’d say combination of A+C (jira with heads up on the ML if someone is
interested into the jira) and regular log on API changes separate from
CHANGES.txt or we can just add labels to entries in CHANGES.txt as some
other projects. (I guess this is a detail we can agree on later on, how to
implement it, if we decide to move into that direction)
On Thu, 2 Feb 2023 at 8:12, Benedict <be...@apache.org> wrote:
> I think it’s fine to separate the systems from the policy? We are agreeing
> a policy for systems we want to make guarantees about to our users
> (regarding maintenance and compatibility)
>
> For me, this is (at minimum) CQL and virtual tables. But I don’t think the
> policy differs based on the contents of the list, and given how long this
> topic stalled for. Given the primary point of contention seems to be the
> *policy* and not the list, I think it’s time to express our opinions
> numerically so we can move the conversation forwards.
>
> This isn’t binding, it just reifies the community sentiment.
>
> On 2 Feb 2023, at 13:02, Ekaterina Dimitrova <e....@gmail.com>
> wrote:
>
>
>
> “ So we can close out this discussion, let’s assume we’re only discussing
> any interfaces we want to make promises for. We can have a separate
> discussion about which those are if there is any disagreement.”
> May I suggest we first clear this topic and then move to voting? I would
> say I see confusion, not that much of a disagreement. Should we raise a
> discussion for every feature flag for example? In another thread virtual
> tables were brought in. I saw also other examples where people expressed
> uncertainty. I personally feel I’ll be able to take a more informed
> decision and vote if I first see this clarified.
>
> I will be happy to put down a document and bring it for discussion if
> people agree with that
>
>
>
> On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko <al...@apple.com> wrote:
>
>> Bringing light to new proposed APIs no less important - if not more, for
>> reasons already mentioned in this thread. For it’s not easy to change them
>> later.
>>
>> Voting B.
>>
>>
>> On 2 Feb 2023, at 10:15, Andrés de la Peña <ad...@apache.org> wrote:
>>
>> If it's a breaking change, like removing a method or property, I think we
>> would need a DISCUSS API thread prior to making changes. However, if the
>> change is an addition, like adding a new yaml property or a JMX method, I
>> think JIRA suffices.
>>
>>
>>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Benedict <be...@apache.org>.
I think it’s fine to separate the systems from the policy? We are agreeing a
policy for systems we want to make guarantees about to our users (regarding
maintenance and compatibility)
For me, this is (at minimum) CQL and virtual tables. But I don’t think the
policy differs based on the contents of the list, and given how long this
topic stalled for. Given the primary point of contention seems to be the
*policy* and not the list, I think it’s time to express our opinions
numerically so we can move the conversation forwards.
This isn’t binding, it just reifies the community sentiment.
> On 2 Feb 2023, at 13:02, Ekaterina Dimitrova <e....@gmail.com> wrote:
>
>
>
>
> “ So we can close out this discussion, let’s assume we’re only discussing
> any interfaces we want to make promises for. We can have a separate
> discussion about which those are if there is any disagreement.”
>
> May I suggest we first clear this topic and then move to voting? I would say
> I see confusion, not that much of a disagreement. Should we raise a
> discussion for every feature flag for example? In another thread virtual
> tables were brought in. I saw also other examples where people expressed
> uncertainty. I personally feel I’ll be able to take a more informed decision
> and vote if I first see this clarified.
>
>
>
>
> I will be happy to put down a document and bring it for discussion if people
> agree with that
>
>
>
>
>
>
>
>
>
>
> On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko
> <[aleksey@apple.com](mailto:aleksey@apple.com)> wrote:
>
>
>> Bringing light to new proposed APIs no less important - if not more, for
reasons already mentioned in this thread. For it’s not easy to change them
later.
>>
>>
>
>>
>> Voting B.
>>
>>
>
>>
>>
>
>>
>>> On 2 Feb 2023, at 10:15, Andrés de la Peña
<[adelapena@apache.org](mailto:adelapena@apache.org)> wrote:
>>>
>>>
>
>>>
>>> If it's a breaking change, like removing a method or property, I think we
would need a DISCUSS API thread prior to making changes. However, if the
change is an addition, like adding a new yaml property or a JMX method, I
think JIRA suffices.
>>
>>
>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Ekaterina Dimitrova <e....@gmail.com>.
“ So we can close out this discussion, let’s assume we’re only discussing
any interfaces we want to make promises for. We can have a separate
discussion about which those are if there is any disagreement.”
May I suggest we first clear this topic and then move to voting? I would
say I see confusion, not that much of a disagreement. Should we raise a
discussion for every feature flag for example? In another thread virtual
tables were brought in. I saw also other examples where people expressed
uncertainty. I personally feel I’ll be able to take a more informed
decision and vote if I first see this clarified.
I will be happy to put down a document and bring it for discussion if
people agree with that
On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko <al...@apple.com> wrote:
> Bringing light to new proposed APIs no less important - if not more, for
> reasons already mentioned in this thread. For it’s not easy to change them
> later.
>
> Voting B.
>
>
> On 2 Feb 2023, at 10:15, Andrés de la Peña <ad...@apache.org> wrote:
>
> If it's a breaking change, like removing a method or property, I think we
> would need a DISCUSS API thread prior to making changes. However, if the
> change is an addition, like adding a new yaml property or a JMX method, I
> think JIRA suffices.
>
>
>
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Aleksey Yeshchenko <al...@apple.com>.
Bringing light to new proposed APIs no less important - if not more, for reasons already mentioned in this thread. For it’s not easy to change them later.
Voting B.
> On 2 Feb 2023, at 10:15, Andrés de la Peña <ad...@apache.org> wrote:
>
> If it's a breaking change, like removing a method or property, I think we would need a DISCUSS API thread prior to making changes. However, if the change is an addition, like adding a new yaml property or a JMX method, I think JIRA suffices.
Re: [DISCUSS] API modifications and when to raise a thread on the dev ML
Posted by Andrés de la Peña <ad...@apache.org>.
I guess that depends on the type of change, and what we consider an API.
If it's a breaking change, like removing a method or property, I think we
would need a DISCUSS API thread prior to making changes. However, if the
change is an addition, like adding a new yaml property or a JMX method, I
think JIRA suffices.
As for what we consider a public API, we usually include extensible
interfaces on this. For example, we can agree that the Index interface for
secondary indexes is a public API. However, that interface exposes many
other interfaces and classes through its methods. For example, that Index
interface exposes ColumnFamillyStore, SSTableReader, ColumnMetadata,
AbstractType, PartitionUpdate, etc. Changes into those indirectly exposed
classes can easily break custom index implementations out there. Should we
consider them public APIs too, and require a DISCUSS thread for every
change on them? Should that include new methods that wouldn't break
compatibility?
On Thu, 2 Feb 2023 at 09:29, Benedict Elliott Smith <be...@apache.org>
wrote:
> Closing the loop on seeking consensus for UX/UI/API changes, I see a few
> options. Can we rank choice vote please?
>
> A - Jira suffices
> B - Post a DISCUSS API thread prior to making changes
> C - Periodically publish a list of API changes for retrospective
> consideration by the community
>
> Points raised in the discussion included: lowering the bar for
> participation and avoiding unnecessary burden to developers.
>
> I vote B (only) because I think broader participation is most important
> for these topics.
>
>
> On 7 Dec 2022, at 15:43, Mick Semb Wever <mc...@apache.org> wrote:
>
> I think it makes sense to look into improving visibility of API changes,
>> so people can more easily review a summary of API changes versus reading
>> through the whole changelog (perhaps we need a summarized API change log?).
>>
>
>
> Agree Paulo.
>
> Observers should be able to see all API changes early. We can do better
> than telling downstream users/devs "you have to listen to all jira tickets"
> or "you have to watch the code and pick up changes". Watching CHANGES.txt
> or NEWS.txt or CEPs doesn't solve the need either.
>
> Observing such changes as early as possible can save a significant amount
> of effort and headache later on, and should be encouraged. If done
> correctly I can imagine it will help welcome more contributors.
>
> I can also see that we can improve at, and have a better shared
> understanding of, categorising the types of API changes:
> addition/change/deprecation/removal, signature/output/behavioural, API/SPI.
> So I can see value here for both observers and for ourselves.
>
>
>