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