Re: [DISCUSSION] Cassandra's code style and source code analysis

[Claude Warren, Jr via dev]

Turn it on at warning (or lower) level now, so people have some idea of the
size of change to their current code.

On Wed, Jan 25, 2023 at 12:05 PM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Thank you Maxim for doing this.
>
> It is nice to see this effort materialized in a PR.
>
> I would wait until bigger chunks of work are committed to trunk (like
> CEP-15) to not collide too much. I would say we can postpone doing this
> until the actual 5.0 release, last weeks before it so we would not clash
> with any work people would like to include in 5.0. This can go in anytime,
> basically.
>
> Are people on the same page?
>
> Regards
>
> 
> From: Maxim Muzafarov 
> Sent: Monday, January 23, 2023 19:46
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
>
> 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.
>
>
>
>
> Hello everyone,
>
> You can find the changes here:
> https://issues.apache.org/jira/browse/CASSANDRA-17925
>
> While preparing the code style configuration for the Eclipse IDE, I
> discovered that there was no easy way to have complex grouping options
> for the set of packages. So we need to add extra blank lines between
> each group of packages so that all the configurations for Eclipse,
> NetBeans, IntelliJ IDEA and checkstyle are aligned. I should have
> checked this earlier for sure, but I only did it for static imports
> and some groups, my bad. The resultant configuration looks like this:
>
> java.*
> [blank line]
> javax.*
> [blank line]
> com.*
> [blank line]
> net.*
> [blank line]
> org.*
> [blank line]
> org.apache.cassandra.*
> [blank line]
> all other imports
> [blank line]
> static all other imports
>
> The pull request is here:
> https://github.com/apache/cassandra/pull/2108
>
> The configuration-related changes are placed in a dedicated commit, so
> it should be easy to make a review:
>
> https://github.com/apache/cassandra/pull/2108/commits/84e292ddc9671a0be76ceb9304b2b9a051c2d52a
>
> 
>
> Another important thing to mention is that the total amount of changes
> for organising imports is really big (more than 2000 files!), so we
> need to decide the right time to merge this PR. Although rebasing or
> merging changes to development branches should become much easier
> ("Accept local" + "Organize imports"), we still need to pay extra
> attention here to minimise the impact on major patches for the next
> release.
>
> On Mon, 16 Jan 2023 at 13:16, Maxim Muzafarov  wrote:
> >
> > Stefan,
> >
> > Thank you for bringing this topic up. I'll prepare the PR shortly with
> > option 4, so everyone can take a look at the amount of changes. This
> > does not force us to go exactly this path, but it may shed light on
> > changes in general.
> >
> > What exactly we're planning to do in the PR:
> >
> > 1. Checkstyle AvoidStarImport rule, so no star imports will be allowed.
> > 2. Checkstyle ImportOrder rule, for controlling the order.
> > 3. The IDE code style configuration for Intellij IDEA, NetBeans, and
> > Eclipse (it doesn't exist for Eclipse yet).
> > 4. The import order according to option 4:
> >
> > ```
> > java.*
> > javax.*
> > [blank line]
> > com.*
> > net.*
> > org.*
> > [blank line]
> > org.apache.cassandra.*
> > [blank line]
> > all other imports
> > [blank line]
> > static all other imports
> > ```
> >
> >
> >
> > On Mon, 16 Jan 2023 at 12:39, Miklosovic, Stefan
> >  wrote:
> > >
> > > Based on the voting we should go with option 4?
> > >
> > > Two weeks passed without anybody joining so I guess folks are all
> happy with that or this just went unnoticed?
> > >
> > > Let's give it time until the end of this week (Friday 12:00 UTC).
> > >
> > > Regards
> > >
> > > 
> > > From: Maxim Muzafarov 
> > > Sent: Tuesday, January 3, 2023 14:31
> > > To: dev@cassandra.apache.org
> > > Subject: Re: [DISCUSSION] Cassandra's code style and source code
> analysis
> > >
> > > 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.
> > >
> > >
> > >
> > >
> > > Folks,
> > >
> > > Let me update the voting status and put together everything we have so
> > > far. We definitely need more votes to have a solid foundation for this
> > > change, so I encourage everyone to consider the options above and
> > > share them in this thread.
> > >
> > >
> > > Total for each applicable option:
> > >
> > > 4-th option -- 4 votes
> > > 3-rd option -- 3 votes
> > > 5-th option -- 1 vote
> > > 1-st option -- 0 votes
> > > 2-nd option -- 0 votes
> > >
> > > On Thu, 22 Dec 2022 at 22:06, Mick Semb Wever  wrote:
> > > >>
> > > >>
> > > >> 3. Total 5 groups, 2968 files to change
> > > >>
> > > >> ```
> > > >> org.apache.cassandra.*
> > > 

Re: [ANNOUNCE] Evolving governance in the Cassandra Ecosystem

[Josh McKenzie]

I'm told my email came through with a white background and gray font. Apologies 
for that; contortions between editors and trying to get my email client to 
format consistently after copy/paste led to some kind of pathologically bad 
case.

Also: you should be using a dark background on your browser to save your eyes. 
Part of why I didn't realize. :)

(It's on the internet so it must be true: 
https://www.wired.co.uk/article/dark-mode-chrome-android-ios-science)

~Josh

On Thu, Jan 26, 2023, at 6:57 PM, C. Scott Andreas wrote:
> Josh and all PMC members, thank you for your work on this!
> 
> Supportive of the changes and grateful to have scaffolding in place to 
> accommodate current/incoming subprojects.
> 
> – Scott
> 
>> On Jan 26, 2023, at 1:21 PM, Josh McKenzie  wrote:
>> 
>> 
>> The Cassandra PMC is pleased to announce that we're evolving our governance 
>> procedures to better foster subprojects under the Cassandra Ecosystem's 
>> umbrella. Astute observers among you may have noticed that the Cassandra 
>> Sidecar is already a subproject of Apache Cassandra as of CEP-1 
>> (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224) 
>> and Cassandra-14395 (https://issues.apache.org/jira/browse/CASSANDRASC-24), 
>> however up until now we haven't had any structure to accommodate raising 
>> committers on specific subprojects or clarity on the addition or governance 
>> of future subprojects.
>> 
>> Further, with the CEP for the driver donation in motion 
>> (https://docs.google.com/document/d/1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY/edit#heading=h.xhizycgqxoyo),
>>  the need for a structured and sustainable way to expand the Cassandra 
>> Ecosystem is pressing.
>> 
>> We'll document these changes in the confluence wiki as well as the sidecar 
>> as our first formal subproject after any discussion on this email thread. 
>> The new governance process is as follows:
>> -
>> 
>> Subproject Governance
>> 1. The Apache Cassandra PMC is responsible for governing the broad Cassandra 
>> Ecosystem.
>> 2. The PMC will vote on inclusion of new interested subprojects using the 
>> existing procedural change vote process documented in the confluence wiki 
>> (Super majority voting: 66% of votes must be in favor to pass. Requires 50% 
>> participation of roll call).
>> 3. New committers for these subprojects will be nominated and raised, both 
>> at inclusion as a subproject and over time. Nominations can be brought to 
>> priv...@cassandra.apache.org. Typically we're looking for a mix of 
>> commitment and contribution to the community and project, be it through 
>> code, documentation, presentations, or other significant engagement with the 
>> project. 
>> 4. While the commit-bit is ecosystem wide, code modification rights and 
>> voting rights (technical contribution, binding -1, CEP's) are granted per 
>> subproject
>>  4a. Individuals are trusted to exercise prudence and only commit or 
>> claim binding votes on approved subprojects. Repeated violations of this 
>> social contract will result in losing committer status.
>>  4b. Members of the PMC have commit and voting rights on all subprojects.
>> 5. For each subproject, the PMC will determine a trio of PMC members that 
>> will be responsible for all PMC specific functions (release votes, driving 
>> CVE response, marketing, branding, policing marks, etc) on the subproject.
>> -
>> 
>> Curious to see what thoughts we have as a community!
>> 
>> Thanks!
>> 
>> ~Josh
>> 
> 
> 

Re: Merging CEP-15 to trunk

[Henrik Ingo]

While the substance of the review discussion has moved to Jira, I wanted to
come back here to clarify one thing:

I've learned that when I have defended the need (or right, if appealing to
the Governance texts...) for contributors to be able to review a feature
branch at the time it is merged to trunk - which for Accord is now - that a
common reaction to this is that doing a review of Accord now might take
months and would stall the Accord project for months if that is allowed.

So I just wanted to clarify I don't think that sounds "reasonable", as the
word is used in the Governance wiki page. I agree that to engage in such
level of review, it would have needed to happen earlier. On the  other
hand, I can think of many things that a pair of fresh eyes can do at this
point in reasonable time, like days or a couple weeks.

I spent 6 hours this week glancing over the 28k lines of code that would be
added to C* codebase. I was able to form an opinion of the patch, have some
fruitful off-list conversations with several people, and as a by-product
apparently also caught some commented out code that possibly should be
enabled before the merge.

henrik

On Wed, Jan 25, 2023 at 5:06 PM Henrik Ingo 
wrote:

> Thanks Benedict
>
> For brevity I'll respond to your email, although indirectly this is also a
> continuation of my debate with Josh:
>
> At least on my scorecard, one issue was raised regarding the actual code:
> CASSANDRA-18193 Provide design and API documentation. Since the addition of
> code comments also significantly impacts the ability of an outsider to
> understand and review the code, I would then treat it as an unknown to say
> how much else such a fresh review would uncover.
>
> By the way I would say the discussion about git submodules (and all the
> other alternatives) in a broad sense was also a review'ish comment.
>
> That said, yes of course the expectation is that if the code has already
> been reviewed, and by rather experienced Cassandra developers too, there
> probably won't be many issues found, and there isn't a need for several
> weeks of line by line re-review.
>
> As for the rebase, I think that somehow started dominating this
> discussion, but in my view was never the only reason. For me this is
> primarily to satisfy points 4 and 5 in the project governance, that
> everyone has had an opportunity to review the code, for whatever reason
> they may wish to do so.
>
> I should say for those of us on the sidelines we certainly expected a
> rebase catching up 6 months and ~500 commits to have more substantial
> changes. Hearing that this is not the case is encouraging, as it also
> suggests the changes to Cassandra code are less invasive than maybe I and
> others had imagined.
>
> henrik
>
> On Wed, Jan 25, 2023 at 1:51 PM Benedict  wrote:
>
>> contributors who didn't actively work on Accord, have assumed that they
>> will be invited to review now
>>
>>
>> I may have missed it, but I have not seen anyone propose to substantively
>> review the actual *work*, only the impact of rebasing. Which, honestly,
>> there is plenty of time to do - the impact is essentially nil, and we
>> aren’t planning to merge immediately. I will only not agree to an adhoc
>> procedural change to prevent merge until this happens, as a matter of
>> principle.
>>
>> However, I am very sympathetic to a desire to participate *substantively*.
>> I think interested parties should have invested as the work progressed, but
>> I *don’t* think it is unreasonable to ask for a *some* time prior to
>> merge if this hasn’t happened.
>>
>> So, if you can adequately resource it, we can delay merging a while
>> longer. I *want* your (constructive) participation. But, I have not seen
>> anything to suggest this is even proposed, let alone realistic.
>>
>> There are currently five full time contributors participating in the
>> Accord project, with cumulatively several person-years of work already
>> accumulated. By the time even another month has passed, you will have
>> another five person-months of work to catch-up on. Resourcing even a review
>> effort to catch up with this is *non-trivial*, and for it to be a
>> reasonable ask, you must credibly be able to keep up while making useful
>> contributions.
>>
>> After all, if it had been ready to merge to trunk already a year ago, why
>> wasn't it?
>>
>>
>> The Cassandra integration has only existed since late last year, and was
>> not merged earlier to avoid interfering with the effort to release 4.1.
>>
>> One thing that I wanted to ask for is when you push to CI, you or whoever
>> does it, to approve all jobs.
>>
>>
>> Thanks Ekaterina, we will be sure to fully qualify the CI result, and I
>> will make sure we also run your flaky test runner on the newly introduced
>> tests.
>>
>>
>>
>>
>> On 24 Jan 2023, at 21:42, Henrik Ingo  wrote:
>>
>> 
>> Thanks Josh
>>
>> Since you mentioned the CEP process, I should also mention one sentiment
>> you omitted, but worth stating explicitly:
>

Re: [ANNOUNCE] Evolving governance in the Cassandra Ecosystem

[Francisco Guerrero]

Great news! I'm very happy to see these changes coming soon.

Thanks to everyone involved in this work.

On 2023/01/26 21:21:01 Josh McKenzie wrote:
> The Cassandra PMC is pleased to announce that we're evolving our governance 
> procedures to better foster subprojects under the Cassandra Ecosystem's 
> umbrella. Astute observers among you may have noticed that the Cassandra 
> Sidecar is already a subproject of Apache Cassandra as of CEP-1 
> (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224) 
> and Cassandra-14395 (https://issues.apache.org/jira/browse/CASSANDRASC-24), 
> however up until now we haven't had any structure to accommodate raising 
> committers on specific subprojects or clarity on the addition or governance 
> of future subprojects.
> 
> Further, with the CEP for the driver donation in motion 
> (https://docs.google.com/document/d/1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY/edit#heading=h.xhizycgqxoyo),
>  the need for a structured and sustainable way to expand the Cassandra 
> Ecosystem is pressing.
> 
> We'll document these changes in the confluence wiki as well as the sidecar as 
> our first formal subproject after any discussion on this email thread. The 
> new governance process is as follows:
> -
> 
> Subproject Governance
> 1. The Apache Cassandra PMC is responsible for governing the broad Cassandra 
> Ecosystem.
> 2. The PMC will vote on inclusion of new interested subprojects using the 
> existing procedural change vote process documented in the confluence wiki 
> (Super majority voting: 66% of votes must be in favor to pass. Requires 50% 
> participation of roll call).
> 3. New committers for these subprojects will be nominated and raised, both at 
> inclusion as a subproject and over time. Nominations can be brought to 
> priv...@cassandra.apache.org. Typically we're looking for a mix of commitment 
> and contribution to the community and project, be it through code, 
> documentation, presentations, or other significant engagement with the 
> project. 
> 4. While the commit-bit is ecosystem wide, code modification rights and 
> voting rights (technical contribution, binding -1, CEP's) are granted per 
> subproject
>  4a. Individuals are trusted to exercise prudence and only commit or 
> claim binding votes on approved subprojects. Repeated violations of this 
> social contract will result in losing committer status.
>  4b. Members of the PMC have commit and voting rights on all subprojects.
> 5. For each subproject, the PMC will determine a trio of PMC members that 
> will be responsible for all PMC specific functions (release votes, driving 
> CVE response, marketing, branding, policing marks, etc) on the subproject.
> -
> 
> Curious to see what thoughts we have as a community!
> 
> Thanks!
> 
> ~Josh
> 

Re: Merging CEP-15 to trunk

[David Capwell]

> I've learned that when I have defended the need (or right, if appealing to 
> the Governance texts...) for contributors to be able to review a feature 
> branch at the time it is merged to trunk - which for Accord is now - that a 
> common reaction to this is that doing a review of Accord now might take 
> months and would stall the Accord project for months if that is allowed.

The way I have been reading this thread is not that “we don’t want the review 
as it slows us down” but more “the process is X, why are you asking for Y?”.  I 
believe I can speak for everyone working on Accord, we all want more reviewers 
and contributors!

I think its fair to ask the question on if feature branches “should" have the 
same process as non-feature branches, but since that has not been called out 
and voted on they are expected to follow the same process; if people working on 
feature branches have not been following the same process that is currently an 
issue that needs to be addressed (In the case of Accord all contributors are 
Committers or PMC and same process has been followed as trunk).  The project 
doesn’t have a good history (at least recent history) of open development of 
features, most features are dumps from private sources, so there are 
learning/growing pains as we try to develop new features in the open.

> On the  other hand, I can think of many things that a pair of fresh eyes can 
> do at this point in reasonable time, like days or a couple weeks. 

I agree more eyes are better, but the conversation is on code that has already 
merged.  I know that many of us review code after it has been merged, and what 
we have been doing is filing follow up bugs/improvement requests as new work.  
A simple example of this was when the trie memtables patch landed I reviewed 
code that was merged I think 2021 making memtables pluggable; I found a bug in 
it, showed the bug existed, and worked with the authors to get all this 
addressed.  Reviews after the fact are fine, common, and welcome in this 
project, but that has always sponsored new tickets and new work to address the 
feedback.


> On Jan 27, 2023, at 7:39 AM, Henrik Ingo  wrote:
> 
> While the substance of the review discussion has moved to Jira, I wanted to 
> come back here to clarify one thing:
> 
> I've learned that when I have defended the need (or right, if appealing to 
> the Governance texts...) for contributors to be able to review a feature 
> branch at the time it is merged to trunk - which for Accord is now - that a 
> common reaction to this is that doing a review of Accord now might take 
> months and would stall the Accord project for months if that is allowed.
> 
> So I just wanted to clarify I don't think that sounds "reasonable", as the 
> word is used in the Governance wiki page. I agree that to engage in such 
> level of review, it would have needed to happen earlier. On the  other hand, 
> I can think of many things that a pair of fresh eyes can do at this point in 
> reasonable time, like days or a couple weeks. 
> 
> I spent 6 hours this week glancing over the 28k lines of code that would be 
> added to C* codebase. I was able to form an opinion of the patch, have some 
> fruitful off-list conversations with several people, and as a by-product 
> apparently also caught some commented out code that possibly should be 
> enabled before the merge.
> 
> henrik
> 
> On Wed, Jan 25, 2023 at 5:06 PM Henrik Ingo  > wrote:
> Thanks Benedict
> 
> For brevity I'll respond to your email, although indirectly this is also a 
> continuation of my debate with Josh:
> 
> At least on my scorecard, one issue was raised regarding the actual code: 
> CASSANDRA-18193 Provide design and API documentation. Since the addition of 
> code comments also significantly impacts the ability of an outsider to 
> understand and review the code, I would then treat it as an unknown to say 
> how much else such a fresh review would uncover.
> 
> By the way I would say the discussion about git submodules (and all the other 
> alternatives) in a broad sense was also a review'ish comment.
> 
> That said, yes of course the expectation is that if the code has already been 
> reviewed, and by rather experienced Cassandra developers too, there probably 
> won't be many issues found, and there isn't a need for several weeks of line 
> by line re-review.
> 
> As for the rebase, I think that somehow started dominating this discussion, 
> but in my view was never the only reason. For me this is primarily to satisfy 
> points 4 and 5 in the project governance, that everyone has had an 
> opportunity to review the code, for whatever reason they may wish to do so.
> 
> I should say for those of us on the sidelines we certainly expected a rebase 
> catching up 6 months and ~500 commits to have more substantial changes. 
> Hearing that this is not the case is encouraging, as it also suggests the 
> changes to Cassandra code are less invasive than

Re: Merging CEP-15 to trunk

[Josh McKenzie]

> I know that many of us review code after it has been merged, and what we have 
> been doing is filing follow up bugs/improvement requests as new work.
I think this is key. The code on the feature branch matches the same bar of 
quality / process that's on trunk, and it's trivially easy to checkout at the 
merge SHA and review the code in an IDE even after merge, raising questions 
with someone if you have concerns. If we were talking about merging this 
feature branch a week before a GA I could see why there'd be concern but we 
have a lot of calendar runway here.

I'd expect modifications post merge to trunk to have the same inertia 
for/against them as modifications on a feature branch that have cleared our 2 
committer bar for merge.

>  1. Code must not be committed if a committer has requested reasonable time 
> to conduct a review 
I'm realizing in retrospect this leaves ambiguity around *where* the code is 
committed (i.e. trunk vs. feature branch). On the one hand we could say this 
code has already been reviewed and committed; the feature branch had the same 
bar as trunk. On the other hand you could say the intent of this agreement was 
to allow committers to inspect code *before it goes to trunk*, which would 
present a different set of constraints.

My perspective is that of the former; I consider this code "already committed". 
This work was done on a formal feature branch w/JIRA tickets and feedback / 
review done on the PR's in the open on the feature branch by 2+ committers, so 
folks have had a reasonable time to engage with the process and conduct a 
review. I don't think right on the cusp of a ceremonial / procedural cutover 
from a feature branch to trunk is the right time, nor scope of work, to propose 
a blocking review based on this text.

On Fri, Jan 27, 2023, at 3:10 PM, David Capwell wrote:
>> I've learned that when I have defended the need (or right, if appealing to 
>> the Governance texts...) for contributors to be able to review a feature 
>> branch at the time it is merged to trunk - which for Accord is now - that a 
>> common reaction to this is that doing a review of Accord now might take 
>> months and would stall the Accord project for months if that is allowed.
> 
> The way I have been reading this thread is not that “we don’t want the review 
> as it slows us down” but more “the process is X, why are you asking for Y?”.  
> I believe I can speak for everyone working on Accord, we all want more 
> reviewers and contributors!
> 
> I think its fair to ask the question on if feature branches “should" have the 
> same process as non-feature branches, but since that has not been called out 
> and voted on they are expected to follow the same process; if people working 
> on feature branches have not been following the same process that is 
> currently an issue that needs to be addressed (In the case of Accord all 
> contributors are Committers or PMC and same process has been followed as 
> trunk).  The project doesn’t have a good history (at least recent history) of 
> open development of features, most features are dumps from private sources, 
> so there are learning/growing pains as we try to develop new features in the 
> open.
> 
>> On the  other hand, I can think of many things that a pair of fresh eyes can 
>> do at this point in reasonable time, like days or a couple weeks. 
> I agree more eyes are better, but the conversation is on code that has 
> already merged.  I know that many of us review code after it has been merged, 
> and what we have been doing is filing follow up bugs/improvement requests as 
> new work.  A simple example of this was when the trie memtables patch landed 
> I reviewed code that was merged I think 2021 making memtables pluggable; I 
> found a bug in it, showed the bug existed, and worked with the authors to get 
> all this addressed.  Reviews after the fact are fine, common, and welcome in 
> this project, but that has always sponsored new tickets and new work to 
> address the feedback.
> 
> 
>> On Jan 27, 2023, at 7:39 AM, Henrik Ingo  wrote:
>> 
>> While the substance of the review discussion has moved to Jira, I wanted to 
>> come back here to clarify one thing:
>> 
>> I've learned that when I have defended the need (or right, if appealing to 
>> the Governance texts...) for contributors to be able to review a feature 
>> branch at the time it is merged to trunk - which for Accord is now - that a 
>> common reaction to this is that doing a review of Accord now might take 
>> months and would stall the Accord project for months if that is allowed.
>> 
>> So I just wanted to clarify I don't think that sounds "reasonable", as the 
>> word is used in the Governance wiki page. I agree that to engage in such 
>> level of review, it would have needed to happen earlier. On the  other hand, 
>> I can think of many things that a pair of fresh eyes can do at this point in 
>> reasonable time, like days or a couple weeks. 
>> 
>> I spent 6 hours 

Re: Merging CEP-15 to trunk

[Benedict]

I'm realizing in retrospect this leaves ambiguityAnother misreading at least of the intent of these clauses, is that they were to ensure that concerns about a design and approach are listened to, and addressed to the satisfaction of interested parties. It was essentially codifying the project’s long term etiquette around pieces of work with either competing proposals or fundamental concerns. It has historically helped to avoid escalation to vetoes, or reverting code after commit. It wasn’t intended that any reason might be invoked, as seems to have been inferred, and perhaps this should be clarified, though I had hoped it would be captured by the word “reasonable". Minor concerns that haven’t been caught by the initial review process can always be addressed in follow-up work, as is very common.On 27 Jan 2023, at 20:22, Josh McKenzie  wrote:I know that many of us review code after it has been merged, and what we have been doing is filing follow up bugs/improvement requests as new work.I think this is key. The code on the feature branch matches the same bar of quality / process that's on trunk, and it's trivially easy to checkout at the merge SHA and review the code in an IDE even after merge, raising questions with someone if you have concerns. If we were talking about merging this feature branch a week before a GA I could see why there'd be concern but we have a lot of calendar runway here.I'd expect modifications post merge to trunk to have the same inertia for/against them as modifications on a feature branch that have cleared our 2 committer bar for merge.Code must not be committed if a committer has requested reasonable time to conduct a review I'm realizing in retrospect this leaves ambiguity around where the code is committed (i.e. trunk vs. feature branch). On the one hand we could say this code has already been reviewed and committed; the feature branch had the same bar as trunk. On the other hand you could say the intent of this agreement was to allow committers to inspect code before it goes to trunk, which would present a different set of constraints.My perspective is that of the former; I consider this code "already committed". This work was done on a formal feature branch w/JIRA tickets and feedback / review done on the PR's in the open on the feature branch by 2+ committers, so folks have had a reasonable time to engage with the process and conduct a review. I don't think right on the cusp of a ceremonial / procedural cutover from a feature branch to trunk is the right time, nor scope of work, to propose a blocking review based on this text.On Fri, Jan 27, 2023, at 3:10 PM, David Capwell wrote:I've learned that when I have defended the need (or right, if appealing to the Governance texts...) for contributors to be able to review a feature branch at the time it is merged to trunk - which for Accord is now - that a common reaction to this is that doing a review of Accord now might take months and would stall the Accord project for months if that is allowed.The way I have been reading this thread is not that “we don’t want the review as it slows us down” but more “the process is X, why are you asking for Y?”.  I believe I can speak for everyone working on Accord, we all want more reviewers and contributors!I think its fair to ask the question on if feature branches “should" have the same process as non-feature branches, but since that has not been called out and voted on they are expected to follow the same process; if people working on feature branches have not been following the same process that is currently an issue that needs to be addressed (In the case of Accord all contributors are Committers or PMC and same process has been followed as trunk).  The project doesn’t have a good history (at least recent history) of open development of features, most features are dumps from private sources, so there are learning/growing pains as we try to develop new features in the open.On the  other hand, I can think of many things that a pair of fresh eyes can do at this point in reasonable time, like days or a couple weeks. I agree more eyes are better, but the conversation is on code that has already merged.  I know that many of us review code after it has been merged, and what we have been doing is filing follow up bugs/improvement requests as new work.  A simple example of this was when the trie memtables patch landed I reviewed code that was merged I think 2021 making memtables pluggable; I found a bug in it, showed the bug existed, and worked with the authors to get all this addressed.  Reviews after the fact are fine, common, and welcome in this project, but that has always sponsored new tickets and new work to address the feedback.On Jan 27, 2023, at 7:39 AM, Henrik Ingo  wrote:While the substance of the review discussion has moved to Jira, I wanted to come back here to clarify one thing:I've learned that when I have defended the need (or right, if appealing to the Gove

Apache Cassandra Publicity & Marketing Group - Cassandra Summit Asks

[Molly Monroy]

Hello All: I will be supporting the publicity & marketing working group
along with my colleagues at Constantia, which partners with Cassandra for
publicity and marketing. For those of you I haven't met yet, I look forward
to working with you!


For our first order of business for this group ... We need your help
getting the word out about Cassandra Summit, which is right around the
corner. We have two immediate requests to help us inform a broader audience
about the event and the future of Cassandra. Details follow. More
information will be shared around onsite promotional guidance as we get
closer to the event.

Thanks in advance for your support, and feel free to reach out with any Qs.
We will also discuss these asks on our first marketing & publicity call Wed
at 8a PT
(but
please don't wait on the call to happen to share word about the event!)

- Molly

Promote registration and build excitement for event:

   -

   ASK: Amplify event details via your company and personal social media
   channels

We need your help getting the word out about the event to your networks to
1) make sure we have as many folks in attendance as possible; 2) build a
strong level of excitement about the event within our community and with
communities around us. Can you amplify the details of the event on your
company and/or personal social networks now, and over the next few weeks? To
help with this, here is a social media cheat sheet with all the details
about the event, including key messages, suggested posts, and blog
templates. The more posts the better and the goal is a consistent stream of
content coming from the community each day. Reminder: early bird
registration ends 2/7.


   - Cassandra Summit social guidance
   




News Submission Process - help us create a robust publicity campaign:

   -

   ASK: submit any news your organization will announce at Cassandra Summit
   by Feb. 10

Cassandra Summit is a key publicity moment to announce project and
community news that will showcase our future. We will create a robust,
easy-to-access news package, inclusive of key foundation news and news from
organizations benefiting from Cassandra. This news package will be shared
with tech media, influencers and industry analysts, on behalf of the
project, to drive press coverage that positions Cassandra as the database
of the future.

   -

   Cassandra Summit: Call for Community News
   

   (Details on submission process)
   -

   Cassandra Summit News Submission Form
   
(please
   save a unique copy and sent to mo...@constantia.io)



On Thu, Jan 26, 2023 at 4:42 PM Patrick McFadin  wrote:

> Thanks for the positive reception on email and slack.
>
> We are going to have our first gathering next Wednesday at 8AM PT
>
> Link to calendar event:
> https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=MDVoY3VucnMwaWViaXA1amFmdXAzcnN0dTYga2w5cHVoZ2s3cXRkdXFhdHRlOHRmZDVtcHNAZw&tmsrc=kl9puhgk7qtduqatte8tfd5mps%40group.calendar.google.com
>
>
>
> On Tue, Jan 24, 2023 at 3:35 AM Mick Semb Wever  wrote:
>
>> The market...@cassandra.apache.org list is created.
>>
>> To subscribe send an email to marketing-subscr...@cassandra.apache.org
>> from
>> the email address you want to subscribe from.
>>
>> If you are a committer you can alternately use Whimsy:
>> https://whimsy.apache.org/committers/subscribe
>>
>> regards,
>> Mick
>>
>>
>> On Fri, 20 Jan 2023 at 00:31, Patrick McFadin  wrote:
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > *Hello Cassandra Community!We are at a pivotal moment for the Cassandra
>> > community, with the first Cassandra Summit in 7 years coming up on March
>> > 13th, and a major release coming later this year with Cassandra 5.0. It
>> is
>> > important that we come together to set the publicity strategy and
>> direction
>> > for these important moments, and that we work together to define how
>> > Cassandra shows up across the technology industry.To achieve this, we
>> are
>> > proposing the formation of a Publicity & Marketing Working Group, and we
>> > are requesting your participation.What is the Publicity & Marketing
>> Working
>> > Group?This is a working group open to community members who have the
>> > insight and skills to help define Cassandra’s public narrative and
>> > participate in our marketing strategy and execution. The group will meet
>> > once a month for an h