Cassandra Contributor Meeting to focus on outstanding 4.0 issues

Hi everyone, First, I want to acknowledge some of the raw conversations today in the cassandra-dev slack channel. It was probably well overdue and if not for 2020 and what a wonderful year this has been, we might have gotten there earlier. I really appreciate how everyone who participated kept the

Re: [DISCUSS] Next steps for Kubernetes operator SIG

Hi, Patrick's suggestion seems good to me. I won't go into specifics here as I need to genuinely prepare for this. It is quite hard to dig deep into the solutions of others and bring some constructive criticism because it takes a lot of time to study it and everybody has some "why's" behind it.

Re: Creating a branch for 5.0 …?

On Thu, Sep 24, 2020 at 10:19 AM Joshua McKenzie wrote: > Jordan: thanks for providing that context - it's quite helpful. Was that > aspect of the conversation captured and shared with the rest of the project > on the mailing list? It's a shame if not, since that may have contributed > quite a bi

Re: Creating a branch for 5.0 …?

Josh, > For what it's worth, when I engage with other people working on large forks > that want to bring their features back to the project, the absolute last > thing I want to do to them is throw them into email threads like this. People need to positively engage with the community, have discuss

Re: Creating a branch for 5.0 …?

On Thu, Sep 24, 2020 at 1:14 PM sankalp kohli wrote: > I think it is important to think why we are here. We are here as we shipped > 3.0 with 10s of correctness bug. So the statements should be > "3.0 shipped with 10s of correctness bugs and that is causing contributions > to go away and stopping

Re: [DISCUSS] Next steps for Kubernetes operator SIG

- choose cass-operator: it is not on offer right now so let’s see if it does We should all talk a lot more, but this is 100% a mistake - I take the blame for that. The intention has long been to offer cass-operator for donation but it slipped through the cracks and your email yesterday made me do

Re: Creating a branch for 5.0 …?

Hi, I hear the following "Freeze is causing contributions to go away and stopping innovation" "Lack of 4.0 release is causing people to think C* is dead." I think it is important to think why we are here. We are here as we shipped 3.0 with 10s of correctness bug. So the statements should be "3

Re: Creating a branch for 5.0 …?

On Thu, Sep 24, 2020 at 12:22 PM sankalp kohli wrote: > > Hi Brandon, > In all respect, we need to discuss and vote before we > create a new branch. So it is best if we do that instead of creating > branches. Fair enough. > Freeze is a symptom not a cause so if we dont like the

Re: [DISCUSS] Next steps for Kubernetes operator SIG

No problem Franck! I will postpone this week's meeting to next week and we can continue the discussion on the ML. Patrick On Thu, Sep 24, 2020 at 9:23 AM wrote: > I can share Orange’s view of the situation, sorry it is a long story! > > We started CassKop at the end of 2018 after betting on K8S

Re: Creating a branch for 5.0 …?

Hi Brandon, In all respect, we need to discuss and vote before we create a new branch. So it is best if we do that instead of creating branches. Freeze is a symptom not a cause so if we dont like the symptom, we should see how to fix the cause. Are we fine having a database releas

Re: Creating a branch for 5.0 …?

this is the basis of argument, This is incorrect. The basis of the argument was Mick's point of view he expressed as an individual on the project, which is that projects that turn away contributions or try and force people into contributing in certain ways are not long for this world. A very basic

Re: Creating a branch for 5.0 …?

On Thu, Sep 24, 2020 at 11:22 AM Benedict Elliott Smith wrote: > Given this is the basis of argument, I would also propose a less contentious > vote, should one be undertaken: to create a cassandra-5.0 branch that is open > only to contributions from those unaffiliated by employment with any exi

Re: [DISCUSS] Next steps for Kubernetes operator SIG

I can share Orange’s view of the situation, sorry it is a long story! We started CassKop at the end of 2018 after betting on K8S which was not so simple as far as C* was concerned. Lack of support for local storage, IPs that change all the time, different network plugins to try to implement a no

Re: Creating a branch for 5.0 …?

The discussion on the present topic has not concluded, and if we are making an exception to 4.0 only then it really needs to. Members of one organisation have been pushing hard for feature development to proceed, arguing it harms unnamed third parties. A request that these third parties be ask

Re: [DISCUSS] Next steps for Kubernetes operator SIG

I would like to propose a hybrid a hybrid of what Benedict mentioned. Let's postpone today's (Sept 24) SIG to the next week, Oct 1. Same time. I'll keep the same zoom with some modifications. Each group, CassKop and cass-operator can have time to present the following: - State your view of the

Re: Creating a branch for 5.0 …?

The intention was the former. It was discussed during apache con in 2019 and many people expressed the desire to wait until GA. Even some who initially were opposed to the freeze. Jordan On Thu, Sep 24, 2020 at 9:04 AM Joshua McKenzie wrote: > > https://lists.apache.org/thread.html/5ee66f3986b

Re: Creating a branch for 5.0 …?

