Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Benedict Elliott Smith]

Closing the loop on seeking consensus for UX/UI/API changes, I see a few 
options. Can we rank choice vote please?

A - Jira suffices
B - Post a DISCUSS API thread prior to making changes
C - Periodically publish a list of API changes for retrospective consideration 
by the community

Points raised in the discussion included: lowering the bar for participation 
and avoiding unnecessary burden to developers.

I vote B (only) because I think broader participation is most important for 
these topics.


> On 7 Dec 2022, at 15:43, Mick Semb Wever  wrote:
> 
>> I think it makes sense to look into improving visibility of API changes, so 
>> people can more easily review a summary of API changes versus reading 
>> through the whole changelog (perhaps we need a summarized API change log?).
> 
> 
> Agree Paulo.
> 
> Observers should be able to see all API changes early. We can do better than 
> telling downstream users/devs "you have to listen to all jira tickets" or 
> "you have to watch the code and pick up changes". Watching CHANGES.txt or 
> NEWS.txt or CEPs doesn't solve the need either. 
> 
> Observing such changes as early as possible can save a significant amount of 
> effort and headache later on, and should be encouraged. If done correctly I 
> can imagine it will help welcome more contributors.
> 
> I can also see that we can improve at, and have a better shared understanding 
> of, categorising the types of API changes: 
> addition/change/deprecation/removal, signature/output/behavioural, API/SPI. 
> So I can see value here for both observers and for ourselves.
> 

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Benedict]

If we expose internal mechanics to public APIs, we should probably document what our promises are - ie none, even between patch versions.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.On 2 Feb 2023, at 10:16, Andrés de la Peña  wrote:I guess that depends on the type of change, and what we consider an API.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.As for what we consider a public API, we usually include extensible interfaces on this. For example, we can agree that the Index interface for secondary indexes is a public API. However, that interface exposes many other interfaces and classes through its methods. For example, that Index interface exposes ColumnFamillyStore, SSTableReader, ColumnMetadata, AbstractType, PartitionUpdate, etc. Changes into those indirectly exposed classes can easily break custom index implementations out there. Should we consider them public APIs too, and require a DISCUSS thread for every change on them? Should that include new methods that wouldn't break compatibility?On Thu, 2 Feb 2023 at 09:29, Benedict Elliott Smith  wrote:Closing the loop on seeking consensus for UX/UI/API changes, I see a few options. Can we rank choice vote please?A - Jira sufficesB - Post a DISCUSS API thread prior to making changesC - Periodically publish a list of API changes for retrospective consideration by the communityPoints raised in the discussion included: lowering the bar for participation and avoiding unnecessary burden to developers.I vote B (only) because I think broader participation is most important for these topics.On 7 Dec 2022, at 15:43, Mick Semb Wever  wrote:I think it makes sense to look into improving visibility of API changes, so people can more easily review a summary of API changes versus reading through the whole changelog (perhaps we need a summarized API change log?).Agree Paulo.Observers should be able to see all API changes early. We can do better than telling downstream users/devs "you have to listen to all jira tickets" or "you have to watch the code and pick up changes". Watching CHANGES.txt or NEWS.txt or CEPs doesn't solve the need either. Observing such changes as early as possible can save a significant amount of effort and headache later on, and should be encouraged. If done correctly I can imagine it will help welcome more contributors.I can also see that we can improve at, and have a better shared understanding of, categorising the types of API changes: addition/change/deprecation/removal, signature/output/behavioural, API/SPI. So I can see value here for both observers and for ourselves.

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Andrés de la Peña]

I guess that depends on the type of change, and what we consider an API.

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.

As for what we consider a public API, we usually include extensible
interfaces on this. For example, we can agree that the Index interface for
secondary indexes is a public API. However, that interface exposes many
other interfaces and classes through its methods. For example, that Index
interface exposes ColumnFamillyStore, SSTableReader, ColumnMetadata,
AbstractType, PartitionUpdate, etc. Changes into those indirectly exposed
classes can easily break custom index implementations out there. Should we
consider them public APIs too, and require a DISCUSS thread for every
change on them? Should that include new methods that wouldn't break
compatibility?

