Hi All,
I don't think we can be 100% prescriptive here. There will always be
gray areas on where API changes start or end. Even on what is an API
change and discussions about why a change was forgotten, not
communicated, etc. I think we should rely on people's judgement on when
to hit the ML/CEP when a significant change is about to come. Smaller
changes could be caught by a weekly git digest of changes to a set of
files, where any challenged commits should be easy to amend/revert
within the week of the commit. What 'significant change', 'small
change', etc means is left open to the criteria of the people involved
and with time we will all align and learn.
Also would it be correct to assume it will be way way cheaper to address
the seldom rare offenders than to CEP/ML every single change feeling the
weight of the process? Think also on process burden for newcomers and
the on boarding experience.
It doesn't 100% fit A, B or C but a bit from each.
On 2/2/23 17:54, Benedict wrote:
I’m inclined to agree with Jeremiah and Patrick, even if it might be a
steep jump from what we’ve been used to. CQL needs to be treated with
the utmost care and attention to detail. Would we apply the same
standard to semantic bug fixes too? Perhaps we should, where there
isn’t an urgent timeline at least.
Once the dust settles from this vote, depending how it tabulates, we
can see what topics like this we might need another round to nail down.
On 2 Feb 2023, at 15: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.