https://lists.apache.org/thread.html/5ee66f3986bf8308912c216bd1b5f9aea35443626db9f92cdca4d7b9%40%3Cdev.cassandra.apache.org%3E "*From: *sankalp kohli *To: *dev *Subject: *Re: [VOTE] Branching Change for 4.0 Freeze *Date: *2018/07/11 21:50:08 *List: *dev@cassandra.apache.org

Re: Creating a branch for 5.0 …?

The vote was to unfreeze new changes at beta, so logically that means non-bugfix work goes into trunk. Jordan, thanks. That is a more recent vote so thanks. That being said, under that line Benedict comments this needs to be discussed. So how about we just have a Vote on branching cassandra-4.0

Re: Creating a branch for 5.0 …?

I'm not sure what you are referring to here, that vote said nothing about branching at beta. The most recent vote on the topic anyway was for the Release Lifecycle process, which stipulates branching at GA. https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle We can vote to

Re: Creating a branch for 5.0 …?

> Today the community still has in force an explicit vote prohibiting thee merge of this work. You referred to an explicit vote here. I assume that was the one you were referring to? Yes, the community should decide. Call a vote if you think the community thinks we should continue the freeze vs

Re: Creating a branch for 5.0 …?

https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle was voted on after and under GA states: "A new branch is created for the release with the new major version, limiting any new feature addition to the new release branch, with new feature development will continue to happen only

Re: Creating a branch for 5.0 …?

The community does everything through discussion and consensus. Does that include branching, or not? If there is no consensus, a vote is held. Whether or not you consider the vote from 2018 still valid, you still need to seek the consent of the community for your action today. Or is that not

Re: Creating a branch for 5.0 …?

I'm sorry I see no issue with branching 4.0 as it was the thing we voted on back in 2018. If you wish to extend the freeze you should call a new vote. On Thu, Sep 24, 2020 at 11:15 AM Benedict Elliott Smith wrote: > Nobody has any problem with an external repository being maintained. Just > be

Re: Creating a branch for 5.0 …?

Indeed, it looks like there is no issue with branching now. On Thu, Sep 24, 2020 at 10:12 AM Jake Luciani wrote: > > > Today the community still has in force an explicit vote prohibiting thee > merge of this work. You must conduct a vote to rescind this decision. > > Actually, the vote was defi

Re: Creating a branch for 5.0 …?

Nobody has any problem with an external repository being maintained. Just bear in mind the normal process will need to take place to merge to the ASF repository, and that there may be feedback and review requests to address, so merge order and diffs will probably change. On 24/09/2020, 16:05

Re: Creating a branch for 5.0 …?

> Today the community still has in force an explicit vote prohibiting thee merge of this work. You must conduct a vote to rescind this decision. Actually, the vote was defined to hold until beta release: https://lists.apache.org/thread.html/5ee66f3986bf8308912c216bd1b5f9aea35443626db9f92cdca4d7

Re: Creating a branch for 5.0 …?

On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith wrote: > > You do not have the authority to unilaterally overrule the community process. > This is a serious breach of your responsibilities as a member of the PMC. Feel free to complain that I'm creating branches we intend to someday, perh

Re: Creating a branch for 5.0 …?

> So, here's what I've done, in an effort to make a space for both of these groups to operate: the exact same thing we've done for every release in the past. I created a branch for the 4.0 release. I agree that everyone is free to work on whatever they want, but it seems like having a 4.next branc

Re: Creating a branch for 5.0 …?

You do not have the authority to unilaterally overrule the community process. This is a serious breach of your responsibilities as a member of the PMC. I have deleted this branch, and will do so again if you repeat this. As discussed, nobody can police what you work on, but the community does d

Re: Creating a branch for 5.0 …?

It's been a while now for this thread, but it seems to me that it has been established: 1. This is an opensource project and anyone is free to work on any part of it that they choose. Nobody has authority over this other than the contributor. 2. Some people are concerned that allowing innovation (

Re: [DISCUSS] Next steps for Kubernetes operator SIG

> > I realise there are meeting logs, but getting a wider discourse with > non-stakeholder input might help to build a community consensus? It > doesn't seem like it can hurt at this point, anyway. > +1 On Wed, Sep 23, 2020 at 9:21 PM Benedict Elliott Smith wrote: > Perhaps it helps to widen

Re: [DISCUSS] CEP-7 Storage Attached Index

>> Question is: is this planned as a next step? >> If yes, how are we going to mark SAI as experimental until it gets >> row offsets? Also, it is likely that index format is going to change when >> row offsets are added, so my concern is that we may have to support two >> versions of a format for a

Re: [DISCUSS] CEP-7 Storage Attached Index

> But for improving overall index read performance, I think improving base table read perf (because SAI/SASI executes LOTS of SinglePartitionReadCommand after searching on-disk index) is more effective than switching from Trie to Prefix BTree. I haven't suggested switching to Prefix B-Tree or any