On Thu, 2 Feb 2023 at 09:29, Benedict Elliott Smith 
wrote:

> Closing the loop on seeking consensus for UX/UI/API changes, I see a few
> options. Can we rank choice vote please?
>
> A - Jira suffices
> B - Post a DISCUSS API thread prior to making changes
> C - Periodically publish a list of API changes for retrospective
> consideration by the community
>
> Points raised in the discussion included: lowering the bar for
> participation and avoiding unnecessary burden to developers.
>
> I vote B (only) because I think broader participation is most important
> for these topics.
>
>
> On 7 Dec 2022, at 15:43, Mick Semb Wever  wrote:
>
> I think it makes sense to look into improving visibility of API changes,
>> so people can more easily review a summary of API changes versus reading
>> through the whole changelog (perhaps we need a summarized API change log?).
>>
>
>
> Agree Paulo.
>
> Observers should be able to see all API changes early. We can do better
> than telling downstream users/devs "you have to listen to all jira tickets"
> or "you have to watch the code and pick up changes". Watching CHANGES.txt
> or NEWS.txt or CEPs doesn't solve the need either.
>
> Observing such changes as early as possible can save a significant amount
> of effort and headache later on, and should be encouraged. If done
> correctly I can imagine it will help welcome more contributors.
>
> I can also see that we can improve at, and have a better shared
> understanding of, categorising the types of API changes:
> addition/change/deprecation/removal, signature/output/behavioural, API/SPI.
> So I can see value here for both observers and for ourselves.
>
>
>

Re: Apache Cassandra 5.0 documentation

[Berenguer Blasi]

I did check it when it was originally posted, I had no major concerns :-)

On 2/2/23 7:14, Mick Semb Wever wrote:


No objections from me! And yes, 7 days have passed and no one has 
spoken up, you're a committer – you can assume silence is consent.


Folks, Lorina's proposal here is very thorough, and it will 
re-organise the docs significantly. Make sure to check it out quickly 
if you think you might have any concerns or objections!



On Thu, 2 Feb 2023 at 05:08, Lorina Poland  wrote:

I've not had any comment on this topic. Can I assume that no one
has objections?

Lorina

On 2023/01/25 19:02:41 Lorina Poland wrote:
> Greetings!
>
> I'm gearing up to help get the Cassandra 5.0 docs in good order
before the
> GA release occurs later this year. Recently, I've been thinking
about a
> more standardized organization to docs, to make it simpler for
users to
> find what they are looking for, separate from searching. [That's
the kind
> of thing docs nerds think about.] To that end, I've created a
unified
> information architecture (IA) that can apply to any kind of
documentation,
> including the Apache C* docs.
>
> Up front, I'll say, not every section of this organization
applies to
> Apache C* docs, but reorganizing the docs to follow this pattern
as much as
> possible will help users find what they need.
>
> I'd like your input into this IA that I've outlined. Please give me
> feedback about your opinions! If I can tackle this issue before
launching
> into adding CEP features, working down the existing JIRA tickets for
> documentation, and backfilling missing items, it would be immensely
> helpful. No opinion will go unaddressed, so please take a few
minutes to
> take a look.
>
> I'm linking a google doc, to make it easy for anyone to make
comments:
>

https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing
>
> I'm also drafting an Apache C* 5.0 Doc Plan for the work, to
make it simple
> for anyone to know what is being done, and will share that next. In
> addition, I've started consolidating the current Documentation
tickets that
> are open under the JIRA project, component "Documentation".
>
> Thanks,
> Lorina Poland
>

Re: Cassandra 5.0 Documentation Plan

[Benedict]

This looks good to me, thanks Lorina

