On Thu, Sep 24, 2020 at 10:19 AM Joshua McKenzie <jmcken...@apache.org> 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 bit to misalignment and misunderstanding over time. Unfortuantely, I don't believe it was. The discussion occurred between committers/contributors/PMC members on the floor in the venue and was brought to the mailing list for a vote to ensure everyone was included. It certainly would have been better if we were able to capture more of it (we took as many notes as we could and translated them into that wiki doc but there was no ability to record/etc). While its true that even more detail would have been helpful, many of the folks who are pushing back against what was discussed there were not in attendance or active in the open source project at the time. > > Fewer and fewer people have the appetite to deal with this bickering and > exposing anyone new to this seems like a guaranteed way to turn them away > from the project for good. > Speaking for myself, the tone and tenor, in addition to the lack of progress, in these discussions have absolutely affected my desire to participate in the open source project (from taking additional reviews that would speed up 4.0 on my free time, to encouraging new community members to join, to participating in these discussions entirely). I hope we can find a better way to communicate. One suggestion I have for folks participating is to consider what feedback is best given on the public mailing list and what feedback is better delivered directly. We don't have to do EVERYTHING on the public mailing list. Only the parts that pertain to Cassandra. And sometimes we can resolve our personal differences better when there isn't an additional audience around. > > > On Thu, Sep 24, 2020 at 12:22 PM, Benedict Elliott Smith < > bened...@apache.org> wrote: > > > 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 asked to participate in the discussion has so far gone > > unanswered. It is reasonable that this is answered before a vote, since > > this is the entire basis of the argument in favour of branching. > > > > 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 existing committers. This seems to alleviate the > > concerns precipitating this discussion, while mitigating the concerns of > > those who are opposed to it. > > > > On 24/09/2020, 17:02, "Jake Luciani" <jak...@gmail.com> wrote: > > > > 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 and the issue will be > > decided? > > > > Jake > > > > On Thu, Sep 24, 2020 at 11:53 AM Benedict Elliott Smith <benedict@apache. > > org> wrote: > > > > 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 modify this document, or to make an exception, but I am > > aware of no other vote stipulating anything about the point at which we > > branch. > > > > On 24/09/2020, 16:49, "Jake Luciani" <jak...@gmail.com> wrote: > > > > 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 continuing to rely on beliefs about the community. > > > > I'm simply pointing out the branching of 4.0 post beta was the plan of > > last > > record. > > > > Jake > > > > On Thu, Sep 24, 2020 at 11:44 AM Benedict Elliott Smith < > benedict@apache. > > org> > > wrote: > > > > 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 sacrosanct anymore? > > > > On 24/09/2020, 16:22, "Jake Luciani" <jak...@gmail.com> wrote: > > > > 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 < > benedict@apache. > > org> > > wrote: > > > > 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, "Brandon Williams" <dri...@gmail.com> > > > > wrote: > > > > On Thu, Sep 24, 2020 at 9:55 AM Benedict Elliott Smith > > <bened...@apache.org> 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, > > > > perhaps even in 2020, release. > > > > I have deleted this branch, and will do so again if you > > > > repeat > > > > this. > > > > This would create some interesting tickets for INFRA, but > > > > I won't > > > > waste their time with you either. Whether either of us has > > > > the > > > > authority to do such on ASF infrastructure is irrelevant, > > > > since > > > > that > > > > is the only thing that can be argued here. The ASL > > > > absolutely > > > > allows > > > > people to innovate on their own with the code, so let's > > > > just > > > > move the > > > > bits. > > > > Those who wish to innovate, > > https://github.com/driftx/cassandra/tree/cassandra-5.0 is > > > > now > > > > open for > > > > business, PRs accepted. This will be maintained to track > > > > trunk > > > > on the > > > > ASF servers. > > > > I guess this is the apache way. > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > > > > dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: > > > > dev-h...@cassandra.apache.org > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For > > additional commands, e-mail: dev-h...@cassandra.apache.org > > > > -- > > http://twitter.com/tjake > > > > --------------------------------------------------------------------- To > > unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional > > commands, e-mail: dev-h...@cassandra.apache.org > > > > -- > > http://twitter.com/tjake > > > > --------------------------------------------------------------------- To > > unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional > > commands, e-mail: dev-h...@cassandra.apache.org > > > > -- > > http://twitter.com/tjake > > > > --------------------------------------------------------------------- To > > unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional > > commands, e-mail: dev-h...@cassandra.apache.org > > >
