You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Joshua McKenzie <jm...@apache.org> on 2020/06/26 13:43:03 UTC
[DISCUSS] When to branch 4.0
As we close on cutting beta1, a new consequence of our release lifecycle is
becoming apparent. With guarantees of API stability in the beta phase, any
work that is deferred from alpha to the next major due to API impacting
changes will atrophy for as long as the beta is active.
Cutting a branch for the 4.0 line upon release of beta1 would mitigate this
problem and allow work in flight to be merged in, as well as unblock the
work of others who may not be focusing on testing 4.0, whether it be due to
their interest and focus or due to saturation on the work in scope for the
release.
The obvious downsides to cutting a branch of a major and allowing dev on
trunk to continue separately is 1) the need to merge up to trunk on changes
going into beta, and 2) a risk of a lack of focus on testing the release
due to the availability of developing on trunk. My personal thoughts on
those two points:
1) changes going into beta should be small enough that a fast-forward merge
should be available in the majority of cases up to trunk. We've done this
with previous releases and it wasn't prohibitively expensive in terms of
time. Further, I would posit that changes going into beta should be on the
smaller side, further mitigating the burden of this process.
2) We've been feature frozen since late 2018 with the expressed intention
to encourage work on testing and stabilizing 4.0. I am not aware of any
contributors whose time and energy has been invested in testing 4.0 that
would otherwise have gone to trunk (i.e. this approach achieving its
desired outcomes), however I do know of several major contributors and
contributions that have atrophied and been deterred from further work on
the project due to waiting for 4.0 to release.
I don't think it's appropriate for us as an existing body of contributors
to mandate either how each other or more detrimentally how other new
contributors engage with and contribute to the project by disallowing
contributions past 4.0; I take the position that we should do everything
reasonably possible to encourage a diversity of contributions to the
project. I deeply believe that making deliberate decisions to prioritize
new engagement and interaction on the project as the context in which it's
used evolves is vital to the project's health long term.
That's just my .02 - I'd be curious to hear what everyone else thinks.
~Josh
Re: [DISCUSS] When to branch 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
This is all really key to be honest. The only feature we need to develop today is quality, and this is true regardless of 4.0.0. 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 that materially contribute to it. With a shift to discussing new feature development, it begins to look a bit empty.
Put some of that excitement for developing new features into developing new approaches to assuring quality. I would love to see some CEP on this topic, and I would consider it a worthwhile distraction to participate in those discussions.
On 26/06/2020, 23:45, "David Capwell" <dc...@gmail.com> wrote:
>
> 1) changes going into beta should be small enough that a fast-forward merge
>
should be available in the majority of cases up to trunk. We've done this
> with previous releases and it wasn't prohibitively expensive in terms of
> time. Further, I would posit that changes going into beta should be on the
> smaller side, further mitigating the burden of this process.
I don't have much experience here, but what I find is that a decent chunk
of the fixes I have been posting have to be rewritten for 2.2 (mostly CI),
3.0, 3.11, and trunk. This is currently already painful and makes me less
likely to want to fix things... If we branch 4.0 and people start
refactoring trunk, then there is even more burden to fix issues; I don't
see this as a small issue today.
2) We've been feature frozen since late 2018 with the expressed intention
> to encourage work on testing and stabilizing 4.0. I am not aware of any
> contributors whose time and energy has been invested in testing 4.0 that
> would otherwise have gone to trunk (i.e. this approach achieving its
> desired outcomes), however I do know of several major contributors and
> contributions that have atrophied and been deterred from further work on
> the project due to waiting for 4.0 to release.
When I joined this project I heard that Repair was a pinpoint for many, so
the first thing I did was look into why and started trying to fix bugs with
Repair. In doing this I found that the testing of repair is lacking and
that small regressions would not be caught by the current tests, so shifted
my focus to improving the testing rather than make the large changes I
wanted to make; my reasoning was simple, "if I can not rely on the existing
tests to show I didn't break anything, by fixing 1 problem I may break 10
others".
I was then later pulled off this into 3.x issues as many still struggle
upgrading from 2.1 to 3.x. I am currently weighted down by features which
are broken in 3.x (so have to rewrite them to be able to migrate), and a
constant stream of new data corruption bugs (I currently have 5 on my
plate). As I resolve the issues I see the common trend is "we lacked
testing in X".
Given the amount of data loss and corruption bugs that keep popping up, I
do feel it's reasonable to ask people to focus on testing rather than new
features. If we don't have a strong foundation we believe in, how do we
build a strong house on top?
I take the position that we should do everything
> reasonably possible to encourage a diversity of contributions to the
> project. I deeply believe that making deliberate decisions to prioritize
> new engagement and interaction on the project as the context in which it's
> used evolves is vital to the project's health long term.
I fully agree with this, which is why I feel the feature freeze is in the
best interest of the project and that we should be focusing on testing. The
hardest thing I have found is that adding a new feature is that there is an
unreasonable expectation of what you have to learn, their interactions, and
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?
On Fri, Jun 26, 2020 at 3:38 PM Jordan West <jo...@gmail.com> wrote:
> On Fri, Jun 26, 2020 at 2:58 PM Benedict Elliott Smith <
> benedict@apache.org>
> wrote:
>
> > > Nothing is stopping us for discussing CEPs now, and nothing prevents
> > folks from making their own feature branches.
> >
> > I disagree. CEPs are just as - if not more - of a distraction than
> > branching.
> >
>
> > Work doesn't happen in a vacuum. Those who are today focusing what
> > resources they can on shipping 4.0.0 will have to divert resources to the
> > new CEP and feature development happening on the project. It is
> > unrealistic to expect otherwise.
> >
> > We can have a swifter 4.0.0 release, or we can begin earnestly developing
> > new features, but we cannot have both.
> >
> >
> Agreed 100% and I would prefer to see us all focus on getting 4.0.0 out. I
> only meant we never explicitly voted to prevent CEPs from being submitted
> at this time and it was more in response to a comment in the initial email
> in this thread.
>
>
> >
> > On 26/06/2020, 22:09, "Jon Haddad" <jo...@jonhaddad.com> wrote:
> >
> > We currently have 2.1, 2.2, 3.0 3.11, and trunk. With a new branch
> > we'll
> > _also_ have whatever is next, let's call it 5.0.
> >
> > Nothing is stopping us for discussing CEPs now, and nothing prevents
> > folks
> > from making their own feature branches.
> >
> > If we're going to add another branch (4.0) and let people merge to
> > trunk,
> > we're making an *active* decision to push the 4.0 release out even
> > further,
> > because the folks working on it will have to learn the new code when
> > they
> > merge forward.
> >
> > I'm -1 on branching before we release 4.0.
> >
> > On Fri, Jun 26, 2020 at 2:04 PM Mick Semb Wever <mc...@apache.org>
> > wrote:
> >
> > > >
> > > > > Branching anytime before we 4.0.0 adds extra burden to the
> folks
> > trying
> > > > to
> > > > > get 4.0.0 out the door (because of merge up)
> > > >
> > > > Given both that we've done this with every major release in the
> > past, as
> > > > well as the type of work we'd expect to land during the beta
> phase
> > > > (smaller, non-api breaking, defect fixing or smaller performance
> > > tuning), I
> > > > didn't personally originally weigh this as being as much of a
> > burden as
> > > you
> > > > perceive it to be.
> > >
> > >
> > >
> > > Looking at this a different way, you might say we have previously
> > cut the
> > > release branch somewhere around beta. Because previous releases
> > haven't
> > > (all) had so much focus on testing and alphas. My impression is
> that
> > 4.0.0
> > > will be closer compared to a second or third patch of previous
> major
> > > releases.
> > >
> > > So I would have thought it makes sense around beta or RC to branch,
> > > especially RC because between RC and GA it is more about a cooling
> > period,
> > > public acceptance and testing. That RC to GA window should be quiet
> > enough
> > > that it makes sense to branch then, and kick off the CEP
> discussions.
> > >
> > > I don't think the forward merging really is so much of a problem,
> > it's a
> > > normal activity in the C* codebase, and the additional
> merge-forward
> > window
> > > between either beta or RC, to GA is short.
> > >
> > > Thanks Ekaterina and Benjamin and Josh for raising the discussion.
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] When to branch 4.0
Posted by Joshua McKenzie <jm...@apache.org>.
>
> 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 <be...@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 <jm...@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.lerer@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 <
> > > benedict@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.lerer@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 <
> > > > benedict@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.lerer@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 <
> > > > > benedict@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" <
> > > jmckenzie@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 <
> > > > djoshi@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > > On Jun 26, 2020, at 3:45 PM, David Capwell <
> > > > > dcapwell@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-unsubscribe@cassandra.apache.org
> > > > > > > For additional commands, e-mail:
> > > > dev-help@cassandra.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > dev-unsubscribe@cassandra.apache.org
> > > > > > For additional commands, e-mail:
> > > dev-help@cassandra.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> >
>
Re: [DISCUSS] When to branch 4.0
Posted by Benjamin Lerer <be...@datastax.com>.
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 <jm...@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.lerer@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 <
> > benedict@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" <be...@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 <
> > > benedict@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.lerer@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 <
> > > > benedict@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" <
> > jmckenzie@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 <
> > > djoshi@apache.org>
> > > > > wrote:
> > > > >
> > > > > > > On Jun 26, 2020, at 3:45 PM, David Capwell <
> > > > dcapwell@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-unsubscribe@cassandra.apache.org
> > > > > > For additional commands, e-mail:
> > > dev-help@cassandra.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> dev-unsubscribe@cassandra.apache.org
> > > > > For additional commands, e-mail:
> > dev-help@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
>
Re: [DISCUSS] When to branch 4.0
Posted by Joshua McKenzie <jm...@apache.org>.
>
> 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 <be...@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 <
> benedict@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" <be...@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 <
> > benedict@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.lerer@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 <
> > > benedict@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" <
> jmckenzie@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 <
> > djoshi@apache.org>
> > > > wrote:
> > > >
> > > > > > On Jun 26, 2020, at 3:45 PM, David Capwell <
> > > dcapwell@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-unsubscribe@cassandra.apache.org
> > > > > For additional commands, e-mail:
> > dev-help@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail:
> dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: [DISCUSS] When to branch 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
> I just believe that we should not look at the organizations behind the persons
You collaborate as an organisation, produce work for the project as an organisation, and the organisation tells its members - each to some greater or lesser extent - how to spend their labour. Even if we only treat you as a coherent social group engaging with the project, your organisation still exists. If you want we can jump through whatever semantic exercise you like to define your organisation's manifestation in the project in a manner that is acceptable to you, but let's not pretend that it does not exist, and that its priorities do not exert significant control over the project.
> It is natural that some people push a bit more towards new features\improvements and others towards stability
Features do not come cost-free to other contributors. Those who focus on features at the expense of quality end up being subsidised by the labour of the latter group. This is unacceptable, and unworkable in the long run. If an organisation controlling overwhelming labour resources does not prioritise quality, there will be a crisis of governance that will need to be addressed.
On 29/06/2020, 15:33, "Benjamin Lerer" <be...@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 <be...@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" <be...@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 <
> benedict@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.lerer@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 <
> > benedict@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" <jmckenzie@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 <
> djoshi@apache.org>
> > > wrote:
> > >
> > > > > On Jun 26, 2020, at 3:45 PM, David Capwell <
> > dcapwell@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-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail:
> dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] When to branch 4.0
Posted by Benjamin Lerer <be...@datastax.com>.
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 <be...@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" <be...@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 <
> benedict@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.lerer@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 <
> > benedict@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" <jmckenzie@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 <
> djoshi@apache.org>
> > > wrote:
> > >
> > > > > On Jun 26, 2020, at 3:45 PM, David Capwell <
> > dcapwell@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-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail:
> dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] When to branch 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
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" <be...@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 <be...@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" <be...@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 <
> benedict@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" <jm...@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 <dj...@apache.org>
> > wrote:
> >
> > > > On Jun 26, 2020, at 3:45 PM, David Capwell <
> dcapwell@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-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] When to branch 4.0
Posted by Ekaterina Dimitrova <e....@gmail.com>.
+1
“This thread was not about sacrificing stability. It is a pity that it came
across like that.“
On Mon, 29 Jun 2020 at 13:35, Stefan Miklosovic <
stefan.miklosovic@instaclustr.com> wrote:
> On Mon, 29 Jun 2020 at 16:50, Jon Haddad <jo...@jonhaddad.com> wrote:
> >
> > > I have been against the freeze from day one. In my opinion it had a
> > negative impact on the project.
> >
> > I'm curious how you're measuring this. Based on my time as an evangelist
> > at DataStax and as a consultant with the Last Pickle, I can say I rarely
> > talked to people looking for shiny new features. Most of the time they
> > wanted the features we've shipped for years to actually work. The
> storage
> > engine for *years* didn't work correctly. Some features still don't,
> like
> > MVs, incremental repair and SASI. We have a reputation for shipping
> broken
> > features, being unstable, and generally being a DB you shouldn't actually
> > count on.
>
> This is my _personal_ opinion as well. Don't take me wrong, I am
> really appreciating a lot of work which went to Cassandra over the
> years, all hats down, but when it comes to it, for example, MV views
> are "better not to use, man", secondary indexes are "do not overuse
> it, you know what ... just dont use it", now transient replication
> will be "you know what, this is quite experimental and some corner
> cases will never be supported", sasi and incremental repairs - yeah it
> works "but", etc etc. So what I am finding myself in is a lot of buts
> and ifs and howevers and one realizes that the best way to use
> Cassandra is just to use simple straightforward scenarios.
>
>
> "Always on" for most teams is marketing speak - it's difficult
> > to defend when someone's cluster goes into a death spiral because they
> ran
> > a "nodetool repair", or is using row cache, or creates an MV because they
> > were hyped up as part of a release [1]. Five years later, still so
> > horribly broken that they are all but guaranteed to not work if you have
> a
> > non trivial amount of data and we had to mark them as experimental
> > post-release. There's a list here [1] for reference, in case anyone
> wants
> > a refresher.
> >
> > The trunk freeze has gone on for a while, it's the result of recklessly
> > merging in untested features with very little consideration for scale.
> > What's happening now couldn't be avoided, because the alternative is
> people
> > just don't use the DB anymore.
> >
> > > For Cassandra to grow we need both new features/improvements and
> > stability.
> >
> > People won't use the shiny new features if they don't trust the DB, and
> > right now they don't trust it. Had we unfrozen trunk a year ago, we just
> > would have shipped another super buggy .0 release and kept our reputation
> > going.
> >
> > Once we've proven we can actually ship a working database, new features
> > sound great to me.
> >
> > [1] https://tinyurl.com/30seriousissues
> > [2]
> >
> https://www.datastax.com/blog/2015/06/new-cassandra-30-materialized-views
> > [3] https://www.postgresql.org/docs/9.1/tutorial-window.html
> >
> >
> > On Mon, Jun 29, 2020 at 5:28 AM Benjamin Lerer <
> benjamin.lerer@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 <
> > > benedict@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.lerer@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 <
> > > > benedict@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" <jmckenzie@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 <
> > > djoshi@apache.org>
> > > > > wrote:
> > > > >
> > > > > > > On Jun 26, 2020, at 3:45 PM, David Capwell <
> > > > dcapwell@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-unsubscribe@cassandra.apache.org
> > > > > > For additional commands, e-mail:
> > > dev-help@cassandra.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] When to branch 4.0
Posted by Stefan Miklosovic <st...@instaclustr.com>.
On Mon, 29 Jun 2020 at 16:50, Jon Haddad <jo...@jonhaddad.com> wrote:
>
> > I have been against the freeze from day one. In my opinion it had a
> negative impact on the project.
>
> I'm curious how you're measuring this. Based on my time as an evangelist
> at DataStax and as a consultant with the Last Pickle, I can say I rarely
> talked to people looking for shiny new features. Most of the time they
> wanted the features we've shipped for years to actually work. The storage
> engine for *years* didn't work correctly. Some features still don't, like
> MVs, incremental repair and SASI. We have a reputation for shipping broken
> features, being unstable, and generally being a DB you shouldn't actually
> count on.
This is my _personal_ opinion as well. Don't take me wrong, I am
really appreciating a lot of work which went to Cassandra over the
years, all hats down, but when it comes to it, for example, MV views
are "better not to use, man", secondary indexes are "do not overuse
it, you know what ... just dont use it", now transient replication
will be "you know what, this is quite experimental and some corner
cases will never be supported", sasi and incremental repairs - yeah it
works "but", etc etc. So what I am finding myself in is a lot of buts
and ifs and howevers and one realizes that the best way to use
Cassandra is just to use simple straightforward scenarios.
"Always on" for most teams is marketing speak - it's difficult
> to defend when someone's cluster goes into a death spiral because they ran
> a "nodetool repair", or is using row cache, or creates an MV because they
> were hyped up as part of a release [1]. Five years later, still so
> horribly broken that they are all but guaranteed to not work if you have a
> non trivial amount of data and we had to mark them as experimental
> post-release. There's a list here [1] for reference, in case anyone wants
> a refresher.
>
> The trunk freeze has gone on for a while, it's the result of recklessly
> merging in untested features with very little consideration for scale.
> What's happening now couldn't be avoided, because the alternative is people
> just don't use the DB anymore.
>
> > For Cassandra to grow we need both new features/improvements and
> stability.
>
> People won't use the shiny new features if they don't trust the DB, and
> right now they don't trust it. Had we unfrozen trunk a year ago, we just
> would have shipped another super buggy .0 release and kept our reputation
> going.
>
> Once we've proven we can actually ship a working database, new features
> sound great to me.
>
> [1] https://tinyurl.com/30seriousissues
> [2]
> https://www.datastax.com/blog/2015/06/new-cassandra-30-materialized-views
> [3] https://www.postgresql.org/docs/9.1/tutorial-window.html
>
>
> On Mon, Jun 29, 2020 at 5:28 AM Benjamin Lerer <be...@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 <
> > benedict@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" <be...@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 <
> > > benedict@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" <jm...@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 <
> > djoshi@apache.org>
> > > > wrote:
> > > >
> > > > > > On Jun 26, 2020, at 3:45 PM, David Capwell <
> > > dcapwell@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-unsubscribe@cassandra.apache.org
> > > > > For additional commands, e-mail:
> > dev-help@cassandra.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] When to branch 4.0
Posted by Jon Haddad <jo...@jonhaddad.com>.
> I have been against the freeze from day one. In my opinion it had a
negative impact on the project.
I'm curious how you're measuring this. Based on my time as an evangelist
at DataStax and as a consultant with the Last Pickle, I can say I rarely
talked to people looking for shiny new features. Most of the time they
wanted the features we've shipped for years to actually work. The storage
engine for *years* didn't work correctly. Some features still don't, like
MVs, incremental repair and SASI. We have a reputation for shipping broken
features, being unstable, and generally being a DB you shouldn't actually
count on. "Always on" for most teams is marketing speak - it's difficult
to defend when someone's cluster goes into a death spiral because they ran
a "nodetool repair", or is using row cache, or creates an MV because they
were hyped up as part of a release [1]. Five years later, still so
horribly broken that they are all but guaranteed to not work if you have a
non trivial amount of data and we had to mark them as experimental
post-release. There's a list here [1] for reference, in case anyone wants
a refresher.
The trunk freeze has gone on for a while, it's the result of recklessly
merging in untested features with very little consideration for scale.
What's happening now couldn't be avoided, because the alternative is people
just don't use the DB anymore.
> For Cassandra to grow we need both new features/improvements and
stability.
People won't use the shiny new features if they don't trust the DB, and
right now they don't trust it. Had we unfrozen trunk a year ago, we just
would have shipped another super buggy .0 release and kept our reputation
going.
Once we've proven we can actually ship a working database, new features
sound great to me.
[1] https://tinyurl.com/30seriousissues
[2]
https://www.datastax.com/blog/2015/06/new-cassandra-30-materialized-views
[3] https://www.postgresql.org/docs/9.1/tutorial-window.html
On Mon, Jun 29, 2020 at 5:28 AM Benjamin Lerer <be...@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 <
> benedict@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" <be...@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 <
> > benedict@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" <jm...@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 <
> djoshi@apache.org>
> > > wrote:
> > >
> > > > > On Jun 26, 2020, at 3:45 PM, David Capwell <
> > dcapwell@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-unsubscribe@cassandra.apache.org
> > > > For additional commands, e-mail:
> dev-help@cassandra.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: [DISCUSS] When to branch 4.0
Posted by Benjamin Lerer <be...@datastax.com>.
>
> 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 <be...@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" <be...@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 <
> benedict@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" <jm...@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 <dj...@apache.org>
> > wrote:
> >
> > > > On Jun 26, 2020, at 3:45 PM, David Capwell <
> dcapwell@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-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] When to branch 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
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" <be...@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 <be...@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" <jm...@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 <dj...@apache.org>
> wrote:
>
> > > On Jun 26, 2020, at 3:45 PM, David Capwell <dc...@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-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] When to branch 4.0
Posted by Benjamin Lerer <be...@datastax.com>.
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 <be...@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" <jm...@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 <dj...@apache.org>
> wrote:
>
> > > On Jun 26, 2020, at 3:45 PM, David Capwell <dc...@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-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] When to branch 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
> 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" <jm...@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 <dj...@apache.org> wrote:
> > On Jun 26, 2020, at 3:45 PM, David Capwell <dc...@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-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] When to branch 4.0
Posted by Joshua McKenzie <jm...@apache.org>.
I thought about this a bit more overnight - if I'm arguing that most work
would be fast forward merges to trunk if we branched beta due to the type
of work going into beta, the inverse argument should hold that most merges
into a feature branch would be fast forward or minimal. So I think the
basic motivation to push for branching that I opened this thread with is
actually largely moot.
It did surface something else for me concerning our posture as a project
and long term health from how we're signaling inclusivity to new
contributors and how we can encourage diversity in contributions on the
project. No need to conflate that with this thread however.
Thanks for the input, and definitely would love more visibility into some
of the things people have been working on that aren't yet captured in JIRA.
On Sat, Jun 27, 2020 at 12:57 AM Scott Andreas <sc...@paradoxica.net> wrote:
> Great point re: increasing the public visibility of testing and validation
> activity.
>
> I’ll partner with a few contributors I work with to prep a summary of our
> findings that aren’t already captured in JIRA tickets we’ve filed against
> 3.x and 4.0 so far (as David mentioned, many issues we’re identifying are
> 3.0 regressions).
>
> Some of these findings are notable, and many are quite standard — the type
> of experience that’s built from prep to deploy a major piece of software at
> large scale with a high degree of automation and confidence. But the pieces
> that are “standard” are the category of work that anyone automating large
> Cassandra 4.0 deployments must undertake and are things Cassandra’s users
> will need to be aware of. I’m sure those findings will be valuable to all
> on this list.
>
> Not all blocking issues involve a combination of range tombstones,
> legacylayout, complex types, paging state, mixed-version clusters, and
> reverse iteration. :)
>
> — Scott
>
> > On Jun 26, 2020, at 7:10 PM, Joshua McKenzie <jm...@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 <dj...@apache.org> wrote:
> >
> >>>> On Jun 26, 2020, at 3:45 PM, David Capwell <dc...@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-unsubscribe@cassandra.apache.org
> >> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] When to branch 4.0
Posted by Scott Andreas <sc...@paradoxica.net>.
Great point re: increasing the public visibility of testing and validation activity.
I’ll partner with a few contributors I work with to prep a summary of our findings that aren’t already captured in JIRA tickets we’ve filed against 3.x and 4.0 so far (as David mentioned, many issues we’re identifying are 3.0 regressions).
Some of these findings are notable, and many are quite standard — the type of experience that’s built from prep to deploy a major piece of software at large scale with a high degree of automation and confidence. But the pieces that are “standard” are the category of work that anyone automating large Cassandra 4.0 deployments must undertake and are things Cassandra’s users will need to be aware of. I’m sure those findings will be valuable to all on this list.
Not all blocking issues involve a combination of range tombstones, legacylayout, complex types, paging state, mixed-version clusters, and reverse iteration. :)
— Scott
> On Jun 26, 2020, at 7:10 PM, Joshua McKenzie <jm...@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 <dj...@apache.org> wrote:
>
>>>> On Jun 26, 2020, at 3:45 PM, David Capwell <dc...@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-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] When to branch 4.0
Posted by Joshua McKenzie <jm...@apache.org>.
>
> 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 <dj...@apache.org> wrote:
> > On Jun 26, 2020, at 3:45 PM, David Capwell <dc...@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-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] When to branch 4.0
Posted by Dinesh Joshi <dj...@apache.org>.
> On Jun 26, 2020, at 3:45 PM, David Capwell <dc...@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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] When to branch 4.0
Posted by David Capwell <dc...@gmail.com>.
>
> 1) changes going into beta should be small enough that a fast-forward merge
>
should be available in the majority of cases up to trunk. We've done this
> with previous releases and it wasn't prohibitively expensive in terms of
> time. Further, I would posit that changes going into beta should be on the
> smaller side, further mitigating the burden of this process.
I don't have much experience here, but what I find is that a decent chunk
of the fixes I have been posting have to be rewritten for 2.2 (mostly CI),
3.0, 3.11, and trunk. This is currently already painful and makes me less
likely to want to fix things... If we branch 4.0 and people start
refactoring trunk, then there is even more burden to fix issues; I don't
see this as a small issue today.
2) We've been feature frozen since late 2018 with the expressed intention
> to encourage work on testing and stabilizing 4.0. I am not aware of any
> contributors whose time and energy has been invested in testing 4.0 that
> would otherwise have gone to trunk (i.e. this approach achieving its
> desired outcomes), however I do know of several major contributors and
> contributions that have atrophied and been deterred from further work on
> the project due to waiting for 4.0 to release.
When I joined this project I heard that Repair was a pinpoint for many, so
the first thing I did was look into why and started trying to fix bugs with
Repair. In doing this I found that the testing of repair is lacking and
that small regressions would not be caught by the current tests, so shifted
my focus to improving the testing rather than make the large changes I
wanted to make; my reasoning was simple, "if I can not rely on the existing
tests to show I didn't break anything, by fixing 1 problem I may break 10
others".
I was then later pulled off this into 3.x issues as many still struggle
upgrading from 2.1 to 3.x. I am currently weighted down by features which
are broken in 3.x (so have to rewrite them to be able to migrate), and a
constant stream of new data corruption bugs (I currently have 5 on my
plate). As I resolve the issues I see the common trend is "we lacked
testing in X".
Given the amount of data loss and corruption bugs that keep popping up, I
do feel it's reasonable to ask people to focus on testing rather than new
features. If we don't have a strong foundation we believe in, how do we
build a strong house on top?
I take the position that we should do everything
> reasonably possible to encourage a diversity of contributions to the
> project. I deeply believe that making deliberate decisions to prioritize
> new engagement and interaction on the project as the context in which it's
> used evolves is vital to the project's health long term.
I fully agree with this, which is why I feel the feature freeze is in the
best interest of the project and that we should be focusing on testing. The
hardest thing I have found is that adding a new feature is that there is an
unreasonable expectation of what you have to learn, their interactions, and
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?
On Fri, Jun 26, 2020 at 3:38 PM Jordan West <jo...@gmail.com> wrote:
> On Fri, Jun 26, 2020 at 2:58 PM Benedict Elliott Smith <
> benedict@apache.org>
> wrote:
>
> > > Nothing is stopping us for discussing CEPs now, and nothing prevents
> > folks from making their own feature branches.
> >
> > I disagree. CEPs are just as - if not more - of a distraction than
> > branching.
> >
>
> > Work doesn't happen in a vacuum. Those who are today focusing what
> > resources they can on shipping 4.0.0 will have to divert resources to the
> > new CEP and feature development happening on the project. It is
> > unrealistic to expect otherwise.
> >
> > We can have a swifter 4.0.0 release, or we can begin earnestly developing
> > new features, but we cannot have both.
> >
> >
> Agreed 100% and I would prefer to see us all focus on getting 4.0.0 out. I
> only meant we never explicitly voted to prevent CEPs from being submitted
> at this time and it was more in response to a comment in the initial email
> in this thread.
>
>
> >
> > On 26/06/2020, 22:09, "Jon Haddad" <jo...@jonhaddad.com> wrote:
> >
> > We currently have 2.1, 2.2, 3.0 3.11, and trunk. With a new branch
> > we'll
> > _also_ have whatever is next, let's call it 5.0.
> >
> > Nothing is stopping us for discussing CEPs now, and nothing prevents
> > folks
> > from making their own feature branches.
> >
> > If we're going to add another branch (4.0) and let people merge to
> > trunk,
> > we're making an *active* decision to push the 4.0 release out even
> > further,
> > because the folks working on it will have to learn the new code when
> > they
> > merge forward.
> >
> > I'm -1 on branching before we release 4.0.
> >
> > On Fri, Jun 26, 2020 at 2:04 PM Mick Semb Wever <mc...@apache.org>
> > wrote:
> >
> > > >
> > > > > Branching anytime before we 4.0.0 adds extra burden to the
> folks
> > trying
> > > > to
> > > > > get 4.0.0 out the door (because of merge up)
> > > >
> > > > Given both that we've done this with every major release in the
> > past, as
> > > > well as the type of work we'd expect to land during the beta
> phase
> > > > (smaller, non-api breaking, defect fixing or smaller performance
> > > tuning), I
> > > > didn't personally originally weigh this as being as much of a
> > burden as
> > > you
> > > > perceive it to be.
> > >
> > >
> > >
> > > Looking at this a different way, you might say we have previously
> > cut the
> > > release branch somewhere around beta. Because previous releases
> > haven't
> > > (all) had so much focus on testing and alphas. My impression is
> that
> > 4.0.0
> > > will be closer compared to a second or third patch of previous
> major
> > > releases.
> > >
> > > So I would have thought it makes sense around beta or RC to branch,
> > > especially RC because between RC and GA it is more about a cooling
> > period,
> > > public acceptance and testing. That RC to GA window should be quiet
> > enough
> > > that it makes sense to branch then, and kick off the CEP
> discussions.
> > >
> > > I don't think the forward merging really is so much of a problem,
> > it's a
> > > normal activity in the C* codebase, and the additional
> merge-forward
> > window
> > > between either beta or RC, to GA is short.
> > >
> > > Thanks Ekaterina and Benjamin and Josh for raising the discussion.
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: [DISCUSS] When to branch 4.0
Posted by Jordan West <jo...@gmail.com>.
On Fri, Jun 26, 2020 at 2:58 PM Benedict Elliott Smith <be...@apache.org>
wrote:
> > Nothing is stopping us for discussing CEPs now, and nothing prevents
> folks from making their own feature branches.
>
> I disagree. CEPs are just as - if not more - of a distraction than
> branching.
>
> Work doesn't happen in a vacuum. Those who are today focusing what
> resources they can on shipping 4.0.0 will have to divert resources to the
> new CEP and feature development happening on the project. It is
> unrealistic to expect otherwise.
>
> We can have a swifter 4.0.0 release, or we can begin earnestly developing
> new features, but we cannot have both.
>
>
Agreed 100% and I would prefer to see us all focus on getting 4.0.0 out. I
only meant we never explicitly voted to prevent CEPs from being submitted
at this time and it was more in response to a comment in the initial email
in this thread.
>
> On 26/06/2020, 22:09, "Jon Haddad" <jo...@jonhaddad.com> wrote:
>
> We currently have 2.1, 2.2, 3.0 3.11, and trunk. With a new branch
> we'll
> _also_ have whatever is next, let's call it 5.0.
>
> Nothing is stopping us for discussing CEPs now, and nothing prevents
> folks
> from making their own feature branches.
>
> If we're going to add another branch (4.0) and let people merge to
> trunk,
> we're making an *active* decision to push the 4.0 release out even
> further,
> because the folks working on it will have to learn the new code when
> they
> merge forward.
>
> I'm -1 on branching before we release 4.0.
>
> On Fri, Jun 26, 2020 at 2:04 PM Mick Semb Wever <mc...@apache.org>
> wrote:
>
> > >
> > > > Branching anytime before we 4.0.0 adds extra burden to the folks
> trying
> > > to
> > > > get 4.0.0 out the door (because of merge up)
> > >
> > > Given both that we've done this with every major release in the
> past, as
> > > well as the type of work we'd expect to land during the beta phase
> > > (smaller, non-api breaking, defect fixing or smaller performance
> > tuning), I
> > > didn't personally originally weigh this as being as much of a
> burden as
> > you
> > > perceive it to be.
> >
> >
> >
> > Looking at this a different way, you might say we have previously
> cut the
> > release branch somewhere around beta. Because previous releases
> haven't
> > (all) had so much focus on testing and alphas. My impression is that
> 4.0.0
> > will be closer compared to a second or third patch of previous major
> > releases.
> >
> > So I would have thought it makes sense around beta or RC to branch,
> > especially RC because between RC and GA it is more about a cooling
> period,
> > public acceptance and testing. That RC to GA window should be quiet
> enough
> > that it makes sense to branch then, and kick off the CEP discussions.
> >
> > I don't think the forward merging really is so much of a problem,
> it's a
> > normal activity in the C* codebase, and the additional merge-forward
> window
> > between either beta or RC, to GA is short.
> >
> > Thanks Ekaterina and Benjamin and Josh for raising the discussion.
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: [DISCUSS] When to branch 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
> Nothing is stopping us for discussing CEPs now, and nothing prevents folks from making their own feature branches.
I disagree. CEPs are just as - if not more - of a distraction than branching.
Work doesn't happen in a vacuum. Those who are today focusing what resources they can on shipping 4.0.0 will have to divert resources to the new CEP and feature development happening on the project. It is unrealistic to expect otherwise.
We can have a swifter 4.0.0 release, or we can begin earnestly developing new features, but we cannot have both.
On 26/06/2020, 22:09, "Jon Haddad" <jo...@jonhaddad.com> wrote:
We currently have 2.1, 2.2, 3.0 3.11, and trunk. With a new branch we'll
_also_ have whatever is next, let's call it 5.0.
Nothing is stopping us for discussing CEPs now, and nothing prevents folks
from making their own feature branches.
If we're going to add another branch (4.0) and let people merge to trunk,
we're making an *active* decision to push the 4.0 release out even further,
because the folks working on it will have to learn the new code when they
merge forward.
I'm -1 on branching before we release 4.0.
On Fri, Jun 26, 2020 at 2:04 PM Mick Semb Wever <mc...@apache.org> wrote:
> >
> > > Branching anytime before we 4.0.0 adds extra burden to the folks trying
> > to
> > > get 4.0.0 out the door (because of merge up)
> >
> > Given both that we've done this with every major release in the past, as
> > well as the type of work we'd expect to land during the beta phase
> > (smaller, non-api breaking, defect fixing or smaller performance
> tuning), I
> > didn't personally originally weigh this as being as much of a burden as
> you
> > perceive it to be.
>
>
>
> Looking at this a different way, you might say we have previously cut the
> release branch somewhere around beta. Because previous releases haven't
> (all) had so much focus on testing and alphas. My impression is that 4.0.0
> will be closer compared to a second or third patch of previous major
> releases.
>
> So I would have thought it makes sense around beta or RC to branch,
> especially RC because between RC and GA it is more about a cooling period,
> public acceptance and testing. That RC to GA window should be quiet enough
> that it makes sense to branch then, and kick off the CEP discussions.
>
> I don't think the forward merging really is so much of a problem, it's a
> normal activity in the C* codebase, and the additional merge-forward window
> between either beta or RC, to GA is short.
>
> Thanks Ekaterina and Benjamin and Josh for raising the discussion.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] When to branch 4.0
Posted by Jon Haddad <jo...@jonhaddad.com>.
We currently have 2.1, 2.2, 3.0 3.11, and trunk. With a new branch we'll
_also_ have whatever is next, let's call it 5.0.
Nothing is stopping us for discussing CEPs now, and nothing prevents folks
from making their own feature branches.
If we're going to add another branch (4.0) and let people merge to trunk,
we're making an *active* decision to push the 4.0 release out even further,
because the folks working on it will have to learn the new code when they
merge forward.
I'm -1 on branching before we release 4.0.
On Fri, Jun 26, 2020 at 2:04 PM Mick Semb Wever <mc...@apache.org> wrote:
> >
> > > Branching anytime before we 4.0.0 adds extra burden to the folks trying
> > to
> > > get 4.0.0 out the door (because of merge up)
> >
> > Given both that we've done this with every major release in the past, as
> > well as the type of work we'd expect to land during the beta phase
> > (smaller, non-api breaking, defect fixing or smaller performance
> tuning), I
> > didn't personally originally weigh this as being as much of a burden as
> you
> > perceive it to be.
>
>
>
> Looking at this a different way, you might say we have previously cut the
> release branch somewhere around beta. Because previous releases haven't
> (all) had so much focus on testing and alphas. My impression is that 4.0.0
> will be closer compared to a second or third patch of previous major
> releases.
>
> So I would have thought it makes sense around beta or RC to branch,
> especially RC because between RC and GA it is more about a cooling period,
> public acceptance and testing. That RC to GA window should be quiet enough
> that it makes sense to branch then, and kick off the CEP discussions.
>
> I don't think the forward merging really is so much of a problem, it's a
> normal activity in the C* codebase, and the additional merge-forward window
> between either beta or RC, to GA is short.
>
> Thanks Ekaterina and Benjamin and Josh for raising the discussion.
>
Re: [DISCUSS] When to branch 4.0
Posted by Mick Semb Wever <mc...@apache.org>.
>
> > Branching anytime before we 4.0.0 adds extra burden to the folks trying
> to
> > get 4.0.0 out the door (because of merge up)
>
> Given both that we've done this with every major release in the past, as
> well as the type of work we'd expect to land during the beta phase
> (smaller, non-api breaking, defect fixing or smaller performance tuning), I
> didn't personally originally weigh this as being as much of a burden as you
> perceive it to be.
Looking at this a different way, you might say we have previously cut the
release branch somewhere around beta. Because previous releases haven't
(all) had so much focus on testing and alphas. My impression is that 4.0.0
will be closer compared to a second or third patch of previous major
releases.
So I would have thought it makes sense around beta or RC to branch,
especially RC because between RC and GA it is more about a cooling period,
public acceptance and testing. That RC to GA window should be quiet enough
that it makes sense to branch then, and kick off the CEP discussions.
I don't think the forward merging really is so much of a problem, it's a
normal activity in the C* codebase, and the additional merge-forward window
between either beta or RC, to GA is short.
Thanks Ekaterina and Benjamin and Josh for raising the discussion.
Re: [DISCUSS] When to branch 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
Ok, I'm sorry for reaching the opposite conclusion before reading this email - the implication here instead appears to be that, you believe, people are advocating to integrate work that should be deferred - is that correct? Perhaps we should have a direct conversation about the tickets you consider this to be the case for?
FWIW, I don't think this is a rational strategy for appeasing anybody pushing for inclusion in this release, given that cutting a new branch says nothing about the timeline for its release.
On 26/06/2020, 19:58, "Joshua McKenzie" <jm...@apache.org> wrote:
I was speaking with Ekaterina and Benjamin about some of the currently
alpha scoped work which is what made me think of this dynamic. There's a
very different dynamic from "if we push this out to the next major, this
code will atrophy for 3-6 months" vs. "if we push this out to the next
major, you should still be able to merge this shortly so it's not as high a
merge cost."
Given our difficulty getting 4.0 out the door, my original thinking was
that having *less* disincentives to pushing out optional work would help us
make more objective decisions about when to hold a release for a ticket vs.
when to push the ticket. I suspect we'll go through something similar when
looking at the scope during beta for non-API breaking code that could
instead live in a patch release or a follow-up major. In my opinion we lack
clarity around scoping of this release and don't seem to have a
project-wide consensus on how we're handling this.
I'm reading an assumption that this is about CEP's and major features;
while there's a non-trivial body of work on the wiki as draft CEP's at this
time, those have not been brought to the mailing list out of respect for
multiple direct requests earlier this year not to distract from work on
getting 4.0 out the door.
Branching anytime before we 4.0.0 adds extra burden to the folks trying to
> get 4.0.0 out the door (because of merge up)
Given both that we've done this with every major release in the past, as
well as the type of work we'd expect to land during the beta phase
(smaller, non-api breaking, defect fixing or smaller performance tuning), I
didn't personally originally weigh this as being as much of a burden as you
perceive it to be. I'm curious to hear more about this.
~Josh
On Fri, Jun 26, 2020 at 1:12 PM Jon Haddad <jo...@jonhaddad.com> wrote:
> I was originally against the trunk freeze because I didn't want it to
> prevent progress, now I'm 100% on board with it and I think we should keep
> it in place till we release 4.0.0.
>
> Branching anytime before we 4.0.0 adds extra burden to the folks trying to
> get 4.0.0 out the door (because of merge up), which means it'll take
> longer. Anyone taking issue with how long it's taken so far to get 4.0 out
> should recognize that if we branch and start allowing new features, we're
> going to take even longer to get 4.0 out. At this point 4.0 is turning
> into somewhat of a running joke, like Duke Nukem Forever.
>
> We can't have the next release come faster, merge new features, and have
> quality be up to the bar we've all aimed to achieve (classic good fast
> cheap scenario). We've got a tradeoff here. If folks are advocating we
> branch anytime before we release & unfreeze trunk, they'd better be
> prepared for the consequences of an even further delayed release. Did
> anyone ever think we'd possibly be frozen till 2021?
>
> After 4.0, we *really* need to start focusing on refactoring the codebase
> to improve modularity and testability so we don't have to ever go through
> this multi-year process again, because it's incredibly unhealthy to have to
> freeze trunk this long. I think a lot of people are frustrated, and I get
> it, but I don't think the path to improving our collective position is to
> say "screw it" and branch any earlier than the 4.0.0 release.
>
>
>
> On Fri, Jun 26, 2020 at 9:26 AM Jordan West <jo...@gmail.com> wrote:
>
> > Thanks for bringing this up Josh. I think the last time we all discussed
> > this on the mailing list was during the initial freeze thread where we
> > agreed "that between the September freeze date and beta, a new branch
> would
> > not be created and trunk would only have bug fixes and performance
> > improvements committed to it." Now that we are closer to beta and have a
> > more formal governance model I think its good to revisit.
> >
> > I'm torn. Folks should absolutely be able to scratch an itch as part of
> the
> > ethos of the project but we also haven't made substantial progress on the
> > testing epic -- less than I expected when I was +1 to branch at beta in
> the
> > initial proposal. A few general thoughts come to mind around this:
> >
> > - Does not having a target branch truly discourage folks from scratching
> an
> > itch? Is the lack of a timeline on when they could actually see that
> merge
> > in a release more substantial?
> >
> > - Regarding timeline (and scope), I wonder if we would be better
> branching
> > after we have a bit more of an idea of our future process and
> development /
> > release lifecycle. Perhaps we should discuss that first?
> >
> > - I haven't seen any CEPs, etc for major features. These discussions
> aren't
> > blocked by the freeze and would presumably precede any need to merge to
> > trunk?
> >
> > - For smaller changes that don't need CEPs, I know maintaining a long
> > running branch can be a pain but I would like to better understand how
> many
> > of these are truly out there before asking the committers to maintain and
> > merge into a 4th branch (which is not super challenging but is measurable
> > overhead).
> >
> > Jordan
> >
> > On Fri, Jun 26, 2020 at 6:43 AM Joshua McKenzie <jm...@apache.org>
> > wrote:
> >
> > > As we close on cutting beta1, a new consequence of our release
> lifecycle
> > is
> > > becoming apparent. With guarantees of API stability in the beta phase,
> > any
> > > work that is deferred from alpha to the next major due to API impacting
> > > changes will atrophy for as long as the beta is active.
> > >
> > > Cutting a branch for the 4.0 line upon release of beta1 would mitigate
> > this
> > > problem and allow work in flight to be merged in, as well as unblock
> the
> > > work of others who may not be focusing on testing 4.0, whether it be
> due
> > to
> > > their interest and focus or due to saturation on the work in scope for
> > the
> > > release.
> > >
> > > The obvious downsides to cutting a branch of a major and allowing dev
> on
> > > trunk to continue separately is 1) the need to merge up to trunk on
> > changes
> > > going into beta, and 2) a risk of a lack of focus on testing the
> release
> > > due to the availability of developing on trunk. My personal thoughts on
> > > those two points:
> > >
> > > 1) changes going into beta should be small enough that a fast-forward
> > merge
> > > should be available in the majority of cases up to trunk. We've done
> this
> > > with previous releases and it wasn't prohibitively expensive in terms
> of
> > > time. Further, I would posit that changes going into beta should be on
> > the
> > > smaller side, further mitigating the burden of this process.
> > >
> > > 2) We've been feature frozen since late 2018 with the expressed
> intention
> > > to encourage work on testing and stabilizing 4.0. I am not aware of any
> > > contributors whose time and energy has been invested in testing 4.0
> that
> > > would otherwise have gone to trunk (i.e. this approach achieving its
> > > desired outcomes), however I do know of several major contributors and
> > > contributions that have atrophied and been deterred from further work
> on
> > > the project due to waiting for 4.0 to release.
> > >
> > > I don't think it's appropriate for us as an existing body of
> contributors
> > > to mandate either how each other or more detrimentally how other new
> > > contributors engage with and contribute to the project by disallowing
> > > contributions past 4.0; I take the position that we should do
> everything
> > > reasonably possible to encourage a diversity of contributions to the
> > > project. I deeply believe that making deliberate decisions to
> prioritize
> > > new engagement and interaction on the project as the context in which
> > it's
> > > used evolves is vital to the project's health long term.
> > >
> > > That's just my .02 - I'd be curious to hear what everyone else thinks.
> > >
> > > ~Josh
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] When to branch 4.0
Posted by Joshua McKenzie <jm...@apache.org>.
I was speaking with Ekaterina and Benjamin about some of the currently
alpha scoped work which is what made me think of this dynamic. There's a
very different dynamic from "if we push this out to the next major, this
code will atrophy for 3-6 months" vs. "if we push this out to the next
major, you should still be able to merge this shortly so it's not as high a
merge cost."
Given our difficulty getting 4.0 out the door, my original thinking was
that having *less* disincentives to pushing out optional work would help us
make more objective decisions about when to hold a release for a ticket vs.
when to push the ticket. I suspect we'll go through something similar when
looking at the scope during beta for non-API breaking code that could
instead live in a patch release or a follow-up major. In my opinion we lack
clarity around scoping of this release and don't seem to have a
project-wide consensus on how we're handling this.
I'm reading an assumption that this is about CEP's and major features;
while there's a non-trivial body of work on the wiki as draft CEP's at this
time, those have not been brought to the mailing list out of respect for
multiple direct requests earlier this year not to distract from work on
getting 4.0 out the door.
Branching anytime before we 4.0.0 adds extra burden to the folks trying to
> get 4.0.0 out the door (because of merge up)
Given both that we've done this with every major release in the past, as
well as the type of work we'd expect to land during the beta phase
(smaller, non-api breaking, defect fixing or smaller performance tuning), I
didn't personally originally weigh this as being as much of a burden as you
perceive it to be. I'm curious to hear more about this.
~Josh
On Fri, Jun 26, 2020 at 1:12 PM Jon Haddad <jo...@jonhaddad.com> wrote:
> I was originally against the trunk freeze because I didn't want it to
> prevent progress, now I'm 100% on board with it and I think we should keep
> it in place till we release 4.0.0.
>
> Branching anytime before we 4.0.0 adds extra burden to the folks trying to
> get 4.0.0 out the door (because of merge up), which means it'll take
> longer. Anyone taking issue with how long it's taken so far to get 4.0 out
> should recognize that if we branch and start allowing new features, we're
> going to take even longer to get 4.0 out. At this point 4.0 is turning
> into somewhat of a running joke, like Duke Nukem Forever.
>
> We can't have the next release come faster, merge new features, and have
> quality be up to the bar we've all aimed to achieve (classic good fast
> cheap scenario). We've got a tradeoff here. If folks are advocating we
> branch anytime before we release & unfreeze trunk, they'd better be
> prepared for the consequences of an even further delayed release. Did
> anyone ever think we'd possibly be frozen till 2021?
>
> After 4.0, we *really* need to start focusing on refactoring the codebase
> to improve modularity and testability so we don't have to ever go through
> this multi-year process again, because it's incredibly unhealthy to have to
> freeze trunk this long. I think a lot of people are frustrated, and I get
> it, but I don't think the path to improving our collective position is to
> say "screw it" and branch any earlier than the 4.0.0 release.
>
>
>
> On Fri, Jun 26, 2020 at 9:26 AM Jordan West <jo...@gmail.com> wrote:
>
> > Thanks for bringing this up Josh. I think the last time we all discussed
> > this on the mailing list was during the initial freeze thread where we
> > agreed "that between the September freeze date and beta, a new branch
> would
> > not be created and trunk would only have bug fixes and performance
> > improvements committed to it." Now that we are closer to beta and have a
> > more formal governance model I think its good to revisit.
> >
> > I'm torn. Folks should absolutely be able to scratch an itch as part of
> the
> > ethos of the project but we also haven't made substantial progress on the
> > testing epic -- less than I expected when I was +1 to branch at beta in
> the
> > initial proposal. A few general thoughts come to mind around this:
> >
> > - Does not having a target branch truly discourage folks from scratching
> an
> > itch? Is the lack of a timeline on when they could actually see that
> merge
> > in a release more substantial?
> >
> > - Regarding timeline (and scope), I wonder if we would be better
> branching
> > after we have a bit more of an idea of our future process and
> development /
> > release lifecycle. Perhaps we should discuss that first?
> >
> > - I haven't seen any CEPs, etc for major features. These discussions
> aren't
> > blocked by the freeze and would presumably precede any need to merge to
> > trunk?
> >
> > - For smaller changes that don't need CEPs, I know maintaining a long
> > running branch can be a pain but I would like to better understand how
> many
> > of these are truly out there before asking the committers to maintain and
> > merge into a 4th branch (which is not super challenging but is measurable
> > overhead).
> >
> > Jordan
> >
> > On Fri, Jun 26, 2020 at 6:43 AM Joshua McKenzie <jm...@apache.org>
> > wrote:
> >
> > > As we close on cutting beta1, a new consequence of our release
> lifecycle
> > is
> > > becoming apparent. With guarantees of API stability in the beta phase,
> > any
> > > work that is deferred from alpha to the next major due to API impacting
> > > changes will atrophy for as long as the beta is active.
> > >
> > > Cutting a branch for the 4.0 line upon release of beta1 would mitigate
> > this
> > > problem and allow work in flight to be merged in, as well as unblock
> the
> > > work of others who may not be focusing on testing 4.0, whether it be
> due
> > to
> > > their interest and focus or due to saturation on the work in scope for
> > the
> > > release.
> > >
> > > The obvious downsides to cutting a branch of a major and allowing dev
> on
> > > trunk to continue separately is 1) the need to merge up to trunk on
> > changes
> > > going into beta, and 2) a risk of a lack of focus on testing the
> release
> > > due to the availability of developing on trunk. My personal thoughts on
> > > those two points:
> > >
> > > 1) changes going into beta should be small enough that a fast-forward
> > merge
> > > should be available in the majority of cases up to trunk. We've done
> this
> > > with previous releases and it wasn't prohibitively expensive in terms
> of
> > > time. Further, I would posit that changes going into beta should be on
> > the
> > > smaller side, further mitigating the burden of this process.
> > >
> > > 2) We've been feature frozen since late 2018 with the expressed
> intention
> > > to encourage work on testing and stabilizing 4.0. I am not aware of any
> > > contributors whose time and energy has been invested in testing 4.0
> that
> > > would otherwise have gone to trunk (i.e. this approach achieving its
> > > desired outcomes), however I do know of several major contributors and
> > > contributions that have atrophied and been deterred from further work
> on
> > > the project due to waiting for 4.0 to release.
> > >
> > > I don't think it's appropriate for us as an existing body of
> contributors
> > > to mandate either how each other or more detrimentally how other new
> > > contributors engage with and contribute to the project by disallowing
> > > contributions past 4.0; I take the position that we should do
> everything
> > > reasonably possible to encourage a diversity of contributions to the
> > > project. I deeply believe that making deliberate decisions to
> prioritize
> > > new engagement and interaction on the project as the context in which
> > it's
> > > used evolves is vital to the project's health long term.
> > >
> > > That's just my .02 - I'd be curious to hear what everyone else thinks.
> > >
> > > ~Josh
> > >
> >
>
Re: [DISCUSS] When to branch 4.0
Posted by Benedict Elliott Smith <be...@apache.org>.
--> Branching anytime before we 4.0.0 adds extra burden to the folks trying to get 4.0.0
This. This is all that matters IMO. Some have been saying 4.0.0 is very delayed, and that this harms the project - and they're right. So I'm surprised to see those same voices advocating we prioritise their feature development instead?
On 26/06/2020, 18:12, "Jon Haddad" <jo...@jonhaddad.com> wrote:
I was originally against the trunk freeze because I didn't want it to
prevent progress, now I'm 100% on board with it and I think we should keep
it in place till we release 4.0.0.
Branching anytime before we 4.0.0 adds extra burden to the folks trying to
get 4.0.0 out the door (because of merge up), which means it'll take
longer. Anyone taking issue with how long it's taken so far to get 4.0 out
should recognize that if we branch and start allowing new features, we're
going to take even longer to get 4.0 out. At this point 4.0 is turning
into somewhat of a running joke, like Duke Nukem Forever.
We can't have the next release come faster, merge new features, and have
quality be up to the bar we've all aimed to achieve (classic good fast
cheap scenario). We've got a tradeoff here. If folks are advocating we
branch anytime before we release & unfreeze trunk, they'd better be
prepared for the consequences of an even further delayed release. Did
anyone ever think we'd possibly be frozen till 2021?
After 4.0, we *really* need to start focusing on refactoring the codebase
to improve modularity and testability so we don't have to ever go through
this multi-year process again, because it's incredibly unhealthy to have to
freeze trunk this long. I think a lot of people are frustrated, and I get
it, but I don't think the path to improving our collective position is to
say "screw it" and branch any earlier than the 4.0.0 release.
On Fri, Jun 26, 2020 at 9:26 AM Jordan West <jo...@gmail.com> wrote:
> Thanks for bringing this up Josh. I think the last time we all discussed
> this on the mailing list was during the initial freeze thread where we
> agreed "that between the September freeze date and beta, a new branch would
> not be created and trunk would only have bug fixes and performance
> improvements committed to it." Now that we are closer to beta and have a
> more formal governance model I think its good to revisit.
>
> I'm torn. Folks should absolutely be able to scratch an itch as part of the
> ethos of the project but we also haven't made substantial progress on the
> testing epic -- less than I expected when I was +1 to branch at beta in the
> initial proposal. A few general thoughts come to mind around this:
>
> - Does not having a target branch truly discourage folks from scratching an
> itch? Is the lack of a timeline on when they could actually see that merge
> in a release more substantial?
>
> - Regarding timeline (and scope), I wonder if we would be better branching
> after we have a bit more of an idea of our future process and development /
> release lifecycle. Perhaps we should discuss that first?
>
> - I haven't seen any CEPs, etc for major features. These discussions aren't
> blocked by the freeze and would presumably precede any need to merge to
> trunk?
>
> - For smaller changes that don't need CEPs, I know maintaining a long
> running branch can be a pain but I would like to better understand how many
> of these are truly out there before asking the committers to maintain and
> merge into a 4th branch (which is not super challenging but is measurable
> overhead).
>
> Jordan
>
> On Fri, Jun 26, 2020 at 6:43 AM Joshua McKenzie <jm...@apache.org>
> wrote:
>
> > As we close on cutting beta1, a new consequence of our release lifecycle
> is
> > becoming apparent. With guarantees of API stability in the beta phase,
> any
> > work that is deferred from alpha to the next major due to API impacting
> > changes will atrophy for as long as the beta is active.
> >
> > Cutting a branch for the 4.0 line upon release of beta1 would mitigate
> this
> > problem and allow work in flight to be merged in, as well as unblock the
> > work of others who may not be focusing on testing 4.0, whether it be due
> to
> > their interest and focus or due to saturation on the work in scope for
> the
> > release.
> >
> > The obvious downsides to cutting a branch of a major and allowing dev on
> > trunk to continue separately is 1) the need to merge up to trunk on
> changes
> > going into beta, and 2) a risk of a lack of focus on testing the release
> > due to the availability of developing on trunk. My personal thoughts on
> > those two points:
> >
> > 1) changes going into beta should be small enough that a fast-forward
> merge
> > should be available in the majority of cases up to trunk. We've done this
> > with previous releases and it wasn't prohibitively expensive in terms of
> > time. Further, I would posit that changes going into beta should be on
> the
> > smaller side, further mitigating the burden of this process.
> >
> > 2) We've been feature frozen since late 2018 with the expressed intention
> > to encourage work on testing and stabilizing 4.0. I am not aware of any
> > contributors whose time and energy has been invested in testing 4.0 that
> > would otherwise have gone to trunk (i.e. this approach achieving its
> > desired outcomes), however I do know of several major contributors and
> > contributions that have atrophied and been deterred from further work on
> > the project due to waiting for 4.0 to release.
> >
> > I don't think it's appropriate for us as an existing body of contributors
> > to mandate either how each other or more detrimentally how other new
> > contributors engage with and contribute to the project by disallowing
> > contributions past 4.0; I take the position that we should do everything
> > reasonably possible to encourage a diversity of contributions to the
> > project. I deeply believe that making deliberate decisions to prioritize
> > new engagement and interaction on the project as the context in which
> it's
> > used evolves is vital to the project's health long term.
> >
> > That's just my .02 - I'd be curious to hear what everyone else thinks.
> >
> > ~Josh
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: [DISCUSS] When to branch 4.0
Posted by Jon Haddad <jo...@jonhaddad.com>.
I was originally against the trunk freeze because I didn't want it to
prevent progress, now I'm 100% on board with it and I think we should keep
it in place till we release 4.0.0.
Branching anytime before we 4.0.0 adds extra burden to the folks trying to
get 4.0.0 out the door (because of merge up), which means it'll take
longer. Anyone taking issue with how long it's taken so far to get 4.0 out
should recognize that if we branch and start allowing new features, we're
going to take even longer to get 4.0 out. At this point 4.0 is turning
into somewhat of a running joke, like Duke Nukem Forever.
We can't have the next release come faster, merge new features, and have
quality be up to the bar we've all aimed to achieve (classic good fast
cheap scenario). We've got a tradeoff here. If folks are advocating we
branch anytime before we release & unfreeze trunk, they'd better be
prepared for the consequences of an even further delayed release. Did
anyone ever think we'd possibly be frozen till 2021?
After 4.0, we *really* need to start focusing on refactoring the codebase
to improve modularity and testability so we don't have to ever go through
this multi-year process again, because it's incredibly unhealthy to have to
freeze trunk this long. I think a lot of people are frustrated, and I get
it, but I don't think the path to improving our collective position is to
say "screw it" and branch any earlier than the 4.0.0 release.
On Fri, Jun 26, 2020 at 9:26 AM Jordan West <jo...@gmail.com> wrote:
> Thanks for bringing this up Josh. I think the last time we all discussed
> this on the mailing list was during the initial freeze thread where we
> agreed "that between the September freeze date and beta, a new branch would
> not be created and trunk would only have bug fixes and performance
> improvements committed to it." Now that we are closer to beta and have a
> more formal governance model I think its good to revisit.
>
> I'm torn. Folks should absolutely be able to scratch an itch as part of the
> ethos of the project but we also haven't made substantial progress on the
> testing epic -- less than I expected when I was +1 to branch at beta in the
> initial proposal. A few general thoughts come to mind around this:
>
> - Does not having a target branch truly discourage folks from scratching an
> itch? Is the lack of a timeline on when they could actually see that merge
> in a release more substantial?
>
> - Regarding timeline (and scope), I wonder if we would be better branching
> after we have a bit more of an idea of our future process and development /
> release lifecycle. Perhaps we should discuss that first?
>
> - I haven't seen any CEPs, etc for major features. These discussions aren't
> blocked by the freeze and would presumably precede any need to merge to
> trunk?
>
> - For smaller changes that don't need CEPs, I know maintaining a long
> running branch can be a pain but I would like to better understand how many
> of these are truly out there before asking the committers to maintain and
> merge into a 4th branch (which is not super challenging but is measurable
> overhead).
>
> Jordan
>
> On Fri, Jun 26, 2020 at 6:43 AM Joshua McKenzie <jm...@apache.org>
> wrote:
>
> > As we close on cutting beta1, a new consequence of our release lifecycle
> is
> > becoming apparent. With guarantees of API stability in the beta phase,
> any
> > work that is deferred from alpha to the next major due to API impacting
> > changes will atrophy for as long as the beta is active.
> >
> > Cutting a branch for the 4.0 line upon release of beta1 would mitigate
> this
> > problem and allow work in flight to be merged in, as well as unblock the
> > work of others who may not be focusing on testing 4.0, whether it be due
> to
> > their interest and focus or due to saturation on the work in scope for
> the
> > release.
> >
> > The obvious downsides to cutting a branch of a major and allowing dev on
> > trunk to continue separately is 1) the need to merge up to trunk on
> changes
> > going into beta, and 2) a risk of a lack of focus on testing the release
> > due to the availability of developing on trunk. My personal thoughts on
> > those two points:
> >
> > 1) changes going into beta should be small enough that a fast-forward
> merge
> > should be available in the majority of cases up to trunk. We've done this
> > with previous releases and it wasn't prohibitively expensive in terms of
> > time. Further, I would posit that changes going into beta should be on
> the
> > smaller side, further mitigating the burden of this process.
> >
> > 2) We've been feature frozen since late 2018 with the expressed intention
> > to encourage work on testing and stabilizing 4.0. I am not aware of any
> > contributors whose time and energy has been invested in testing 4.0 that
> > would otherwise have gone to trunk (i.e. this approach achieving its
> > desired outcomes), however I do know of several major contributors and
> > contributions that have atrophied and been deterred from further work on
> > the project due to waiting for 4.0 to release.
> >
> > I don't think it's appropriate for us as an existing body of contributors
> > to mandate either how each other or more detrimentally how other new
> > contributors engage with and contribute to the project by disallowing
> > contributions past 4.0; I take the position that we should do everything
> > reasonably possible to encourage a diversity of contributions to the
> > project. I deeply believe that making deliberate decisions to prioritize
> > new engagement and interaction on the project as the context in which
> it's
> > used evolves is vital to the project's health long term.
> >
> > That's just my .02 - I'd be curious to hear what everyone else thinks.
> >
> > ~Josh
> >
>
Re: [DISCUSS] When to branch 4.0
Posted by Jordan West <jo...@gmail.com>.
Thanks for bringing this up Josh. I think the last time we all discussed
this on the mailing list was during the initial freeze thread where we
agreed "that between the September freeze date and beta, a new branch would
not be created and trunk would only have bug fixes and performance
improvements committed to it." Now that we are closer to beta and have a
more formal governance model I think its good to revisit.
I'm torn. Folks should absolutely be able to scratch an itch as part of the
ethos of the project but we also haven't made substantial progress on the
testing epic -- less than I expected when I was +1 to branch at beta in the
initial proposal. A few general thoughts come to mind around this:
- Does not having a target branch truly discourage folks from scratching an
itch? Is the lack of a timeline on when they could actually see that merge
in a release more substantial?
- Regarding timeline (and scope), I wonder if we would be better branching
after we have a bit more of an idea of our future process and development /
release lifecycle. Perhaps we should discuss that first?
- I haven't seen any CEPs, etc for major features. These discussions aren't
blocked by the freeze and would presumably precede any need to merge to
trunk?
- For smaller changes that don't need CEPs, I know maintaining a long
running branch can be a pain but I would like to better understand how many
of these are truly out there before asking the committers to maintain and
merge into a 4th branch (which is not super challenging but is measurable
overhead).
Jordan
On Fri, Jun 26, 2020 at 6:43 AM Joshua McKenzie <jm...@apache.org>
wrote:
> As we close on cutting beta1, a new consequence of our release lifecycle is
> becoming apparent. With guarantees of API stability in the beta phase, any
> work that is deferred from alpha to the next major due to API impacting
> changes will atrophy for as long as the beta is active.
>
> Cutting a branch for the 4.0 line upon release of beta1 would mitigate this
> problem and allow work in flight to be merged in, as well as unblock the
> work of others who may not be focusing on testing 4.0, whether it be due to
> their interest and focus or due to saturation on the work in scope for the
> release.
>
> The obvious downsides to cutting a branch of a major and allowing dev on
> trunk to continue separately is 1) the need to merge up to trunk on changes
> going into beta, and 2) a risk of a lack of focus on testing the release
> due to the availability of developing on trunk. My personal thoughts on
> those two points:
>
> 1) changes going into beta should be small enough that a fast-forward merge
> should be available in the majority of cases up to trunk. We've done this
> with previous releases and it wasn't prohibitively expensive in terms of
> time. Further, I would posit that changes going into beta should be on the
> smaller side, further mitigating the burden of this process.
>
> 2) We've been feature frozen since late 2018 with the expressed intention
> to encourage work on testing and stabilizing 4.0. I am not aware of any
> contributors whose time and energy has been invested in testing 4.0 that
> would otherwise have gone to trunk (i.e. this approach achieving its
> desired outcomes), however I do know of several major contributors and
> contributions that have atrophied and been deterred from further work on
> the project due to waiting for 4.0 to release.
>
> I don't think it's appropriate for us as an existing body of contributors
> to mandate either how each other or more detrimentally how other new
> contributors engage with and contribute to the project by disallowing
> contributions past 4.0; I take the position that we should do everything
> reasonably possible to encourage a diversity of contributions to the
> project. I deeply believe that making deliberate decisions to prioritize
> new engagement and interaction on the project as the context in which it's
> used evolves is vital to the project's health long term.
>
> That's just my .02 - I'd be curious to hear what everyone else thinks.
>
> ~Josh
>
Re: [DISCUSS] When to branch 4.0
Posted by Ekaterina Dimitrova <e....@gmail.com>.
I think that this goes well with the philosophy of the open source and
volunteering contributions.
Also, it could really open the door for more new features and people
contributing to the project in the long term.
Ekaterina
On Fri, 26 Jun 2020 at 10:44, Sylvain Lebresne <le...@gmail.com> wrote:
> Fwiw, I agree with that POV in general (that it's probably beneficial on
> balance to branch now/soonish for the reasonings Josh mentioned).
> --
> Sylvain
>
>
> On Fri, Jun 26, 2020 at 3:43 PM Joshua McKenzie <jm...@apache.org>
> wrote:
>
> > As we close on cutting beta1, a new consequence of our release lifecycle
> is
> > becoming apparent. With guarantees of API stability in the beta phase,
> any
> > work that is deferred from alpha to the next major due to API impacting
> > changes will atrophy for as long as the beta is active.
> >
> > Cutting a branch for the 4.0 line upon release of beta1 would mitigate
> this
> > problem and allow work in flight to be merged in, as well as unblock the
> > work of others who may not be focusing on testing 4.0, whether it be due
> to
> > their interest and focus or due to saturation on the work in scope for
> the
> > release.
> >
> > The obvious downsides to cutting a branch of a major and allowing dev on
> > trunk to continue separately is 1) the need to merge up to trunk on
> changes
> > going into beta, and 2) a risk of a lack of focus on testing the release
> > due to the availability of developing on trunk. My personal thoughts on
> > those two points:
> >
> > 1) changes going into beta should be small enough that a fast-forward
> merge
> > should be available in the majority of cases up to trunk. We've done this
> > with previous releases and it wasn't prohibitively expensive in terms of
> > time. Further, I would posit that changes going into beta should be on
> the
> > smaller side, further mitigating the burden of this process.
> >
> > 2) We've been feature frozen since late 2018 with the expressed intention
> > to encourage work on testing and stabilizing 4.0. I am not aware of any
> > contributors whose time and energy has been invested in testing 4.0 that
> > would otherwise have gone to trunk (i.e. this approach achieving its
> > desired outcomes), however I do know of several major contributors and
> > contributions that have atrophied and been deterred from further work on
> > the project due to waiting for 4.0 to release.
> >
> > I don't think it's appropriate for us as an existing body of contributors
> > to mandate either how each other or more detrimentally how other new
> > contributors engage with and contribute to the project by disallowing
> > contributions past 4.0; I take the position that we should do everything
> > reasonably possible to encourage a diversity of contributions to the
> > project. I deeply believe that making deliberate decisions to prioritize
> > new engagement and interaction on the project as the context in which
> it's
> > used evolves is vital to the project's health long term.
> >
> > That's just my .02 - I'd be curious to hear what everyone else thinks.
> >
> > ~Josh
> >
>
Re: [DISCUSS] When to branch 4.0
Posted by Sylvain Lebresne <le...@gmail.com>.
Fwiw, I agree with that POV in general (that it's probably beneficial on
balance to branch now/soonish for the reasonings Josh mentioned).
--
Sylvain
On Fri, Jun 26, 2020 at 3:43 PM Joshua McKenzie <jm...@apache.org>
wrote:
> As we close on cutting beta1, a new consequence of our release lifecycle is
> becoming apparent. With guarantees of API stability in the beta phase, any
> work that is deferred from alpha to the next major due to API impacting
> changes will atrophy for as long as the beta is active.
>
> Cutting a branch for the 4.0 line upon release of beta1 would mitigate this
> problem and allow work in flight to be merged in, as well as unblock the
> work of others who may not be focusing on testing 4.0, whether it be due to
> their interest and focus or due to saturation on the work in scope for the
> release.
>
> The obvious downsides to cutting a branch of a major and allowing dev on
> trunk to continue separately is 1) the need to merge up to trunk on changes
> going into beta, and 2) a risk of a lack of focus on testing the release
> due to the availability of developing on trunk. My personal thoughts on
> those two points:
>
> 1) changes going into beta should be small enough that a fast-forward merge
> should be available in the majority of cases up to trunk. We've done this
> with previous releases and it wasn't prohibitively expensive in terms of
> time. Further, I would posit that changes going into beta should be on the
> smaller side, further mitigating the burden of this process.
>
> 2) We've been feature frozen since late 2018 with the expressed intention
> to encourage work on testing and stabilizing 4.0. I am not aware of any
> contributors whose time and energy has been invested in testing 4.0 that
> would otherwise have gone to trunk (i.e. this approach achieving its
> desired outcomes), however I do know of several major contributors and
> contributions that have atrophied and been deterred from further work on
> the project due to waiting for 4.0 to release.
>
> I don't think it's appropriate for us as an existing body of contributors
> to mandate either how each other or more detrimentally how other new
> contributors engage with and contribute to the project by disallowing
> contributions past 4.0; I take the position that we should do everything
> reasonably possible to encourage a diversity of contributions to the
> project. I deeply believe that making deliberate decisions to prioritize
> new engagement and interaction on the project as the context in which it's
> used evolves is vital to the project's health long term.
>
> That's just my .02 - I'd be curious to hear what everyone else thinks.
>
> ~Josh
>