> On 1 Feb 2023, at 19:24, Lorina Poland  wrote:
> 
> 
> Hey all -
> 
> I presented a potential Docs Information Architecture recently, and promised 
> a Doc Plan for the upcoming C* 5.0 release. Please give me feedback, 
> especially if you feel that the priorities for upcoming features should be 
> different than what I propose. Also understand that the priority is just to 
> make absolutely certain that the most impactful features are covered at GA. 
> Eventually, and hopefully also before GA, all the items listed in the Doc 
> Plan will be completed. Just depends on the effort devoted by the community, 
> myself included.
> 
> Here's the link: 
> https://docs.google.com/document/d/1FAACcAxtV9qLJS05RLt85S_6Gb4C4t4g9DhmfLufjOk/edit?usp=sharing
> 
> Happy reading!
> 
> Lorina
> 

Re: Apache Cassandra 5.0 documentation

[Ekaterina Dimitrova]

I also looked at it and I do not have any objections.
I also think lazy consensus can be assumed:

https://community.apache.org/committers/lazyConsensus.html

On Thu, 2 Feb 2023 at 3:44, Berenguer Blasi 
wrote:

> I did check it when it was originally posted, I had no major concerns :-)
> On 2/2/23 7:14, Mick Semb Wever wrote:
>
>
> No objections from me! And yes, 7 days have passed and no one has spoken
> up, you're a committer – you can assume silence is consent.
>
> Folks, Lorina's proposal here is very thorough, and it will re-organise
> the docs significantly. Make sure to check it out quickly if you think you
> might have any concerns or objections!
>
>
> On Thu, 2 Feb 2023 at 05:08, Lorina Poland  wrote:
>
>> I've not had any comment on this topic. Can I assume that no one has
>> objections?
>>
>> Lorina
>>
>> On 2023/01/25 19:02:41 Lorina Poland wrote:
>> > Greetings!
>> >
>> > I'm gearing up to help get the Cassandra 5.0 docs in good order before
>> the
>> > GA release occurs later this year. Recently, I've been thinking about a
>> > more standardized organization to docs, to make it simpler for users to
>> > find what they are looking for, separate from searching. [That's the
>> kind
>> > of thing docs nerds think about.] To that end, I've created a unified
>> > information architecture (IA) that can apply to any kind of
>> documentation,
>> > including the Apache C* docs.
>> >
>> > Up front, I'll say, not every section of this organization applies to
>> > Apache C* docs, but reorganizing the docs to follow this pattern as
>> much as
>> > possible will help users find what they need.
>> >
>> > I'd like your input into this IA that I've outlined. Please give me
>> > feedback about your opinions! If I can tackle this issue before
>> launching
>> > into adding CEP features, working down the existing JIRA tickets for
>> > documentation, and backfilling missing items, it would be immensely
>> > helpful. No opinion will go unaddressed, so please take a few minutes to
>> > take a look.
>> >
>> > I'm linking a google doc, to make it easy for anyone to make comments:
>> >
>> https://docs.google.com/document/d/1A96K73vj9MbJoD7wJNgIKWrOkLq-ZL2cNZAEXSWrciY/edit?usp=sharing
>> >
>> > I'm also drafting an Apache C* 5.0 Doc Plan for the work, to make it
>> simple
>> > for anyone to know what is being done, and will share that next. In
>> > addition, I've started consolidating the current Documentation tickets
>> that
>> > are open under the JIRA project, component "Documentation".
>> >
>> > Thanks,
>> > Lorina Poland
>> >
>>
>

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Ekaterina Dimitrova]

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

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Benedict]

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  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 thatOn Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko  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  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.

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Ekaterina Dimitrova]

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

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Aleksey Yeshchenko]

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

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Benedict]

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  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  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  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 thatOn Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko  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  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.

Re: Cassandra 5.0 Documentation Plan

[Ekaterina Dimitrova]

I second Benedict, thanks Lorina

On Thu, 2 Feb 2023 at 7:54, Benedict  wrote:

