> > As long as you keep thinking the expressions on this ML reflect an > organization's priorities and not the opinions of individual actors we're > not going to get anywhere.
I propose we agree to disagree and stop thrashing the project with this topic. Nobody is going to change their mind based on continued back and forth opinion browbeating. Merit follows the individual. It's up to all of us individually to navigate any perceived pressures from where our paycheck comes from with what we personally think is genuinely best for the project. There's going to be some of us that think as close to a bug-free codebase as possible is the right approach, and those of us that think it's releasing rapidly. It's up to all of us to work together to find a middle ground at neither extreme, since that's probably where the healthiest calibration for the project lives anyway. Spending time framing and characterizing each others' contributions and points of view as individually motivated or social organization motivated or corporate organization motivated isn't helping any of us move forward. On Mon, Jun 29, 2020 at 11:40 AM Benjamin Lerer <benjamin.le...@datastax.com> wrote: > To answer your questions Jon. > > I have been against the freeze from day one. In my opinion it had a > > negative impact on the project. > > > > It is simply an opinion. I stated it as such because I have no way to > validate or invalidate that theory. > > Had we unfrozen trunk a year ago, we just > > would have shipped another super buggy .0 release and kept our reputation > > going. > > > > In my opinion having an unfrozen trunk does not mean necessarily shipping a > buggy release. > I see them as 2 different choices: Do we have a frozen trunk? What are our > criteria to ship a release? > > Once we've proven we can actually ship a working database, new features > > sound great to me. > > > > I agree with the fact that making C* more stable is the priority. I just > would like us to have a clear plan for that. > > This thread was not about sacrificing stability. It is a pity that it came > across like that. > > > On Mon, Jun 29, 2020 at 4:50 PM Joshua McKenzie <jmcken...@apache.org> > wrote: > > > > > > > I am pointing to the implied signals about an organisation's priorities > > > and values that are communicated by its actions > > > > As long as you keep thinking the expressions on this ML reflect an > > organization's priorities and not the opinions of individual actors (like > > my email about branching was because I didn't want to piss off Ekaterina > > and Benjamin by making them constantly rebase), we're not going to get > > anywhere. > > > > This thread isn't about 5.0 or a roadmap for it. If we want to talk about > > that let's take it to another thread. > > > > Also, this thread wasn't intended to discuss what our bar of quality for > a > > release of 4.0 should be. I think that's a great topic. Let's take that > to > > another thread. > > > > I recommend we let this thread die and move on. > > > > > > On Mon, Jun 29, 2020 at 10:33 AM Benjamin Lerer < > > benjamin.le...@datastax.com> > > wrote: > > > > > Sorry, Benedict. My answer was probably not phrased in the correct way. > > > I just believe that we should not look at the organizations behind the > > > persons participating in the project. I am not my organization and it > > does > > > not push me in a direction or another. > > > Of course, our opinions are somehow tainted by our organizations but > that > > > does not mean that individuals can be reduced to their organization. > > > > > > > > > On Mon, Jun 29, 2020 at 2:33 PM Benedict Elliott Smith < > > > bened...@apache.org> > > > wrote: > > > > > > > I believe that we should try to assume that everybody has positive > > > > intentions. :-) > > > > > > > > What did I say that suggests I have assumed any negative intentions? > > > > Sometimes this phrase reads as a thought-terminating cliché. > > > > > > > > > > > > > > > > On 29/06/2020, 13:28, "Benjamin Lerer" <benjamin.le...@datastax.com > > > > > > wrote: > > > > > > > > > > > > > > If this is in response to my email, you misunderstand me. > > > > > > > > > > > > > Sorry, that was not a response. > > > > Increasing stability was mentioned a lot in that thread. I am all > > for > > > > it. I > > > > just wanted to raise the issue that the plan for that is not > clear > > at > > > > least > > > > for me. > > > > > > > > That is not to say there should not be agreed minimum > deliverables, > > > but > > > > > they should be readily achievable in that time-frame. > > > > > > > > > > > > > I am totally in favor of determining what the deliverables should > > be. > > > > > > > > I am pointing to the implied signals about an organisation's > > > > priorities and > > > > > values that are communicated by its actions. > > > > > > > > > > > > > I believe that we should try to assume that everybody has > positive > > > > intentions. :-) > > > > I have been against the freeze from day one. In my opinion it > had a > > > > negative impact on the project. Now it is just a personal feeling > > and > > > > it > > > > does not mean that I am not all in favor of delivering a product > of > > > > better > > > > quality. > > > > I have spent most of my first 2 years working on C* writing test > > for > > > > the > > > > CQL code and that paid off in the long term as it seems that we > do > > > not > > > > have > > > > too many bugs in that area. > > > > For Cassandra to grow we need both new features/improvements and > > > > stability. > > > > It is natural that some people push a bit more towards new > > > > features\improvements and others towards stability. > > > > I would be worried if everybody wanted to go in the same > direction. > > > > > > > > On Mon, Jun 29, 2020 at 12:22 PM Benedict Elliott Smith < > > > > bened...@apache.org> > > > > wrote: > > > > > > > > > If this is in response to my email, you misunderstand me. > There > > > are > > > > > distinct issues at play. To respond directly to the issue you > > > > raise: I am > > > > > personally inclined to pursue a release of 4.0 within some > > time-box > > > > - say > > > > > 3-6 months. We have already done a huge amount to improve the > > > > quality of > > > > > the project since 3.x. That is not to say there should not be > > > agreed > > > > > minimum deliverables, but they should be readily achievable in > > that > > > > > time-frame. We can soon be confident of the highest quality .0 > > > > release to > > > > > date in the project, even if we have not delivered all that we > > > > originally > > > > > hoped on the quality assurance front. > > > > > > > > > > However, I am looking forward to the way the project delivers > > 5.0, > > > > and > > > > > whether we will continue to improve. I am pointing to the > > implied > > > > signals > > > > > about an organisation's priorities and values that are > > communicated > > > > by its > > > > > actions. These signals are read by actors both internal and > > > > external to > > > > > the organisation, and shape their actions in turn. If there > is a > > > > > disconnect between the implied and expressed priorities, this > > leads > > > > to > > > > > tensions; usually to the detriment of the expressed priorities, > > > since > > > > > actions speak louder than words. > > > > > > > > > > > > > > > On 29/06/2020, 10:10, "Benjamin Lerer" < > > > benjamin.le...@datastax.com > > > > > > > > > > wrote: > > > > > > > > > > I believe that we all need to see 4.0.0 being released. We > > have > > > > been > > > > > frozen > > > > > for too long in my opinions and some people simply believe > > that > > > > the > > > > > project > > > > > is dead. That is hurting us. > > > > > > > > > > That does not mean that I am not in favor of making that > > > release > > > > as > > > > > stable > > > > > as possible. > > > > > What we miss in my opinion is a clear target and some > > metrics. > > > > When > > > > > will we > > > > > know that we can release 4.0? How are we measuring its > > quality? > > > > > If we cannot provide some answers to those questions we can > > end > > > > up > > > > > spending > > > > > our life searching for bugs and 4.0 will never be released. > > > > > > > > > > Maybe there is a clear plan in the mind of some of you > guys. > > It > > > > is > > > > > just not > > > > > the case for me. So chances are that I am not the only one > in > > > > this > > > > > case. > > > > > > > > > > The 4.0 Beta is nearly there, more than ever we need a > clear > > > > testing > > > > > plan > > > > > that will lead us to releasing 4.0. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Jun 28, 2020 at 12:07 AM Benedict Elliott Smith < > > > > > bened...@apache.org> > > > > > wrote: > > > > > > > > > > > > Just a heads up - this comes across as passive > aggressive > > > > sniping. > > > > > I'm > > > > > > sure you didn't mean it as such > > > > > > > > > > > > I think indirect criticism is a normal part of discourse, > > > > > particularly in > > > > > > public fora where it can be more polite and less > disruptive > > > > than > > > > > direct > > > > > > criticism. Ironically, this snippet of yours seem (to > me) > > to > > > > be more > > > > > > readily ascribed your epithet; which is fine, of course, > > and > > > > > pleasingly > > > > > > meta. > > > > > > > > > > > > > very little has publically materialized on the project > to > > > > this > > > > > point > > > > > > that I know of > > > > > > > > > > > > I think you are wrong, here. Firstly, you overlook > recent > > > > work such > > > > > as > > > > > > (but not limited to): FQL, cassandra-diff, in-jvm dtests; > > > also > > > > the > > > > > steady > > > > > > drip of dozens of critical bugs found, and the work to > fix > > > > those > > > > > bugs. It > > > > > > is perhaps unfair to label "very little" work that has > > > spanned > > > > > several > > > > > > years and uncovered perhaps the majority of serious > > > > correctness bugs. > > > > > > > > > > > > Secondly, there is an important distinction to draw, > > between > > > QA > > > > > projects > > > > > > that are in progress but not yet published, and an > absence > > of > > > > such > > > > > > projects. We might also note feature development > > endeavours > > > > that > > > > > have been > > > > > > initiated, and whether work aims to improve quality or > > expand > > > > > > functionality. I look forward to seeing the balance of > > > > investments > > > > > shift > > > > > > to match stated priorities in the near future. > > > > > > > > > > > > > > > > > > > > > > > > On 27/06/2020, 03:10, "Joshua McKenzie" < > > > jmcken...@apache.org > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > I've seen a lot of talk from some quarters of a new > > > > approach to > > > > > > quality, > > > > > > > but so far there have been few contributions from > the > > > > same > > > > > quarters > > > > > > > > > > > > > Just a heads up - this comes across as passive > > aggressive > > > > > sniping. I'm > > > > > > sure > > > > > > you didn't mean it as such but it does read that way > > (at > > > > least > > > > > to me). > > > > > > > > > > > > When it comes to quality, much like you said in > another > > > > thread > > > > > > Benedict I > > > > > > think we all need to be honest with ourselves. > There's > > > > been a > > > > > lot of > > > > > > talk > > > > > > from *all* quarters but outside a lot of expression > of > > > > intent > > > > > across > > > > > > many > > > > > > fronts (verbal, ML, JIRA, slack), very little has > > > > publically > > > > > > materialized > > > > > > on the project to this point that I know of. > > > > > > > > > > > > I cleared out assignees on 40_quality_testing tickets > > > > earlier > > > > > this week > > > > > > (overloading shepherds in this field was a mistake > IMO > > - > > > > that's > > > > > on me) > > > > > > which has clarified for some contributors that they > can > > > > take > > > > > that work > > > > > > on. > > > > > > There's still considerable uncertainty as to what the > > > > scope is > > > > > for > > > > > > those > > > > > > tickets and nobody really replied to Jordan pinging > > > > shepherds for > > > > > > clarification a long while ago. > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 26, 2020 at 8:44 PM Dinesh Joshi < > > > > djo...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > > On Jun 26, 2020, at 3:45 PM, David Capwell < > > > > > dcapw...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > > > the ability to test their impact. Even simple > > things > > > > become > > > > > hard > > > > > > given > > > > > > > the > > > > > > > > fact only committers can run Jenkins tests, or > you > > > pay > > > > money > > > > > to be > > > > > > able > > > > > > > to > > > > > > > > run the tests... If the intent is to make it > > easier > > > > for new > > > > > > people to > > > > > > > > contribute to the project, shouldn't the focus be > > on > > > > fixing > > > > > their > > > > > > pain > > > > > > > > points such as testing? > > > > > > > > > > > > > > +1 on not branching and keeping focus on testing > and > > > > fixing > > > > > 4.0. > > > > > > > > > > > > > > I am sorry about the situation for non-committers. > I > > > > tried > > > > > reaching > > > > > > out to > > > > > > > legal and infra in the past without a great > response. > > > If > > > > > someone in > > > > > > the > > > > > > > community has a way to reach out and get clarity on > > > > problems > > > > > > affecting our > > > > > > > contributors, it would be great. Otherwise, I will > > try > > > > to bug > > > > > them > > > > > > again. > > > > > > > > > > > > > > Dinesh > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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 > > > > > > > > > > > > > >
