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> 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. >>>> >>>> >>>>