> This looks good to me, thanks Lorina
>
> On 1 Feb 2023, at 19:24, Lorina Poland  wrote:
>
> 
>
> Hey all -
>
> I presented a potential Docs Information Architecture recently, and
> promised a Doc Plan for the upcoming C* 5.0 release. Please give me
> feedback, especially if you feel that the priorities for upcoming features
> should be different than what I propose. Also understand that the priority
> is just to make absolutely certain that the most impactful features are
> covered at GA. Eventually, and hopefully also before GA, all the items
> listed in the Doc Plan will be completed. Just depends on the effort
> devoted by the community, myself included.
>
> Here's the link:
>
> https://docs.google.com/document/d/1FAACcAxtV9qLJS05RLt85S_6Gb4C4t4g9DhmfLufjOk/edit?usp=sharing
>
> Happy reading!
>
> Lorina
>
>

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Ekaterina Dimitrova]

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

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Josh McKenzie]

Things I think of as API's:
1. nodetool output (user tooling couples with this)
2. CQL syntax
3. JMX
4. VTables
5. Potential future refactored and deliberately exposed API interfaces 
(SSTables, custom indexes, etc)

API's persist; I don't think lazy consensus to favor velocity is the right 
tradeoff for them given their weight. They're effectively one-way doors.

I vote B.

On Thu, Feb 2, 2023, at 9:01 AM, Ekaterina Dimitrova 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  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  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  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  
> 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  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  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.

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Benedict]

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  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  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. PatrickOn Thu, Feb 2, 2023 at 6:01 AM Ekaterina Dimitrova  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. ThanksOn Thu, 2 Feb 2023 at 8:54, Benedict  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  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  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  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 thatOn Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko  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  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.

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Patrick McFadin]

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

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Josh McKenzie]

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

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Jeremiah D Jordan]

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

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

[Maxim Muzafarov]

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

Re: Welcome Patrick McFadin as Cassandra Committer

[Brandon Williams]

Congratulations, Patrick!

Kind Regards,
Brandon

On Thu, Feb 2, 2023 at 11:58 AM Benjamin Lerer  wrote:
>
> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
>
> Thanks a lot, Patrick, for everything you have done for this project and its 
> community through the years.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members

Re: Welcome Patrick McFadin as Cassandra Committer

[Aaron Ploetz]

Patrick FTW!!!

On Thu, Feb 2, 2023 at 12:32 PM Joseph Lynch  wrote:

> W! Congratulations Patrick!!
>
> -Joey
>
> On Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer  wrote:
>
>> The PMC members are pleased to announce that Patrick McFadin has accepted
>> the invitation to become committer today.
>>
>> Thanks a lot, Patrick, for everything you have done for this project and
>> its community through the years.
>>
>> Congratulations and welcome!
>>
>> The Apache Cassandra PMC members
>>
>

Re: Welcome Patrick McFadin as Cassandra Committer

[J. D. Jordan]

Congrats!On Feb 2, 2023, at 12:47 PM, Christopher Bradford  wrote:Congrats Patrick! Well done. On Thu, Feb 2, 2023 at 10:44 AM Aaron Ploetz  wrote:Patrick FTW!!!On Thu, Feb 2, 2023 at 12:32 PM Joseph Lynch  wrote:W! Congratulations Patrick!!-JoeyOn Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer  wrote:
The PMC members are pleased to announce that Patrick McFadin has accepted
the invitation to become committer today.

Thanks a lot, Patrick, for everything you have done for this project and its community through the years.

Congratulations and welcome!

The Apache Cassandra PMC members




-- Christopher Bradford

Re: Welcome Patrick McFadin as Cassandra Committer

[Francisco Guerrero]

Congrats, Patrick!

