Re: Merging CEP-15 to trunk

[Benedict]

There is no merge-then-review. The work has been reviewed. This is identical to 
how reviews work as normal.

If it helps your mental model, consider this a convenient atomic merge of many 
Jira that have independently met the standard project procedural requirements, 
as that is what it is.

Squashing of commits is normal before merging a ticket, and does not typically 
incur an additional round of review - indeed, it’s not even clear what this 
would mean, since a squash has no visible effect to review.

This is not a question of moving fast, but a question of process. We have out 
of politeness highlighted the impending merge of a lot of work. This is an 
invitation to engage on the relevant tickets that already exist to represent 
the work, not an invitation to create novel adhoc procedural steps.


> On 23 Jan 2023, at 22:54, Mick Semb Wever  wrote:
> 
> 
>> The sooner it’s in trunk, the more eyes it will draw, IMO, if you are right 
>> about most contributors not having paid attention to a feature branch.
> 
> 
> 
> We all agree we want the feature branch incrementally merged sooner rather 
> than later.
> IMHO any merge to trunk, and any rebase and squash of ninja-fix commits, 
> deserves an invite to reviewers.
> Any notion of merge-then-review isn't our community precedent.
> 
> I appreciate the desire to not "be left hanging" by creating a merge ticket 
> that requires a reviewer when no reviewer shows. And the desire to move 
> quickly on this.
> 
> I don't object if you wish to use this thread as that review process. On the 
> other hand, if you create the ticket I promise to be a reviewer of it, so as 
> not to delay.
> 
> 

Re: Merging CEP-15 to trunk

[Jeff Jirsa]

 But it's not merge-than-review, because they've already been reviewed,
before being merged to the feature branch, by committers (actually PMC
members)?

You want code that's been written by one PMC member and reviewed by 2 other
PMC members to be put up for review by some random 4th party? For how long?


On Mon, Jan 23, 2023 at 2:54 PM Mick Semb Wever  wrote:

> The sooner it’s in trunk, the more eyes it will draw, IMO, if you are
>> right about most contributors not having paid attention to a feature branch.
>>
>
>
> We all agree we want the feature branch incrementally merged sooner rather
> than later.
> IMHO any merge to trunk, and any rebase and squash of ninja-fix commits,
> deserves an invite to reviewers.
> Any notion of merge-then-review isn't our community precedent.
>
> I appreciate the desire to not "be left hanging" by creating a merge
> ticket that requires a reviewer when no reviewer shows. And the desire to
> move quickly on this.
>
> I don't object if you wish to use this thread as that review process. On
> the other hand, if you create the ticket I promise to be a reviewer of it,
> so as not to delay.
>
>
>

Re: Merging CEP-15 to trunk

[Mick Semb Wever]

>
> The sooner it’s in trunk, the more eyes it will draw, IMO, if you are
> right about most contributors not having paid attention to a feature branch.
>


We all agree we want the feature branch incrementally merged sooner rather
than later.
IMHO any merge to trunk, and any rebase and squash of ninja-fix commits,
deserves an invite to reviewers.
Any notion of merge-then-review isn't our community precedent.

I appreciate the desire to not "be left hanging" by creating a merge ticket
that requires a reviewer when no reviewer shows. And the desire to move
quickly on this.

I don't object if you wish to use this thread as that review process. On
the other hand, if you create the ticket I promise to be a reviewer of it,
so as not to delay.

Re: Cassandra CI Status 2023-01-07

[Caleb Rackliffe]

New failures from Build Lead Week 4:

*** CASSANDRA-18188 - Test failure in
upgrade_tests.cql_tests.cls.test_limit_ranges
- trunk
- AttributeError: module 'py' has no attribute 'io'

*** CASSANDRA-18189 - Test failure in
cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_with_timeouts
- 4.0
- assert 10 == 94764
- other failures currently open in this test class, but at least
superficially, different errors (see CASSANDRA-17322, CASSANDRA-18162)

Timeouts continue to manifest in many places.

On Sun, Jan 15, 2023 at 6:02 AM Mick Semb Wever  wrote:

