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 <jeremiah.jor...@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 <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> > 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. >>>>> >>>>> >