On 2023/02/02 19:52:35 Jean-Armel Luce wrote:
> Congrats, Patrick
> 
> Le jeu. 2 févr. 2023 à 20:46, David Capwell  a écrit :
> 
> > Congrats and welcome! =)
> >
> > On Feb 2, 2023, at 10:53 AM, J. D. Jordan 
> > wrote:
> >
> > Congrats!
> >
> > On Feb 2, 2023, at 12:47 PM, Christopher Bradford 
> > wrote:
> >
> > 
> > Congrats Patrick! Well done.
> >
> > On Thu, Feb 2, 2023 at 10:44 AM Aaron Ploetz 
> > wrote:
> >
> >> Patrick FTW!!!
> >>
> >> On Thu, Feb 2, 2023 at 12:32 PM Joseph Lynch 
> >> wrote:
> >>
> >>> W! Congratulations Patrick!!
> >>>
> >>> -Joey
> >>>
> >>> On Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer  wrote:
> >>>
>  The PMC members are pleased to announce that Patrick McFadin has
>  accepted
>  the invitation to become committer today.
> 
>  Thanks a lot, Patrick, for everything you have done for this project
>  and its community through the years.
> 
>  Congratulations and welcome!
> 
>  The Apache Cassandra PMC members
> 
> >>> --
> >
> > Christopher Bradford
> >
> >
> >
> 

Re: Welcome Patrick McFadin as Cassandra Committer

[Dinesh Joshi]

Congratulations Patrick!

> 
> On Feb 2, 2023, at 9:58 AM, Benjamin Lerer  wrote:
> 
> 
> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
> 
> Thanks a lot, Patrick, for everything you have done for this project and its 
> community through the years.
> 
> Congratulations and welcome!
> 
> The Apache Cassandra PMC members

Re: Welcome Patrick McFadin as Cassandra Committer

[Derek Chen-Becker]

Congrats!

On Thu, Feb 2, 2023 at 10:58 AM Benjamin Lerer  wrote:

> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
>
> Thanks a lot, Patrick, for everything you have done for this project and
> its community through the years.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members
>


-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Welcome Patrick McFadin as Cassandra Committer

[Benjamin Lerer]

 The PMC members are pleased to announce that Patrick McFadin has accepted
the invitation to become committer today.

Thanks a lot, Patrick, for everything you have done for this project and
its community through the years.

Congratulations and welcome!

The Apache Cassandra PMC members

Re: Welcome Patrick McFadin as Cassandra Committer

[Melissa Logan]

Congrats, Patrick!

On Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer  wrote:

> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
>
> Thanks a lot, Patrick, for everything you have done for this project and
> its community through the years.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members
>


-- 
Melissa Logan (she/her)
CEO & Founder, Constantia.io
LinkedIn  | Twitter

Re: Welcome Patrick McFadin as Cassandra Committer

[Cheng Wang via dev]

Congrats, Patrick!!

Cheng

On Thu, Feb 2, 2023 at 10:24 AM Jordan West  wrote:

> Congratulations Patrick! Well deserved.
>
> Jordan
>
> On Thu, Feb 2, 2023 at 10:18 Brandon Williams  wrote:
>
>> Congratulations, Patrick!
>>
>> Kind Regards,
>> Brandon
>>
>> On Thu, Feb 2, 2023 at 11:58 AM Benjamin Lerer  wrote:
>> >
>> > The PMC members are pleased to announce that Patrick McFadin has
>> accepted
>> > the invitation to become committer today.
>> >
>> > Thanks a lot, Patrick, for everything you have done for this project
>> and its community through the years.
>> >
>> > Congratulations and welcome!
>> >
>> > The Apache Cassandra PMC members
>>
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Joseph Lynch]

W! Congratulations Patrick!!

-Joey

On Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer  wrote:

> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
>
> Thanks a lot, Patrick, for everything you have done for this project and
> its community through the years.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Jean-Armel Luce]

Congrats, Patrick

Le jeu. 2 févr. 2023 à 20:46, David Capwell  a écrit :

