[DISCUSS] Remove Dead Pull Requests

At the moment we have 222 open pull requests. Some dating back 4 years. For some the repository from which they were pulled from has been deleted. For many there are branch conflicts. Now, I am new here so please excuse any misstatements and attribute to ignorance not malice any offence. I

Re: Cassandra project status update 2022-08-03

 > We can start by putting the bar at a lower level and raise the level over time +1 > One simple approach that has been mentioned several time is to run the new > tests added by a given patch in a loop using one of the CircleCI tasks I think if we want to do this, it should be extremely easy

Re: Cassandra project status update 2022-08-03

Perhaps flaky tests need to be handled differently. Is there a way to build a statistical model of the current flakiness of the test that we can then use during testing to accept the failures? So if an acceptable level of flakiness is developed then if the test fails, it needs to be run again or

Re: [DISCUSS] Remove Dead Pull Requests

Claude, can you say more about the goal or purpose that closing tickets advances? There are quite a lot of tickets with patches attached that the project has either not been able to act on at the time; or which the original contributor started but was unable to complete. We’ve picked up many

Hint transfer during decommission

Hey friends, I'm looking for some feedback on whether what's been proposed in CASSANDRA-17808 is reasonable. To summarize... 1.) We continue to transfer hints by default during decommission, but at a higher rate. We could, for instance,

Re: [DISCUSS] Remove Dead Pull Requests

I recently came across a github automation in the docker project that I found interesting: https://github.com/docker/for-win/issues/7905#issuecomment-787212626 "Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed

Re: Cassandra project status update 2022-08-03

> “ We can start by putting the bar at a lower level and raise the level over > time when most of the flakies that we hit are above that level.” > My only concern is only who and how will track that. What's Butler's logic for flagging things flaky? Maybe a "flaky low" vs. "flaky high"

Re: Cassandra project status update 2022-08-03

On Wed, 10 Aug 2022 at 17:54, Josh McKenzie wrote: > “ We can start by putting the bar at a lower level and raise the level > over time when most of the flakies that we hit are above that level.” > My only concern is only who and how will track that. > > What's Butler's logic for flagging things

Re: Cassandra project status update 2022-08-03

> Side note, Butler is reporting CASSANDRA-17348 as open (it's resolved as a > duplicate). This is fixed.

Re: [DISCUSS] Remove Dead Pull Requests

I think of this from a discoverability and workflow perspective at least on the JIRA side, though many of the same traits apply to PR's. Some questions that come to mind: 1. Are people grepping through the backlog of open items for things to work on they'd otherwise miss if they were closed