> *** The Butler (Build Lead)
>>
>> The introduction of Butler and the Build Lead was a wonderful
>> improvement to our CI efforts.  It has brought a lot of hygiene in
>> listing out flakies as they happened.  Noted that this has in-turn
>> increased the burden in getting our major releases out, but that's to
>> be seen as a one-off cost.
>>
>
>
> New Failures from Build Lead Week 3.
>
>
> *** CASSANDRA-18156
> – 
> repair_tests.deprecated_repair_test.TestDeprecatedRepairNotifications.test_deprecated_repair_error_notification
>  - AssertionError: Node logs don't have an error message for the failed
> repair
>  - hard regression
>  - 3.0, 3.11,
>
> *** CASSANDRA-18164 – CASTest Message serializedSize(12) does not match
> what was written with serialize(out, 12) for verb
> PAXOS2_COMMIT_AND_PREPARE_RSP
>  - serializer class org.apache.cassandra.net.Message$Serializer; expected
> 1077, actual 1079
>  - 4.1, trunk
>
> *** CASSANDRA-18158
> – 
> org.apache.cassandra.distributed.upgrade.MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck
>  - Cannot achieve consistency level ALL
>  - 3.11, trunk
>
> *** CASSANDRA-18159 – repair_tests.repair_test.TestRepair.test_*dc_repair
>   - AssertionError: null
> in MemtablePool$SubPool.released(MemtablePool.java:193)
>  - 3.11, 4.0, 4.1, trunk
>
> *** CASSANDRA-18160
> – 
> cdc_test.TestCDC.test_insertion_and_commitlog_behavior_after_reaching_cdc_total_space
>  - Found orphaned index file in after CDC state not in former
>  - 4.1, trunk
>
> *** CASSANDRA-18161 –
>  
> org.apache.cassandra.transport.CQLConnectionTest.handleCorruptionOfLargeMessageFrame
>  - AssertionFailedError in
> CQLConnectionTest.testFrameCorruption(CQLConnectionTest.java:491)
>  - 4.0, 4.1, trunk
>
> *** CASSANDRA-18162 –
> cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_trip_non_prepared_statements
> - Inet address 127.0.0.3:7000 is not available: [Errno 98] Address
> already in use
> - 3.0, 3.11, 4.0, 4.1, trunk
>
> *** CASSANDRA-18163 –
>  
> transient_replication_test.TestTransientReplicationRepairLegacyStreaming.test_speculative_write_repair_cycle
>  - AssertionError Incoming stream entireSSTable
>  - 4.0, 4.1, trunk
>
>
> While writing these up, some thoughts…
>  - While Butler reports failures against multiple branches, there's no
> feedback/sync that the ticket needs its fixVersions updated when failures
> happen in other branches after the ticket is created.
>  - In 4.0 onwards, a majority of the failures are timeouts (>900s),
> reinforcing that the current main problem we are facing in ci-cassandra.a.o
> is saturation/infra
>
>
>
>
>

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

[Maxim Muzafarov]

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.*
> > >> [blank line]
> > >> java.*
> > >> [blank line]
> > >> javax.*
> > >> [blank line]
> > >> all other imports
> > >> [blank line]
> > >> static all other imports
> > >> ```
> > >
> > >
> > >
> > > 3, then 5.
> > > There's lots under com.*, net.*, org.* that is essentially the same as 
> > > "all other imports", what's the reason to separate those?
> > >
> > > My preference for 3 is simply that imports are by default collapsed, and 
> > > if I expand them it's the dependencies on other cassandra stuff I'm first 
> > > grokking. It's also our only imports that lead to cyclic dependencies 
> > > (which we're not good at).

Re: [DISCUSS] Formation of Apache Cassandra Publicity & Marketing Group

[Benjamin Lerer]

Super happy to see this happening. :-)

Le sam. 21 janv. 2023 à 00:08, Mick Semb Wever  a écrit :

>
> I'll add the both of you, and anyone else that speaks up.
>
> To clarify, being a moderator to the mailing list is only about
> accepting/rejecting posts being sent from recipients that have not (yet)
> subscribed.
> This is usually 95% spam and 5% existing users posting from a
> different account.
>
>
> On Fri, 20 Jan 2023 at 19:24, Molly Monroy  wrote:
>
>> 
>> I am also happy to be a moderator. Melissa and I together can ensure we
>> have a solid level of coverage.
>>
>> On Jan 20, 2023, at 11:03 AM, Melissa Logan 
>> wrote:
>>
>> 
>> I appreciate the open and more structured approach to publicity &
>> marketing so everyone can provide input and for transparency.
>>
>> I'm also happy to be a moderator.
>>
>>
>> On Fri, Jan 20, 2023 at 7:01 AM Patrick McFadin 
>> wrote:
>>
>>> I would be happy to be one of the moderators. Not sure if that's
>>> singular or plural. :D Just need to know how to do it.
>>>
>>> Patrick
>>>
>>> On Fri, Jan 20, 2023 at 1:44 AM Mick Semb Wever  wrote:
>>>
 *To achieve this, we are proposing the formation of a Publicity &
> Marketing Working Group, and we are requesting your participation.*
>


 +1 to the proposal and everything you write Patrick!

 I've submitted the request for the ML (can take 24 hours). Who would
 like to be a moderator for the list?

 Otherwise let's give this a few days for any concerns, questions,
 objections to be raised.


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