> Congrats and welcome! =)
>
> On Feb 2, 2023, at 10:53 AM, J. D. Jordan 
> wrote:
>
> Congrats!
>
> On Feb 2, 2023, at 12:47 PM, Christopher Bradford 
> wrote:
>
> 
> Congrats Patrick! Well done.
>
> On Thu, Feb 2, 2023 at 10:44 AM Aaron Ploetz 
> wrote:
>
>> Patrick FTW!!!
>>
>> On Thu, Feb 2, 2023 at 12:32 PM Joseph Lynch 
>> wrote:
>>
>>> W! Congratulations Patrick!!
>>>
>>> -Joey
>>>
>>> On Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer  wrote:
>>>
 The PMC members are pleased to announce that Patrick McFadin has
 accepted
 the invitation to become committer today.

 Thanks a lot, Patrick, for everything you have done for this project
 and its community through the years.

 Congratulations and welcome!

 The Apache Cassandra PMC members

>>> --
>
> Christopher Bradford
>
>
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Miklosovic, Stefan]

Wow Patrick, this is great!


From: Benjamin Lerer 
Sent: Thursday, February 2, 2023 18:58
To: dev@cassandra.apache.org
Subject: Welcome Patrick McFadin as Cassandra Committer

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



The PMC members are pleased to announce that Patrick McFadin has accepted
the invitation to become committer today.

Thanks a lot, Patrick, for everything you have done for this project and its 
community through the years.

Congratulations and welcome!

The Apache Cassandra PMC members

Re: Welcome Patrick McFadin as Cassandra Committer

[Sharan F]

Congratulations Patrick!

Thanks
Sharan

On Thu, 2 Feb 2023, 18:58 Benjamin Lerer,  wrote:

> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
>
> Thanks a lot, Patrick, for everything you have done for this project and
> its community through the years.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Christopher Bradford]

Congrats Patrick! Well done.

On Thu, Feb 2, 2023 at 10:44 AM Aaron Ploetz  wrote:

> Patrick FTW!!!
>
> On Thu, Feb 2, 2023 at 12:32 PM Joseph Lynch 
> wrote:
>
>> W! Congratulations Patrick!!
>>
>> -Joey
>>
>> On Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer  wrote:
>>
>>> The PMC members are pleased to announce that Patrick McFadin has accepted
>>> the invitation to become committer today.
>>>
>>> Thanks a lot, Patrick, for everything you have done for this project and
>>> its community through the years.
>>>
>>> Congratulations and welcome!
>>>
>>> The Apache Cassandra PMC members
>>>
>> --

Christopher Bradford

Re: Welcome Patrick McFadin as Cassandra Committer

[Ekaterina Dimitrova]

Congrats Patrick 

On Thu, 2 Feb 2023 at 12:58, Benjamin Lerer  wrote:

> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
>
> Thanks a lot, Patrick, for everything you have done for this project and
> its community through the years.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Jacek Lewandowski]

Congrats !!!

- - -- --- -  -
Jacek Lewandowski


czw., 2 lut 2023 o 19:10 Melissa Logan  napisał(a):

> Congrats, Patrick!
>
> On Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer  wrote:
>
>> The PMC members are pleased to announce that Patrick McFadin has accepted
>> the invitation to become committer today.
>>
>> Thanks a lot, Patrick, for everything you have done for this project and
>> its community through the years.
>>
>> Congratulations and welcome!
>>
>> The Apache Cassandra PMC members
>>
>
>
> --
> Melissa Logan (she/her)
> CEO & Founder, Constantia.io
> LinkedIn  | Twitter
> 
>
>
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Jordan West]

Congratulations Patrick! Well deserved.

Jordan

On Thu, Feb 2, 2023 at 10:18 Brandon Williams  wrote:

> Congratulations, Patrick!
>
> Kind Regards,
> Brandon
>
> On Thu, Feb 2, 2023 at 11:58 AM Benjamin Lerer  wrote:
> >
> > The PMC members are pleased to announce that Patrick McFadin has accepted
> > the invitation to become committer today.
> >
> > Thanks a lot, Patrick, for everything you have done for this project and
> its community through the years.
> >
> > Congratulations and welcome!
> >
> > The Apache Cassandra PMC members
>

