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 <pmcfa...@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.dimitr...@gmail.com > <mailto:e.dimitr...@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 <bened...@apache.org >> <mailto: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 >>>> <mailto: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 >>>> <mailto: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 >>>>>> <mailto: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 >>>>>> <mailto: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 >>>>>>>> <mailto: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. >>>>>>>
