>
> 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
>
>

Reply via email to