Re: Welcome Patrick McFadin as Cassandra Committer

[David Capwell]

Congrats and welcome! =)

> On Feb 2, 2023, at 10:53 AM, J. D. Jordan  wrote:
> 
> Congrats!
> 
>> On Feb 2, 2023, at 12:47 PM, Christopher Bradford  
>> wrote:
>> 
>> 
>> Congrats Patrick! Well done. 
>> 
>> On Thu, Feb 2, 2023 at 10:44 AM Aaron Ploetz > > wrote:
>>> Patrick FTW!!!
>>> 
>>> On Thu, Feb 2, 2023 at 12:32 PM Joseph Lynch >> > wrote:
 W! Congratulations Patrick!!
 
 -Joey
 
 On Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer >>> > wrote:
> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
> 
> Thanks a lot, Patrick, for everything you have done for this project and 
> its community through the years.
> 
> Congratulations and welcome!
> 
> The Apache Cassandra PMC members
>> -- 
>> 
>> Christopher Bradford
>> 

Re: Welcome Patrick McFadin as Cassandra Committer

[Andrés de la Peña]

Congratulations, Patrick!

On Thu, 2 Feb 2023 at 19:54, Francisco Guerrero  wrote:

> Congrats, Patrick!
>
> On 2023/02/02 19:52:35 Jean-Armel Luce wrote:
> > Congrats, Patrick
> >
> > Le jeu. 2 févr. 2023 à 20:46, David Capwell  a
> écrit :
> >
> > > Congrats and welcome! =)
> > >
> > > On Feb 2, 2023, at 10:53 AM, J. D. Jordan 
> > > wrote:
> > >
> > > Congrats!
> > >
> > > On Feb 2, 2023, at 12:47 PM, Christopher Bradford <
> bradfor...@gmail.com>
> > > wrote:
> > >
> > > 
> > > Congrats Patrick! Well done.
> > >
> > > On Thu, Feb 2, 2023 at 10:44 AM Aaron Ploetz 
> > > wrote:
> > >
> > >> Patrick FTW!!!
> > >>
> > >> On Thu, Feb 2, 2023 at 12:32 PM Joseph Lynch 
> > >> wrote:
> > >>
> > >>> W! Congratulations Patrick!!
> > >>>
> > >>> -Joey
> > >>>
> > >>> On Thu, Feb 2, 2023 at 9:58 AM Benjamin Lerer 
> wrote:
> > >>>
> >  The PMC members are pleased to announce that Patrick McFadin has
> >  accepted
> >  the invitation to become committer today.
> > 
> >  Thanks a lot, Patrick, for everything you have done for this project
> >  and its community through the years.
> > 
> >  Congratulations and welcome!
> > 
> >  The Apache Cassandra PMC members
> > 
> > >>> --
> > >
> > > Christopher Bradford
> > >
> > >
> > >
> >
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Lorina Poland]

Absolutely, a big woot for you, Patrick! Congratulations!

Lorina

On Thu, Feb 2, 2023 at 12:09 PM Sharan F  wrote:

> Congratulations Patrick!
>
> Thanks
> Sharan
>
> On Thu, 2 Feb 2023, 18:58 Benjamin Lerer,  wrote:
>
>> The PMC members are pleased to announce that Patrick McFadin has accepted
>> the invitation to become committer today.
>>
>> Thanks a lot, Patrick, for everything you have done for this project and
>> its community through the years.
>>
>> Congratulations and welcome!
>>
>> The Apache Cassandra PMC members
>>
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Henrik Ingo]

Congratulations Patrick.

I guess this is a good time to thank you for your mentorship as I have
learned about and worked with the Cassandra community for 2½ years now.

henrik

