Re: Project hygiene on old PRs

Thanks Paulo, I have not known that one. Jordan, yes I agree. I think that unless we automate it it is more about discipline than anything else. If I briefly enumerate the options: 1) put here "closes" as Paulo suggested - that needs manual intervention for a committer to put there such message (

Re: Project hygiene on old PRs

> Funny that people don't forget to create a PR when trying to make a change > but as soon as it is delivered the respective PR is "memory holed". We use the PR mechanisms for review but don't use the PR mechanism for merge. Makes sense that we open them since they're part of our workflow and for

Re: Project hygiene on old PRs

+1 on Paulo’s proposal. That will definitely help things up. I will give one or two more days in case someone missed the thread, and if there is no voices against it, I’ll just close the stale PRs and raise the ticket to INFRA to close PRs when a Jira ticket is resolved. Bernardo > On Apr 14,

Re: Constraint's "not null" alignment with transactions and their simplification

One argument I have against using columns in the constraint is that we currently are not able to actually handle the CHECK spec in SQL. In SQL the CHECK expression is a valid search expression (eg. price > 42 AND tag = ‘foo’), and is limited to the current row. Where we differ in Apache Cassan

Re: Project hygiene on old PRs

If we want something to happen repeatably we should automate it not add more manual tasks to the list. Paulo’s suggestion seems to be in line with that so +1 to something in that direction. We continually are swimming upstream making up our own process. The ask to put the ticket number in the PR

Last week to submit Cassandra proposals to Community Over Code 2025

Hi, I wanted to send a gentle reminder that the deadline for submissions to Community Over Code 2025 closes in 1 week at 23:59 UTC on April 21, 2025. Please submit your proposal via https://sessionize.com/community-over-code-na-2025 Thanks to all who have submitted so far. Feel free to reach out

Re: Constraint's "not null" alignment with transactions and their simplification

Consistency *within* our own ecosystem supersedes consistency with other familiar ecosystems IMO. I'd prefer we consistently apply the CHECK keyword and don't have special cases that omit it, or perhaps have those as optional syntactic sugar but at its base the syntax is uniform and consistent.

Re: Constraint's "not null" alignment with transactions and their simplification

To be honest, I agree with Bernardo here. The requirement to have "val int not null" makes sense at first, but it is not so straightforward. I think that what we are trying to do here is to "copy like they have it" because ... well, because they have it like that. And we do not want to differ too

Re: Constraint's "not null" alignment with transactions and their simplification

Now this is becoming a really interesting discussion. Thanks everyone for pitching in! Here is my take on some of the proposed changes: We are talking about treating some constraints (NOT_NULL, JSON) as special cases by omitting the CHECK keyword (not reserved as per current implementation). N

Re: Constraint's "not null" alignment with transactions and their simplification

As Yifan already said, "check" is not a reserved word now and its usage does not collide with anything. If people have columns, tables, keyspaces with name "check" that seems to work already so they don't need to do anything: CREATE TABLE ks.tb (id int check id > 0, val int check val > 0, primary

Re: Project hygiene on old PRs

*committers (and not reviewers) On Mon, Apr 14, 2025 at 12:13 PM Paulo Motta wrote: > > I am not sure why it is so hard for people to not forget to close a PR > when their branch is merged. > > I wonder if reviewers* know they need to append the message "Closes > #PR_ID" to the end of the commi

Re: Project hygiene on old PRs

> I am not sure why it is so hard for people to not forget to close a PR when their branch is merged. I wonder if reviewers know they need to append the message "Closes #PR_ID" to the end of the commit message to have the PR be closed, this does not seem very obvious, but it's also a bit inconven

Re: Project hygiene on old PRs

Just for reference, I ran a script I wrote using Stefan’s as inspiration, and there are 413 PRs without any activity for the past 6 months. Bernardo > On Apr 14, 2025, at 6:39 AM, Štefan Miklošovič wrote: > > > > On Mon, Apr 14, 2025 at 3:22 PM Josh McKenzie > w

Re: Project hygiene on old PRs

On Mon, 14 Apr 2025 at 10:23, Štefan Miklošovič wrote: > BTW If you still do not want to take care of closing it, that is also > fine, because we have a script at least. > >> >>> Relying on the PR name seems a bit brittle. Maybe it wouldn't take much to improve it. e.g. would it be possible to

Re: Project hygiene on old PRs

BTW If you still do not want to take care of closing it, that is also fine, because we have a script at least. But in that case, please do the absolute minimum and just be sure that you name your PRs correctly (starting with a JIRA ticket number) so the script will detect it. The worse combination

Re: Project hygiene on old PRs

I am not sure why it is so hard for people to not forget to close a PR when their branch is merged. I stopped "fighting" this and I just run a script every few weeks. Funny that people don't forget to create a PR when trying to make a change but as soon as it is delivered the respective PR is "memo