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 <bened...@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.dimitr...@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 <bened...@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.dimitr...@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 <alek...@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 <adelap...@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.