On Thu, Feb 2, 2023 at 7:58 PM Benjamin Lerer  wrote:

> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
>
> Thanks a lot, Patrick, for everything you have done for this project and
> its community through the years.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members
>


-- 

Henrik Ingo

c. +358 40 569 7354

w. www.datastax.com

  
  

Re: Welcome Patrick McFadin as Cassandra Committer

[Molly Monroy]

Congrats, Patrick... much deserved!

On Thu, Feb 2, 2023 at 1:59 PM Derek Chen-Becker 
wrote:

> Congrats!
>
> On Thu, Feb 2, 2023 at 10:58 AM Benjamin Lerer  wrote:
>
>> The PMC members are pleased to announce that Patrick McFadin has accepted
>> the invitation to become committer today.
>>
>> Thanks a lot, Patrick, for everything you have done for this project and
>> its community through the years.
>>
>> Congratulations and welcome!
>>
>> The Apache Cassandra PMC members
>>
>
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>
>

Re: Welcome Patrick McFadin as Cassandra Committer

[Josh McKenzie]

Congrats Patrick! Well deserved.

On Thu, Feb 2, 2023, at 5:25 PM, Molly Monroy wrote:
> Congrats, Patrick... much deserved!
> 
> On Thu, Feb 2, 2023 at 1:59 PM Derek Chen-Becker  
> wrote:
>> Congrats!
>> 
>> On Thu, Feb 2, 2023 at 10:58 AM Benjamin Lerer  wrote:
>>> The PMC members are pleased to announce that Patrick McFadin has accepted
>>> the invitation to become committer today.
>>> 
>>> Thanks a lot, Patrick, for everything you have done for this project and 
>>> its community through the years.
>>> 
>>> Congratulations and welcome!
>>> 
>>> The Apache Cassandra PMC members
>> 
>> 
>> --
>> +---+
>> | Derek Chen-Becker |
>> | GPG Key available at https://keybase.io/dchenbecker and   |
>> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
>> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
>> +---+
>> 

Re: Welcome Patrick McFadin as Cassandra Committer

[Berenguer Blasi]

Welcome!

On 3/2/23 4:09, Vinay Chella wrote:

Well deserved one, Congratulations, Patrick.

On Fri, Feb 3, 2023 at 4:01 AM Josh McKenzie  wrote:

Congrats Patrick! Well deserved.

On Thu, Feb 2, 2023, at 5:25 PM, Molly Monroy wrote:

Congrats, Patrick... much deserved!

On Thu, Feb 2, 2023 at 1:59 PM Derek Chen-Becker
 wrote:

Congrats!

On Thu, Feb 2, 2023 at 10:58 AM Benjamin Lerer
 wrote:

The PMC members are pleased to announce that Patrick
McFadin has accepted
the invitation to become committer today.

Thanks a lot, Patrick, for everything you have done for
this project and its community through the years.

Congratulations and welcome!

The Apache Cassandra PMC members



--
+---+
| Derek Chen-Becker                      |
| GPG Key available at https://keybase.io/dchenbeckerand       |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+



--

Thanks,
Vinay Chella

Re: Welcome Patrick McFadin as Cassandra Committer

[Vinay Chella]

Well deserved one, Congratulations, Patrick.

On Fri, Feb 3, 2023 at 4:01 AM Josh McKenzie  wrote:

> Congrats Patrick! Well deserved.
>
> On Thu, Feb 2, 2023, at 5:25 PM, Molly Monroy wrote:
>
> Congrats, Patrick... much deserved!
>
> On Thu, Feb 2, 2023 at 1:59 PM Derek Chen-Becker 
> wrote:
>
> Congrats!
>
> On Thu, Feb 2, 2023 at 10:58 AM Benjamin Lerer  wrote:
>
> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
>
> Thanks a lot, Patrick, for everything you have done for this project and
> its community through the years.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members
>
>
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> +---+
>
>
> --

Thanks,
Vinay Chella