Re: Testing 4.0 Post-Freeze

[kurt greaves]

Correct.

On Wed., 4 Jul. 2018, 15:21 sankalp kohli,  wrote:

> Hi Kurt,
>Thank you for your feedback. I am reading your comment as +1 on
> the idea of working on making a solid release but +0 on branching model. Is
> that correct?
> Thanks,
> Sankalp
>
> On Tue, Jul 3, 2018 at 10:09 PM kurt greaves  wrote:
>
> > >
> > > but by committing to reserving trunk for stabilizing changes until the
> > > beta, we focus our effort on polishing and delivering the release.
> >
> > No, committing to testing, bug fixing, and validating focuses our effort
> on
> > polishing and delivering the release.
> > Committing to reserving trunk for stabilising changes doesn't actually do
> > anything. We could reserve trunk and no one could ever commit a single
> > patch to it, or we could reserve trunk and everyone continues working on
> > features. Whatever we do to trunk doesn't have any impact on how our
> > attention is directed.
> >
> > Granted, you could argue that there is some great beneficial
> psychological
> > aspect and having no feature branch will make everyone suddenly start
> > working on bug fixes, but to people this actually affects (committers),
> > it's not going to mean much to them. They are either already going to be
> > motivated and tasked with getting 4.0 out the door, or they are going to
> do
> > their own thing.
> >
> > I'm fairly positive that better communication around the release, and
> > progress towards the release would be a better motivator. And it would go
> > further to getting new contributors (who definitely don't care about the
> > branches) involved, because anyone on the ML could see progress getting
> > made and be a part of any call to arms.
> >
> > But at the end of the day, bikeshedding about this is not important. This
> > is one of those issues which someone should just stand up and say "We're
> > doing it this way because I said so", because either way, it really
> doesn't
> > matter and the impact is going to be minimal, so we may as well get on
> with
> > our lives.
> >
> > On 4 July 2018 at 04:06, Scott Andreas  wrote:
> >
> > > Here’s why I really like this proposal:
> > >
> > > – It focuses our thought and effort on what it’ll take for each of us
> to
> > > become confident in running Apache Cassandra 4.0 for our most critical
> > > applications *prior* to cutting the dot-zero release.
> > > – It marks a commitment we can make to our user community: delivering
> > > 4.0’s featureset with safety and stability is our top priority.
> > > – There are many different perspectives each contributor can bring:
> > > correctness, performance, durability, automation, documentation,
> > > operational safety, etc; and many ways to gain confidence in each –
> perf
> > > tests, profiling, shadow writes/traffic mirroring, diff tests, replay
> > > tests, fuzz tests, fault injection, chaos engineering, and so many
> > others.
> > > By bringing diverse methods to bear on the same class of problem
> > (quality),
> > > we’re more likely to identify issues that could impact our users and to
> > > ship a better release.
> > > – It’s disciplined and courageous!
> > >
> > > Here’s why I think this won’t discourage new contributors from joining
> –
> > > in fact, the opposite:
> > >
> > > – It provides a very simple step that any contributor can take toward
> > > shipping 4.0: running it.
> > > – We raise spirits by delivering enhancements the community has been
> > > working on for two years rather than fracturing our attention.
> > > – If members of the community are interested in post-4.0 work, they’re
> > not
> > > blocked from making progress toward that – but it’s not the focus, and
> > > unlikely that review bandwidth would be available given that focus. I
> > agree
> > > with Kurt’s note that nobody can be “forced" to do anything - but by
> > > committing to reserving trunk for stabilizing changes until the beta,
> we
> > > focus our effort on polishing and delivering the release.
> > >
> > > On the last question:
> > > > On another note, we are still planning on accepting/reviewing bug
> fixes
> > > for previous versions as well correct?
> > >
> > > I’d expect so – and to take it a step further, it’s likely that this
> > rigor
> > > will result in us identifying serious issues that were not regressions
> in
> > > 4.0 warranting backports. As with any investment in testing /
> validation,
> > > I’m hoping we do … but also hoping we don’t. :-)
> > >
> > >
> > > > On Jul 3, 2018, at 7:21 PM, kurt greaves 
> wrote:
> > > >
> > > > tl;dr: +1 for committing to testing + bugfixing after feature freeze,
> > > but I
> > > > can't really see how changing the branching strategy is going to have
> > any
> > > > impact at all.
> > > >
> > > > I really don't think it's a big deal. People will work based on
> > whatever
> > > > priorities they've been assigned, regardless of what you do to the
> > > > branching. That's essentially just red tape and adding unnecessary
> > > > complexity to an a

Re: Testing 4.0 Post-Freeze

[sankalp kohli]

Hi Kurt,
   Thank you for your feedback. I am reading your comment as +1 on
the idea of working on making a solid release but +0 on branching model. Is
that correct?
Thanks,
Sankalp

On Tue, Jul 3, 2018 at 10:09 PM kurt greaves  wrote:

> >
> > but by committing to reserving trunk for stabilizing changes until the
> > beta, we focus our effort on polishing and delivering the release.
>
> No, committing to testing, bug fixing, and validating focuses our effort on
> polishing and delivering the release.
> Committing to reserving trunk for stabilising changes doesn't actually do
> anything. We could reserve trunk and no one could ever commit a single
> patch to it, or we could reserve trunk and everyone continues working on
> features. Whatever we do to trunk doesn't have any impact on how our
> attention is directed.
>
> Granted, you could argue that there is some great beneficial psychological
> aspect and having no feature branch will make everyone suddenly start
> working on bug fixes, but to people this actually affects (committers),
> it's not going to mean much to them. They are either already going to be
> motivated and tasked with getting 4.0 out the door, or they are going to do
> their own thing.
>
> I'm fairly positive that better communication around the release, and
> progress towards the release would be a better motivator. And it would go
> further to getting new contributors (who definitely don't care about the
> branches) involved, because anyone on the ML could see progress getting
> made and be a part of any call to arms.
>
> But at the end of the day, bikeshedding about this is not important. This
> is one of those issues which someone should just stand up and say "We're
> doing it this way because I said so", because either way, it really doesn't
> matter and the impact is going to be minimal, so we may as well get on with
> our lives.
>
> On 4 July 2018 at 04:06, Scott Andreas  wrote:
>
> > Here’s why I really like this proposal:
> >
> > – It focuses our thought and effort on what it’ll take for each of us to
> > become confident in running Apache Cassandra 4.0 for our most critical
> > applications *prior* to cutting the dot-zero release.
> > – It marks a commitment we can make to our user community: delivering
> > 4.0’s featureset with safety and stability is our top priority.
> > – There are many different perspectives each contributor can bring:
> > correctness, performance, durability, automation, documentation,
> > operational safety, etc; and many ways to gain confidence in each – perf
> > tests, profiling, shadow writes/traffic mirroring, diff tests, replay
> > tests, fuzz tests, fault injection, chaos engineering, and so many
> others.
> > By bringing diverse methods to bear on the same class of problem
> (quality),
> > we’re more likely to identify issues that could impact our users and to
> > ship a better release.
> > – It’s disciplined and courageous!
> >
> > Here’s why I think this won’t discourage new contributors from joining –
> > in fact, the opposite:
> >
> > – It provides a very simple step that any contributor can take toward
> > shipping 4.0: running it.
> > – We raise spirits by delivering enhancements the community has been
> > working on for two years rather than fracturing our attention.
> > – If members of the community are interested in post-4.0 work, they’re
> not
> > blocked from making progress toward that – but it’s not the focus, and
> > unlikely that review bandwidth would be available given that focus. I
> agree
> > with Kurt’s note that nobody can be “forced" to do anything - but by
> > committing to reserving trunk for stabilizing changes until the beta, we
> > focus our effort on polishing and delivering the release.
> >
> > On the last question:
> > > On another note, we are still planning on accepting/reviewing bug fixes
> > for previous versions as well correct?
> >
> > I’d expect so – and to take it a step further, it’s likely that this
> rigor
> > will result in us identifying serious issues that were not regressions in
> > 4.0 warranting backports. As with any investment in testing / validation,
> > I’m hoping we do … but also hoping we don’t. :-)
> >
> >
> > > On Jul 3, 2018, at 7:21 PM, kurt greaves  wrote:
> > >
> > > tl;dr: +1 for committing to testing + bugfixing after feature freeze,
> > but I
> > > can't really see how changing the branching strategy is going to have
> any
> > > impact at all.
> > >
> > > I really don't think it's a big deal. People will work based on
> whatever
> > > priorities they've been assigned, regardless of what you do to the
> > > branching. That's essentially just red tape and adding unnecessary
> > > complexity to an already established process. Granted, you'll have to
> do
> > > one less merge, but it should be an effortless merge, and it saves
> there
> > > being any confusion about what people should do with features. If
> someone
> > > decided to commit a feature, they could, and we wouldn't have 

Re: Testing 4.0 Post-Freeze

[kurt greaves]

>
> but by committing to reserving trunk for stabilizing changes until the
> beta, we focus our effort on polishing and delivering the release.

No, committing to testing, bug fixing, and validating focuses our effort on
polishing and delivering the release.
Committing to reserving trunk for stabilising changes doesn't actually do
anything. We could reserve trunk and no one could ever commit a single
patch to it, or we could reserve trunk and everyone continues working on
features. Whatever we do to trunk doesn't have any impact on how our
attention is directed.

Granted, you could argue that there is some great beneficial psychological
aspect and having no feature branch will make everyone suddenly start
working on bug fixes, but to people this actually affects (committers),
it's not going to mean much to them. They are either already going to be
motivated and tasked with getting 4.0 out the door, or they are going to do
their own thing.

I'm fairly positive that better communication around the release, and
progress towards the release would be a better motivator. And it would go
further to getting new contributors (who definitely don't care about the
branches) involved, because anyone on the ML could see progress getting
made and be a part of any call to arms.

But at the end of the day, bikeshedding about this is not important. This
is one of those issues which someone should just stand up and say "We're
doing it this way because I said so", because either way, it really doesn't
matter and the impact is going to be minimal, so we may as well get on with
our lives.

On 4 July 2018 at 04:06, Scott Andreas  wrote:

> Here’s why I really like this proposal:
>
> – It focuses our thought and effort on what it’ll take for each of us to
> become confident in running Apache Cassandra 4.0 for our most critical
> applications *prior* to cutting the dot-zero release.
> – It marks a commitment we can make to our user community: delivering
> 4.0’s featureset with safety and stability is our top priority.
> – There are many different perspectives each contributor can bring:
> correctness, performance, durability, automation, documentation,
> operational safety, etc; and many ways to gain confidence in each – perf
> tests, profiling, shadow writes/traffic mirroring, diff tests, replay
> tests, fuzz tests, fault injection, chaos engineering, and so many others.
> By bringing diverse methods to bear on the same class of problem (quality),
> we’re more likely to identify issues that could impact our users and to
> ship a better release.
> – It’s disciplined and courageous!
>
> Here’s why I think this won’t discourage new contributors from joining –
> in fact, the opposite:
>
> – It provides a very simple step that any contributor can take toward
> shipping 4.0: running it.
> – We raise spirits by delivering enhancements the community has been
> working on for two years rather than fracturing our attention.
> – If members of the community are interested in post-4.0 work, they’re not
> blocked from making progress toward that – but it’s not the focus, and
> unlikely that review bandwidth would be available given that focus. I agree
> with Kurt’s note that nobody can be “forced" to do anything - but by
> committing to reserving trunk for stabilizing changes until the beta, we
> focus our effort on polishing and delivering the release.
>
> On the last question:
> > On another note, we are still planning on accepting/reviewing bug fixes
> for previous versions as well correct?
>
> I’d expect so – and to take it a step further, it’s likely that this rigor
> will result in us identifying serious issues that were not regressions in
> 4.0 warranting backports. As with any investment in testing / validation,
> I’m hoping we do … but also hoping we don’t. :-)
>
>
> > On Jul 3, 2018, at 7:21 PM, kurt greaves  wrote:
> >
> > tl;dr: +1 for committing to testing + bugfixing after feature freeze,
> but I
> > can't really see how changing the branching strategy is going to have any
> > impact at all.
> >
> > I really don't think it's a big deal. People will work based on whatever
> > priorities they've been assigned, regardless of what you do to the
> > branching. That's essentially just red tape and adding unnecessary
> > complexity to an already established process. Granted, you'll have to do
> > one less merge, but it should be an effortless merge, and it saves there
> > being any confusion about what people should do with features. If someone
> > decided to commit a feature, they could, and we wouldn't have to be all
> > over every ticket making sure people don't commit things that shouldn't
> be
> > committed.
> >
> > Cutting to the point, all we're really aiming for here is a commitment
> from
> > the community to only dev on bugfixes, only review bugfixes, and
> > testing/validation during the freeze period. That's not going to be
> > enforced by a change in branching strategy, it's going to be enforced by
> > the contributors them

Re: Testing 4.0 Post-Freeze

[Scott Andreas]

Here’s why I really like this proposal:

– It focuses our thought and effort on what it’ll take for each of us to become 
confident in running Apache Cassandra 4.0 for our most critical applications 
*prior* to cutting the dot-zero release.
– It marks a commitment we can make to our user community: delivering 4.0’s 
featureset with safety and stability is our top priority.
– There are many different perspectives each contributor can bring: 
correctness, performance, durability, automation, documentation, operational 
safety, etc; and many ways to gain confidence in each – perf tests, profiling, 
shadow writes/traffic mirroring, diff tests, replay tests, fuzz tests, fault 
injection, chaos engineering, and so many others. By bringing diverse methods 
to bear on the same class of problem (quality), we’re more likely to identify 
issues that could impact our users and to ship a better release.
– It’s disciplined and courageous!

Here’s why I think this won’t discourage new contributors from joining – in 
fact, the opposite:

– It provides a very simple step that any contributor can take toward shipping 
4.0: running it.
– We raise spirits by delivering enhancements the community has been working on 
for two years rather than fracturing our attention.
– If members of the community are interested in post-4.0 work, they’re not 
blocked from making progress toward that – but it’s not the focus, and unlikely 
that review bandwidth would be available given that focus. I agree with Kurt’s 
note that nobody can be “forced" to do anything - but by committing to 
reserving trunk for stabilizing changes until the beta, we focus our effort on 
polishing and delivering the release.

On the last question:
> On another note, we are still planning on accepting/reviewing bug fixes for 
> previous versions as well correct?

I’d expect so – and to take it a step further, it’s likely that this rigor will 
result in us identifying serious issues that were not regressions in 4.0 
warranting backports. As with any investment in testing / validation, I’m 
hoping we do … but also hoping we don’t. :-)


> On Jul 3, 2018, at 7:21 PM, kurt greaves  wrote:
> 
> tl;dr: +1 for committing to testing + bugfixing after feature freeze, but I
> can't really see how changing the branching strategy is going to have any
> impact at all.
> 
> I really don't think it's a big deal. People will work based on whatever
> priorities they've been assigned, regardless of what you do to the
> branching. That's essentially just red tape and adding unnecessary
> complexity to an already established process. Granted, you'll have to do
> one less merge, but it should be an effortless merge, and it saves there
> being any confusion about what people should do with features. If someone
> decided to commit a feature, they could, and we wouldn't have to be all
> over every ticket making sure people don't commit things that shouldn't be
> committed.
> 
> Cutting to the point, all we're really aiming for here is a commitment from
> the community to only dev on bugfixes, only review bugfixes, and
> testing/validation during the freeze period. That's not going to be
> enforced by a change in branching strategy, it's going to be enforced by
> the contributors themselves (and their respective priority-setters).
> The best we can do is encourage a commitment to testing and bugfixing for
> the freeze period. This is a volunteer based project after all, so we can't
> really force anyone to do anything. If contributors make proposals for
> features in the freeze period we can just tell them that there is a focus
> on 4.0 testing and it's unlikely to be reviewed until 4.0 is released at
> best.
> 
> On another note, we are still planning on accepting/reviewing bug fixes for
> previous versions as well correct?  Just to clarify because it doesn't seem
> to be mentioned here and we don't want people getting in arguments over
> reviewing patches that only affect older releases.
> 
> I think not having your patch reviewed for months is more
>> discouraging than following the community and helping with stability of
>> 4.0.
> 
> Patches not getting reviewed for months on end already occurs. Changing how
> we branch isn't going to change this or make anyone feel better about it.
> The best we can do is communicate why their patches aren't getting
> reviewed, and we should be doing this on individual feature tickets that
> get raised and on the ML.
> 
> On 4 July 2018 at 00:44, Mick Semb Wever  wrote:
> 
>>> 
>>> 
>>> We propose 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.
>>> 
>> 
>> 
>> +1, like really yes!! because it's a step towards a more stable-master
>> project.
>> 
>> If trunk is focused on stabilising (which ideally it shouldn't have to, if
>> stable-master were true) then new features remaining in their respective
>> branches shouldn't be a big co

Re: Testing 4.0 Post-Freeze

[kurt greaves]

tl;dr: +1 for committing to testing + bugfixing after feature freeze, but I
can't really see how changing the branching strategy is going to have any
impact at all.

I really don't think it's a big deal. People will work based on whatever
priorities they've been assigned, regardless of what you do to the
branching. That's essentially just red tape and adding unnecessary
complexity to an already established process. Granted, you'll have to do
one less merge, but it should be an effortless merge, and it saves there
being any confusion about what people should do with features. If someone
decided to commit a feature, they could, and we wouldn't have to be all
over every ticket making sure people don't commit things that shouldn't be
committed.

Cutting to the point, all we're really aiming for here is a commitment from
the community to only dev on bugfixes, only review bugfixes, and
testing/validation during the freeze period. That's not going to be
enforced by a change in branching strategy, it's going to be enforced by
the contributors themselves (and their respective priority-setters).
The best we can do is encourage a commitment to testing and bugfixing for
the freeze period. This is a volunteer based project after all, so we can't
really force anyone to do anything. If contributors make proposals for
features in the freeze period we can just tell them that there is a focus
on 4.0 testing and it's unlikely to be reviewed until 4.0 is released at
best.

On another note, we are still planning on accepting/reviewing bug fixes for
previous versions as well correct?  Just to clarify because it doesn't seem
to be mentioned here and we don't want people getting in arguments over
reviewing patches that only affect older releases.

I think not having your patch reviewed for months is more
> discouraging than following the community and helping with stability of
> 4.0.

Patches not getting reviewed for months on end already occurs. Changing how
we branch isn't going to change this or make anyone feel better about it.
The best we can do is communicate why their patches aren't getting
reviewed, and we should be doing this on individual feature tickets that
get raised and on the ML.

On 4 July 2018 at 00:44, Mick Semb Wever  wrote:

> >
> >
> > We propose 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.
> >
>
>
> +1, like really yes!! because it's a step towards a more stable-master
> project.
>
> If trunk is focused on stabilising (which ideally it shouldn't have to, if
> stable-master were true) then new features remaining in their respective
> branches shouldn't be a big cost or risk (nor seen as anything negative).
> And hopefully any additional practices/lessons learnt from during the
> freeze period get carried on for good.
>
> Although, and unfortunately, there's just not the testing infrastructure
> available to the public to ensure feature branches are solid before
> merging. But I struggle to see that as an excuse to only "stabilise" on
> release branches.
>
> 2¢,
> mick
>

Re: [VOTE] Release Apache Cassandra 2.2.13

[Joseph Lynch]

+1 nb

Tests look reasonable

with passing unit tests  and
about 13 failing dtests 

On Tue, Jul 3, 2018 at 1:55 PM kurt greaves  wrote:

> +1 nb
>
> On Wed., 4 Jul. 2018, 03:26 Brandon Williams,  wrote:
>
> > +1
> >
> > On Mon, Jul 2, 2018 at 3:10 PM, Michael Shuler 
> > wrote:
> >
> > > I propose the following artifacts for release as 2.2.13.
> > >
> > > sha1: 9ff78249a0a5e87bd04bf9804ef1a3b29b5e1645
> > > Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=sho
> > > rtlog;h=refs/tags/2.2.13-tentative
> > > Artifacts:
> https://repository.apache.org/content/repositories/orgapache
> > > cassandra-1159/org/apache/cassandra/apache-cassandra/2.2.13/
> > > Staging repository: https://repository.apache.org/
> > > content/repositories/orgapachecassandra-1159/
> > >
> > > The Debian and RPM packages are available here:
> > > http://people.apache.org/~mshuler/
> > >
> > > The vote will be open for 72 hours (longer if needed).
> > >
> > > [1]: (CHANGES.txt) http://git-wip-us.apache.org/r
> > > epos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/
> > > tags/2.2.13-tentative
> > > [2]: (NEWS.txt) http://git-wip-us.apache.org/r
> > > epos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tag
> > > s/2.2.13-tentative
> > >
> > > --
> > > Michael
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: Testing 4.0 Post-Freeze

[Mick Semb Wever]

>
>
> We propose 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.
>


+1, like really yes!! because it's a step towards a more stable-master
project.

If trunk is focused on stabilising (which ideally it shouldn't have to, if
stable-master were true) then new features remaining in their respective
branches shouldn't be a big cost or risk (nor seen as anything negative).
And hopefully any additional practices/lessons learnt from during the
freeze period get carried on for good.

Although, and unfortunately, there's just not the testing infrastructure
available to the public to ensure feature branches are solid before
merging. But I struggle to see that as an excuse to only "stabilise" on
release branches.

2¢,
mick

Re: Testing 4.0 Post-Freeze

[Jeff Jirsa]

Yes?

-- 
Jeff Jirsa


> On Jul 3, 2018, at 2:29 PM, Jonathan Ellis  wrote:
> 
> Is that worth the risk of demotivating new contributors who might have
> other priorities?
> 
>> On Tue, Jul 3, 2018 at 4:22 PM, Jeff Jirsa  wrote:
>> 
>> I think there's value in the psychological commitment that if someone has
>> time to contribute, their contributions should be focused on validating a
>> release, not pushing future features.
>> 
>> 
>>> On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad  wrote:
>>> 
>>> I agree with Josh. I don’t see how changing the convention around trunk
>>> will improve the process, seems like it’ll only introduce a handful of
>>> rollback commits when people forget.
>>> 
>>> Other than that, it all makes sense to me.
>>> 
>>> I’ve been working on a workload centric stress tool on and off for a
>> little
>>> bit in an effort to create something that will help with wider adoption
>> in
>>> stress testing. It differs from the stress we ship by including fully
>>> functional stress workloads as well as a validation process. The idea
>> being
>>> to be flexible enough to test both performance and correctness in LWT and
>>> MVs as well as other arbitrary workloads.
>>> 
>>> https://github.com/thelastpickle/tlp-stress
>>> 
>>> Jon
>>> 
>>> 
>>> On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie 
>>> wrote:
>>> 
 Why not just branch a 4.0-rel and bugfix there and merge up while still
 accepting new features or improvements on trunk?
 
 I don't think the potential extra engagement in testing will balance
>> out
 the atrophy and discouraging contributions / community engagement we'd
>>> get
 by deferring all improvements and new features in an open-ended way.
 
 On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli 
 wrote:
 
> Hi cassandra-dev@,
> 
> With the goal of making Cassandra's 4.0 the most stable major release
>>> to
> date, we would like all committers of the project to consider joining
>>> us
 in
> dedicating their time and attention to testing, running, and fixing
 issues
> in 4.0 between the September freeze and the 4.0 beta release. This
>>> would
> result in a freeze of new feature development on trunk or branches
>>> during
> this period, instead focusing on writing, improving, and running
>> tests
>>> or
> fixing and reviewing bugs or performance regressions found in 4.0 or
> earlier.
> 
> How would this work?
> 
> We propose 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. At the same time we do not want to
 discourage
> community contributions. Not all contributors can be expected to be
>>> aware
> of such a decision or may be new to the project. In cases where new
> features are contributed during this time, the contributor can be
 informed
> of the current status of the release process, be encouraged to
>>> contribute
> to testing or bug fixing, and have their feature reviewed after the
>>> beta
 is
> reached.
> 
> 
> What happens when beta is reached?
> 
> Ideally, contributors who have made significant contributions to the
> release will stick around to continue testing between beta and final
> release. Any additional folks who continue this focus would also be
 greatly
> appreciated.
> 
> What about before the freeze?
> 
> Testing new features is of course important. This isn't meant to
 discourage
> development – only to enable us to focus on testing and hardening 4.0
>>> to
> deliver Cassandra's most stable major release. We would like to see
> adoption of 4.0 happen much more quickly than its predecessor.
> 
> Thanks for considering this proposal,
> Sankalp Kohli
 
>>> --
>>> Jon Haddad
>>> http://www.rustyrazorblade.com
>>> twitter: rustyrazorblade
>>> 
>> 
> 
> 
> 
> -- 
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Testing 4.0 Post-Freeze

[sankalp kohli]

Having an explicit way to tell the community that we all will work on
testing is better than writing a patch which will sit without review for
months. I think not having your patch reviewed for months is more
discouraging than following the community and helping with stability of
4.0.



On Tue, Jul 3, 2018 at 3:02 PM Josh McKenzie  wrote:

> >
> > We propose 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.
>
>
> This is more of a call to action and announcement of intent than an attempt
> > to
> > enforce policy; we can and probably will branch off 4.0, and keep trunk
> > technically active.
>
> These are two very different statements. :) Which is it?
>
> On Tue, Jul 3, 2018 at 5:57 PM Aleksey Yeshchenko 
> wrote:
>
> > If we want to have a stable, usable 4.0.0 release out in the next 6-12
> > months, there needs to be a focused effort on getting it out - or else
> > it’ll just never happen.
> >
> > This is more of a call to action and announcement of intent than an
> > attempt to enforce policy; we can and probably will branch off 4.0, and
> > keep trunk technically active. But so long as there is a critical mass of
> > active contributors who are on board with only/mostly working on
> stability,
> > bug fixes, and validation - both as assignees and reviewers - we’ll have
> a
> > de-facto freeze.
> >
> > And I have a feeling that there is such a critical mass.
> >
> > —
> > AY
> >
> > On 3 July 2018 at 22:23:38, Jeff Jirsa (jji...@gmail.com) wrote:
> >
> > I think there's value in the psychological commitment that if someone has
> > time to contribute, their contributions should be focused on validating a
> > release, not pushing future features.
> >
> >
> > On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad 
> > wrote:
> >
> > > I agree with Josh. I don’t see how changing the convention around trunk
> > > will improve the process, seems like it’ll only introduce a handful of
> > > rollback commits when people forget.
> > >
> > > Other than that, it all makes sense to me.
> > >
> > > I’ve been working on a workload centric stress tool on and off for a
> > little
> > > bit in an effort to create something that will help with wider adoption
> > in
> > > stress testing. It differs from the stress we ship by including fully
> > > functional stress workloads as well as a validation process. The idea
> > being
> > > to be flexible enough to test both performance and correctness in LWT
> > and
> > > MVs as well as other arbitrary workloads.
> > >
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_thelastpickle_tlp-2Dstress&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ&s=f8gf_JCP6JRQIRkL_1R_zJOS_6gdAAsLleDr2PZHppE&e=
> >
> > >
> > > Jon
> > >
> > >
> > > On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie 
> > > wrote:
> > >
> > > > Why not just branch a 4.0-rel and bugfix there and merge up while
> > still
> > > > accepting new features or improvements on trunk?
> > > >
> > > > I don't think the potential extra engagement in testing will balance
> > out
> > > > the atrophy and discouraging contributions / community engagement
> > we'd
> > > get
> > > > by deferring all improvements and new features in an open-ended way.
> > > >
> > > > On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli  >
> >
> > > > wrote:
> > > >
> > > > > Hi cassandra-dev@,
> > > > >
> > > > > With the goal of making Cassandra's 4.0 the most stable major
> > release
> > > to
> > > > > date, we would like all committers of the project to consider
> > joining
> > > us
> > > > in
> > > > > dedicating their time and attention to testing, running, and fixing
> > > > issues
> > > > > in 4.0 between the September freeze and the 4.0 beta release. This
> > > would
> > > > > result in a freeze of new feature development on trunk or branches
> > > during
> > > > > this period, instead focusing on writing, improving, and running
> > tests
> > > or
> > > > > fixing and reviewing bugs or performance regressions found in 4.0
> > or
> > > > > earlier.
> > > > >
> > > > > How would this work?
> > > > >
> > > > > We propose 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. At the same time we do not want to
> > > > discourage
> > > > > community contributions. Not all contributors can be expected to be
> > > aware
> > > > > of such a decision or may be new to the project. In cases where new
> > > > > features are contributed during this time, the contributor can be
> > > > informed
> > > > > of the current status of the release process, be encouraged to
> > > contribute
> > > > > to testing or bug fixing, and have their feature reviewed after the
> > > beta
> > > > is
> > > > > reached.
> > > > >
> > > > 

Re: Testing 4.0 Post-Freeze

[Josh McKenzie]

>
> We propose 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.


This is more of a call to action and announcement of intent than an attempt
> to
> enforce policy; we can and probably will branch off 4.0, and keep trunk
> technically active.

These are two very different statements. :) Which is it?

On Tue, Jul 3, 2018 at 5:57 PM Aleksey Yeshchenko  wrote:

> If we want to have a stable, usable 4.0.0 release out in the next 6-12
> months, there needs to be a focused effort on getting it out - or else
> it’ll just never happen.
>
> This is more of a call to action and announcement of intent than an
> attempt to enforce policy; we can and probably will branch off 4.0, and
> keep trunk technically active. But so long as there is a critical mass of
> active contributors who are on board with only/mostly working on stability,
> bug fixes, and validation - both as assignees and reviewers - we’ll have a
> de-facto freeze.
>
> And I have a feeling that there is such a critical mass.
>
> —
> AY
>
> On 3 July 2018 at 22:23:38, Jeff Jirsa (jji...@gmail.com) wrote:
>
> I think there's value in the psychological commitment that if someone has
> time to contribute, their contributions should be focused on validating a
> release, not pushing future features.
>
>
> On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad 
> wrote:
>
> > I agree with Josh. I don’t see how changing the convention around trunk
> > will improve the process, seems like it’ll only introduce a handful of
> > rollback commits when people forget.
> >
> > Other than that, it all makes sense to me.
> >
> > I’ve been working on a workload centric stress tool on and off for a
> little
> > bit in an effort to create something that will help with wider adoption
> in
> > stress testing. It differs from the stress we ship by including fully
> > functional stress workloads as well as a validation process. The idea
> being
> > to be flexible enough to test both performance and correctness in LWT
> and
> > MVs as well as other arbitrary workloads.
> >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_thelastpickle_tlp-2Dstress&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ&s=f8gf_JCP6JRQIRkL_1R_zJOS_6gdAAsLleDr2PZHppE&e=
>
> >
> > Jon
> >
> >
> > On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie 
> > wrote:
> >
> > > Why not just branch a 4.0-rel and bugfix there and merge up while
> still
> > > accepting new features or improvements on trunk?
> > >
> > > I don't think the potential extra engagement in testing will balance
> out
> > > the atrophy and discouraging contributions / community engagement
> we'd
> > get
> > > by deferring all improvements and new features in an open-ended way.
> > >
> > > On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli 
>
> > > wrote:
> > >
> > > > Hi cassandra-dev@,
> > > >
> > > > With the goal of making Cassandra's 4.0 the most stable major
> release
> > to
> > > > date, we would like all committers of the project to consider
> joining
> > us
> > > in
> > > > dedicating their time and attention to testing, running, and fixing
> > > issues
> > > > in 4.0 between the September freeze and the 4.0 beta release. This
> > would
> > > > result in a freeze of new feature development on trunk or branches
> > during
> > > > this period, instead focusing on writing, improving, and running
> tests
> > or
> > > > fixing and reviewing bugs or performance regressions found in 4.0
> or
> > > > earlier.
> > > >
> > > > How would this work?
> > > >
> > > > We propose 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. At the same time we do not want to
> > > discourage
> > > > community contributions. Not all contributors can be expected to be
> > aware
> > > > of such a decision or may be new to the project. In cases where new
> > > > features are contributed during this time, the contributor can be
> > > informed
> > > > of the current status of the release process, be encouraged to
> > contribute
> > > > to testing or bug fixing, and have their feature reviewed after the
> > beta
> > > is
> > > > reached.
> > > >
> > > >
> > > > What happens when beta is reached?
> > > >
> > > > Ideally, contributors who have made significant contributions to
> the
> > > > release will stick around to continue testing between beta and
> final
> > > > release. Any additional folks who continue this focus would also be
> > > greatly
> > > > appreciated.
> > > >
> > > > What about before the freeze?
> > > >
> > > > Testing new features is of course important. This isn't meant to
> > > discourage
> > > > development – only to enable us to focus on testing and hardening
> 4.0
> > to
> > > > deliver Cassandra's most stable major r

Re: Testing 4.0 Post-Freeze

[Roopa Tangirala]

At Netflix, we use NDBench  extensively
to ensure there are no performance regressions introduced between major
releases since all our micro services are very sensitive to any latency
changes. I see a value in community organizing efforts around the
production readiness and stability of a release which builds confidence in
using the particular release in production. Once 4.0 is freezed, we will
run it through our build pipeline which not only validates the performance
but also regular maintenances like repair, compactions, node terminations,
replacements, streaming and share the results.


*Regards,*

*Roopa Tangirala*

Engineering Manager CDE

*(408) 438-3156 - mobile*






On Tue, Jul 3, 2018 at 2:32 PM dinesh.jo...@yahoo.com.INVALID
 wrote:

> I think the call to action for the community here is to focus efforts on
> testing and bug fixes than spending time on reviewing features. That said,
> tlp-stress looks interesting.
> Dinesh
>
> On Tuesday, July 3, 2018, 1:03:54 PM PDT, Jonathan Haddad <
> j...@jonhaddad.com> wrote:
>
>  I agree with Josh. I don’t see how changing the convention around trunk
> will improve the process, seems like it’ll only introduce a handful of
> rollback commits when people forget.
>
> Other than that, it all makes sense to me.
>
> I’ve been working on a workload centric stress tool on and off for a little
> bit in an effort to create something that will help with wider adoption in
> stress testing. It differs from the stress we ship by including fully
> functional stress workloads as well as a validation process. The idea being
> to be flexible enough to test both performance and correctness in LWT and
> MVs as well as other arbitrary workloads.
>
> https://github.com/thelastpickle/tlp-stress
>
> Jon
>
>
> On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie 
> wrote:
>
> > Why not just branch a 4.0-rel and bugfix there and merge up while still
> > accepting new features or improvements on trunk?
> >
> > I don't think the potential extra engagement in testing will balance out
> > the atrophy and discouraging contributions / community engagement we'd
> get
> > by deferring all improvements and new features in an open-ended way.
> >
> > On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli 
> > wrote:
> >
> > > Hi cassandra-dev@,
> > >
> > > With the goal of making Cassandra's 4.0 the most stable major release
> to
> > > date, we would like all committers of the project to consider joining
> us
> > in
> > > dedicating their time and attention to testing, running, and fixing
> > issues
> > > in 4.0 between the September freeze and the 4.0 beta release. This
> would
> > > result in a freeze of new feature development on trunk or branches
> during
> > > this period, instead focusing on writing, improving, and running tests
> or
> > > fixing and reviewing bugs or performance regressions found in 4.0 or
> > > earlier.
> > >
> > > How would this work?
> > >
> > > We propose 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. At the same time we do not want to
> > discourage
> > > community contributions. Not all contributors can be expected to be
> aware
> > > of such a decision or may be new to the project. In cases where new
> > > features are contributed during this time, the contributor can be
> > informed
> > > of the current status of the release process, be encouraged to
> contribute
> > > to testing or bug fixing, and have their feature reviewed after the
> beta
> > is
> > > reached.
> > >
> > >
> > > What happens when beta is reached?
> > >
> > > Ideally, contributors who have made significant contributions to the
> > > release will stick around to continue testing between beta and final
> > > release. Any additional folks who continue this focus would also be
> > greatly
> > > appreciated.
> > >
> > > What about before the freeze?
> > >
> > > Testing new features is of course important. This isn't meant to
> > discourage
> > > development – only to enable us to focus on testing and hardening 4.0
> to
> > > deliver Cassandra's most stable major release. We would like to see
> > > adoption of 4.0 happen much more quickly than its predecessor.
> > >
> > > Thanks for considering this proposal,
> > > Sankalp Kohli
> >
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade

Re: Testing 4.0 Post-Freeze

[Aleksey Yeshchenko]

If we want to have a stable, usable 4.0.0 release out in the next 6-12 months, 
there needs to be a focused effort on getting it out - or else it’ll just never 
happen.

This is more of a call to action and announcement of intent than an attempt to 
enforce policy; we can and probably will branch off 4.0, and keep trunk 
technically active. But so long as there is a critical mass of active 
contributors who are on board with only/mostly working on stability, bug fixes, 
and validation - both as assignees and reviewers - we’ll have a de-facto freeze.

And I have a feeling that there is such a critical mass.

—
AY

On 3 July 2018 at 22:23:38, Jeff Jirsa (jji...@gmail.com) wrote:

I think there's value in the psychological commitment that if someone has  
time to contribute, their contributions should be focused on validating a  
release, not pushing future features.  


On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad  wrote:  

> I agree with Josh. I don’t see how changing the convention around trunk  
> will improve the process, seems like it’ll only introduce a handful of  
> rollback commits when people forget.  
>  
> Other than that, it all makes sense to me.  
>  
> I’ve been working on a workload centric stress tool on and off for a little  
> bit in an effort to create something that will help with wider adoption in  
> stress testing. It differs from the stress we ship by including fully  
> functional stress workloads as well as a validation process. The idea being  
> to be flexible enough to test both performance and correctness in LWT and  
> MVs as well as other arbitrary workloads.  
>  
> https://github.com/thelastpickle/tlp-stress  
>  
> Jon  
>  
>  
> On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie   
> wrote:  
>  
> > Why not just branch a 4.0-rel and bugfix there and merge up while still  
> > accepting new features or improvements on trunk?  
> >  
> > I don't think the potential extra engagement in testing will balance out  
> > the atrophy and discouraging contributions / community engagement we'd  
> get  
> > by deferring all improvements and new features in an open-ended way.  
> >  
> > On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli   
> > wrote:  
> >  
> > > Hi cassandra-dev@,  
> > >  
> > > With the goal of making Cassandra's 4.0 the most stable major release  
> to  
> > > date, we would like all committers of the project to consider joining  
> us  
> > in  
> > > dedicating their time and attention to testing, running, and fixing  
> > issues  
> > > in 4.0 between the September freeze and the 4.0 beta release. This  
> would  
> > > result in a freeze of new feature development on trunk or branches  
> during  
> > > this period, instead focusing on writing, improving, and running tests  
> or  
> > > fixing and reviewing bugs or performance regressions found in 4.0 or  
> > > earlier.  
> > >  
> > > How would this work?  
> > >  
> > > We propose 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. At the same time we do not want to  
> > discourage  
> > > community contributions. Not all contributors can be expected to be  
> aware  
> > > of such a decision or may be new to the project. In cases where new  
> > > features are contributed during this time, the contributor can be  
> > informed  
> > > of the current status of the release process, be encouraged to  
> contribute  
> > > to testing or bug fixing, and have their feature reviewed after the  
> beta  
> > is  
> > > reached.  
> > >  
> > >  
> > > What happens when beta is reached?  
> > >  
> > > Ideally, contributors who have made significant contributions to the  
> > > release will stick around to continue testing between beta and final  
> > > release. Any additional folks who continue this focus would also be  
> > greatly  
> > > appreciated.  
> > >  
> > > What about before the freeze?  
> > >  
> > > Testing new features is of course important. This isn't meant to  
> > discourage  
> > > development – only to enable us to focus on testing and hardening 4.0  
> to  
> > > deliver Cassandra's most stable major release. We would like to see  
> > > adoption of 4.0 happen much more quickly than its predecessor.  
> > >  
> > > Thanks for considering this proposal,  
> > > Sankalp Kohli  
> >  
> --  
> Jon Haddad  
> http://www.rustyrazorblade.com  
> twitter: rustyrazorblade  
>  

Re: Testing 4.0 Post-Freeze

[dinesh.jo...@yahoo.com.INVALID]

I think the call to action for the community here is to focus efforts on 
testing and bug fixes than spending time on reviewing features. That said, 
tlp-stress looks interesting.
Dinesh 

On Tuesday, July 3, 2018, 1:03:54 PM PDT, Jonathan Haddad 
 wrote:  
 
 I agree with Josh. I don’t see how changing the convention around trunk
will improve the process, seems like it’ll only introduce a handful of
rollback commits when people forget.

Other than that, it all makes sense to me.

I’ve been working on a workload centric stress tool on and off for a little
bit in an effort to create something that will help with wider adoption in
stress testing. It differs from the stress we ship by including fully
functional stress workloads as well as a validation process. The idea being
to be flexible enough to test both performance and correctness in LWT and
MVs as well as other arbitrary workloads.

https://github.com/thelastpickle/tlp-stress

Jon


On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie  wrote:

> Why not just branch a 4.0-rel and bugfix there and merge up while still
> accepting new features or improvements on trunk?
>
> I don't think the potential extra engagement in testing will balance out
> the atrophy and discouraging contributions / community engagement we'd get
> by deferring all improvements and new features in an open-ended way.
>
> On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli 
> wrote:
>
> > Hi cassandra-dev@,
> >
> > With the goal of making Cassandra's 4.0 the most stable major release to
> > date, we would like all committers of the project to consider joining us
> in
> > dedicating their time and attention to testing, running, and fixing
> issues
> > in 4.0 between the September freeze and the 4.0 beta release. This would
> > result in a freeze of new feature development on trunk or branches during
> > this period, instead focusing on writing, improving, and running tests or
> > fixing and reviewing bugs or performance regressions found in 4.0 or
> > earlier.
> >
> > How would this work?
> >
> > We propose 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. At the same time we do not want to
> discourage
> > community contributions. Not all contributors can be expected to be aware
> > of such a decision or may be new to the project. In cases where new
> > features are contributed during this time, the contributor can be
> informed
> > of the current status of the release process, be encouraged to contribute
> > to testing or bug fixing, and have their feature reviewed after the beta
> is
> > reached.
> >
> >
> > What happens when beta is reached?
> >
> > Ideally, contributors who have made significant contributions to the
> > release will stick around to continue testing between beta and final
> > release. Any additional folks who continue this focus would also be
> greatly
> > appreciated.
> >
> > What about before the freeze?
> >
> > Testing new features is of course important. This isn't meant to
> discourage
> > development – only to enable us to focus on testing and hardening 4.0 to
> > deliver Cassandra's most stable major release. We would like to see
> > adoption of 4.0 happen much more quickly than its predecessor.
> >
> > Thanks for considering this proposal,
> > Sankalp Kohli
>
-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade  

Re: Testing 4.0 Post-Freeze

[Jonathan Ellis]

Is that worth the risk of demotivating new contributors who might have
other priorities?

On Tue, Jul 3, 2018 at 4:22 PM, Jeff Jirsa  wrote:

> I think there's value in the psychological commitment that if someone has
> time to contribute, their contributions should be focused on validating a
> release, not pushing future features.
>
>
> On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad  wrote:
>
> > I agree with Josh. I don’t see how changing the convention around trunk
> > will improve the process, seems like it’ll only introduce a handful of
> > rollback commits when people forget.
> >
> > Other than that, it all makes sense to me.
> >
> > I’ve been working on a workload centric stress tool on and off for a
> little
> > bit in an effort to create something that will help with wider adoption
> in
> > stress testing. It differs from the stress we ship by including fully
> > functional stress workloads as well as a validation process. The idea
> being
> > to be flexible enough to test both performance and correctness in LWT and
> > MVs as well as other arbitrary workloads.
> >
> > https://github.com/thelastpickle/tlp-stress
> >
> > Jon
> >
> >
> > On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie 
> > wrote:
> >
> > > Why not just branch a 4.0-rel and bugfix there and merge up while still
> > > accepting new features or improvements on trunk?
> > >
> > > I don't think the potential extra engagement in testing will balance
> out
> > > the atrophy and discouraging contributions / community engagement we'd
> > get
> > > by deferring all improvements and new features in an open-ended way.
> > >
> > > On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli 
> > > wrote:
> > >
> > > > Hi cassandra-dev@,
> > > >
> > > > With the goal of making Cassandra's 4.0 the most stable major release
> > to
> > > > date, we would like all committers of the project to consider joining
> > us
> > > in
> > > > dedicating their time and attention to testing, running, and fixing
> > > issues
> > > > in 4.0 between the September freeze and the 4.0 beta release. This
> > would
> > > > result in a freeze of new feature development on trunk or branches
> > during
> > > > this period, instead focusing on writing, improving, and running
> tests
> > or
> > > > fixing and reviewing bugs or performance regressions found in 4.0 or
> > > > earlier.
> > > >
> > > > How would this work?
> > > >
> > > > We propose 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. At the same time we do not want to
> > > discourage
> > > > community contributions. Not all contributors can be expected to be
> > aware
> > > > of such a decision or may be new to the project. In cases where new
> > > > features are contributed during this time, the contributor can be
> > > informed
> > > > of the current status of the release process, be encouraged to
> > contribute
> > > > to testing or bug fixing, and have their feature reviewed after the
> > beta
> > > is
> > > > reached.
> > > >
> > > >
> > > > What happens when beta is reached?
> > > >
> > > > Ideally, contributors who have made significant contributions to the
> > > > release will stick around to continue testing between beta and final
> > > > release. Any additional folks who continue this focus would also be
> > > greatly
> > > > appreciated.
> > > >
> > > > What about before the freeze?
> > > >
> > > > Testing new features is of course important. This isn't meant to
> > > discourage
> > > > development – only to enable us to focus on testing and hardening 4.0
> > to
> > > > deliver Cassandra's most stable major release. We would like to see
> > > > adoption of 4.0 happen much more quickly than its predecessor.
> > > >
> > > > Thanks for considering this proposal,
> > > > Sankalp Kohli
> > >
> > --
> > Jon Haddad
> > http://www.rustyrazorblade.com
> > twitter: rustyrazorblade
> >
>



-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: Testing 4.0 Post-Freeze

[Jeff Jirsa]

I think there's value in the psychological commitment that if someone has
time to contribute, their contributions should be focused on validating a
release, not pushing future features.


On Tue, Jul 3, 2018 at 1:03 PM, Jonathan Haddad  wrote:

> I agree with Josh. I don’t see how changing the convention around trunk
> will improve the process, seems like it’ll only introduce a handful of
> rollback commits when people forget.
>
> Other than that, it all makes sense to me.
>
> I’ve been working on a workload centric stress tool on and off for a little
> bit in an effort to create something that will help with wider adoption in
> stress testing. It differs from the stress we ship by including fully
> functional stress workloads as well as a validation process. The idea being
> to be flexible enough to test both performance and correctness in LWT and
> MVs as well as other arbitrary workloads.
>
> https://github.com/thelastpickle/tlp-stress
>
> Jon
>
>
> On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie 
> wrote:
>
> > Why not just branch a 4.0-rel and bugfix there and merge up while still
> > accepting new features or improvements on trunk?
> >
> > I don't think the potential extra engagement in testing will balance out
> > the atrophy and discouraging contributions / community engagement we'd
> get
> > by deferring all improvements and new features in an open-ended way.
> >
> > On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli 
> > wrote:
> >
> > > Hi cassandra-dev@,
> > >
> > > With the goal of making Cassandra's 4.0 the most stable major release
> to
> > > date, we would like all committers of the project to consider joining
> us
> > in
> > > dedicating their time and attention to testing, running, and fixing
> > issues
> > > in 4.0 between the September freeze and the 4.0 beta release. This
> would
> > > result in a freeze of new feature development on trunk or branches
> during
> > > this period, instead focusing on writing, improving, and running tests
> or
> > > fixing and reviewing bugs or performance regressions found in 4.0 or
> > > earlier.
> > >
> > > How would this work?
> > >
> > > We propose 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. At the same time we do not want to
> > discourage
> > > community contributions. Not all contributors can be expected to be
> aware
> > > of such a decision or may be new to the project. In cases where new
> > > features are contributed during this time, the contributor can be
> > informed
> > > of the current status of the release process, be encouraged to
> contribute
> > > to testing or bug fixing, and have their feature reviewed after the
> beta
> > is
> > > reached.
> > >
> > >
> > > What happens when beta is reached?
> > >
> > > Ideally, contributors who have made significant contributions to the
> > > release will stick around to continue testing between beta and final
> > > release. Any additional folks who continue this focus would also be
> > greatly
> > > appreciated.
> > >
> > > What about before the freeze?
> > >
> > > Testing new features is of course important. This isn't meant to
> > discourage
> > > development – only to enable us to focus on testing and hardening 4.0
> to
> > > deliver Cassandra's most stable major release. We would like to see
> > > adoption of 4.0 happen much more quickly than its predecessor.
> > >
> > > Thanks for considering this proposal,
> > > Sankalp Kohli
> >
> --
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade
>

Re: [VOTE] Release Apache Cassandra 2.2.13

[kurt greaves]

+1 nb

On Wed., 4 Jul. 2018, 03:26 Brandon Williams,  wrote:

> +1
>
> On Mon, Jul 2, 2018 at 3:10 PM, Michael Shuler 
> wrote:
>
> > I propose the following artifacts for release as 2.2.13.
> >
> > sha1: 9ff78249a0a5e87bd04bf9804ef1a3b29b5e1645
> > Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=sho
> > rtlog;h=refs/tags/2.2.13-tentative
> > Artifacts: https://repository.apache.org/content/repositories/orgapache
> > cassandra-1159/org/apache/cassandra/apache-cassandra/2.2.13/
> > Staging repository: https://repository.apache.org/
> > content/repositories/orgapachecassandra-1159/
> >
> > The Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler/
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) http://git-wip-us.apache.org/r
> > epos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/
> > tags/2.2.13-tentative
> > [2]: (NEWS.txt) http://git-wip-us.apache.org/r
> > epos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tag
> > s/2.2.13-tentative
> >
> > --
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Testing 4.0 Post-Freeze

[Jonathan Haddad]

I agree with Josh. I don’t see how changing the convention around trunk
will improve the process, seems like it’ll only introduce a handful of
rollback commits when people forget.

Other than that, it all makes sense to me.

I’ve been working on a workload centric stress tool on and off for a little
bit in an effort to create something that will help with wider adoption in
stress testing. It differs from the stress we ship by including fully
functional stress workloads as well as a validation process. The idea being
to be flexible enough to test both performance and correctness in LWT and
MVs as well as other arbitrary workloads.

https://github.com/thelastpickle/tlp-stress

Jon


On Tue, Jul 3, 2018 at 12:28 PM Josh McKenzie  wrote:

> Why not just branch a 4.0-rel and bugfix there and merge up while still
> accepting new features or improvements on trunk?
>
> I don't think the potential extra engagement in testing will balance out
> the atrophy and discouraging contributions / community engagement we'd get
> by deferring all improvements and new features in an open-ended way.
>
> On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli 
> wrote:
>
> > Hi cassandra-dev@,
> >
> > With the goal of making Cassandra's 4.0 the most stable major release to
> > date, we would like all committers of the project to consider joining us
> in
> > dedicating their time and attention to testing, running, and fixing
> issues
> > in 4.0 between the September freeze and the 4.0 beta release. This would
> > result in a freeze of new feature development on trunk or branches during
> > this period, instead focusing on writing, improving, and running tests or
> > fixing and reviewing bugs or performance regressions found in 4.0 or
> > earlier.
> >
> > How would this work?
> >
> > We propose 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. At the same time we do not want to
> discourage
> > community contributions. Not all contributors can be expected to be aware
> > of such a decision or may be new to the project. In cases where new
> > features are contributed during this time, the contributor can be
> informed
> > of the current status of the release process, be encouraged to contribute
> > to testing or bug fixing, and have their feature reviewed after the beta
> is
> > reached.
> >
> >
> > What happens when beta is reached?
> >
> > Ideally, contributors who have made significant contributions to the
> > release will stick around to continue testing between beta and final
> > release. Any additional folks who continue this focus would also be
> greatly
> > appreciated.
> >
> > What about before the freeze?
> >
> > Testing new features is of course important. This isn't meant to
> discourage
> > development – only to enable us to focus on testing and hardening 4.0 to
> > deliver Cassandra's most stable major release. We would like to see
> > adoption of 4.0 happen much more quickly than its predecessor.
> >
> > Thanks for considering this proposal,
> > Sankalp Kohli
>
-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade

Re: Testing 4.0 Post-Freeze

[Josh McKenzie]

Why not just branch a 4.0-rel and bugfix there and merge up while still
accepting new features or improvements on trunk?

I don't think the potential extra engagement in testing will balance out
the atrophy and discouraging contributions / community engagement we'd get
by deferring all improvements and new features in an open-ended way.

On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli  wrote:

> Hi cassandra-dev@,
>
> With the goal of making Cassandra's 4.0 the most stable major release to
> date, we would like all committers of the project to consider joining us in
> dedicating their time and attention to testing, running, and fixing issues
> in 4.0 between the September freeze and the 4.0 beta release. This would
> result in a freeze of new feature development on trunk or branches during
> this period, instead focusing on writing, improving, and running tests or
> fixing and reviewing bugs or performance regressions found in 4.0 or
> earlier.
>
> How would this work?
>
> We propose 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. At the same time we do not want to discourage
> community contributions. Not all contributors can be expected to be aware
> of such a decision or may be new to the project. In cases where new
> features are contributed during this time, the contributor can be informed
> of the current status of the release process, be encouraged to contribute
> to testing or bug fixing, and have their feature reviewed after the beta is
> reached.
>
>
> What happens when beta is reached?
>
> Ideally, contributors who have made significant contributions to the
> release will stick around to continue testing between beta and final
> release. Any additional folks who continue this focus would also be greatly
> appreciated.
>
> What about before the freeze?
>
> Testing new features is of course important. This isn't meant to discourage
> development – only to enable us to focus on testing and hardening 4.0 to
> deliver Cassandra's most stable major release. We would like to see
> adoption of 4.0 happen much more quickly than its predecessor.
>
> Thanks for considering this proposal,
> Sankalp Kohli

Testing 4.0 Post-Freeze

[sankalp kohli]

Hi cassandra-dev@,

With the goal of making Cassandra's 4.0 the most stable major release to
date, we would like all committers of the project to consider joining us in
dedicating their time and attention to testing, running, and fixing issues
in 4.0 between the September freeze and the 4.0 beta release. This would
result in a freeze of new feature development on trunk or branches during
this period, instead focusing on writing, improving, and running tests or
fixing and reviewing bugs or performance regressions found in 4.0 or
earlier.

How would this work?

We propose 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. At the same time we do not want to discourage
community contributions. Not all contributors can be expected to be aware
of such a decision or may be new to the project. In cases where new
features are contributed during this time, the contributor can be informed
of the current status of the release process, be encouraged to contribute
to testing or bug fixing, and have their feature reviewed after the beta is
reached.


What happens when beta is reached?

Ideally, contributors who have made significant contributions to the
release will stick around to continue testing between beta and final
release. Any additional folks who continue this focus would also be greatly
appreciated.

What about before the freeze?

Testing new features is of course important. This isn't meant to discourage
development – only to enable us to focus on testing and hardening 4.0 to
deliver Cassandra's most stable major release. We would like to see
adoption of 4.0 happen much more quickly than its predecessor.

Thanks for considering this proposal,
Sankalp Kohli

Re: [VOTE] Release Apache Cassandra 2.2.13

[Brandon Williams]

+1

On Mon, Jul 2, 2018 at 3:10 PM, Michael Shuler 
wrote:

> I propose the following artifacts for release as 2.2.13.
>
> sha1: 9ff78249a0a5e87bd04bf9804ef1a3b29b5e1645
> Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=sho
> rtlog;h=refs/tags/2.2.13-tentative
> Artifacts: https://repository.apache.org/content/repositories/orgapache
> cassandra-1159/org/apache/cassandra/apache-cassandra/2.2.13/
> Staging repository: https://repository.apache.org/
> content/repositories/orgapachecassandra-1159/
>
> The Debian and RPM packages are available here:
> http://people.apache.org/~mshuler/
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) http://git-wip-us.apache.org/r
> epos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/
> tags/2.2.13-tentative
> [2]: (NEWS.txt) http://git-wip-us.apache.org/r
> epos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tag
> s/2.2.13-tentative
>
> --
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Difference between heartbeat and generation on a Gossip packet

[Abdelkrim Fitouri]

Hi Joe,

Thanks for the details it is more clear for me now !

Kind regards.
Abdelkarim.

Le jeu. 28 juin 2018 08:29, Joseph Lynch  a écrit :

> Hi Abdelkarim,
>
> Other people on this list are much more knowledgeable than me and can
> correct me if I'm wrong, but my understanding is that the combination of
> generation and version (aka heartbeat) form a logical clock tuple
> consisting of (generation, version) and that combination is the
> HeartBeatState.
>
> The generation is the really important part and roughly corresponds to the
> last start time of that particular Cassandra process in seconds since epoch
> plus any forced increments due to e.g. the gossiper stopping or starting
> (nodetool disable/enable gossip). The generation is further stored on disk
> in the system.local table so that during a crash or restart, even if the
> system's clock moves backwards, the Cassandra node's generation should
> never move backwards. Whenever a node's generation number changes it's
> considered a major gossip state update by other nodes because they have to
> do things like ensure they are speaking the right protocol version, compare
> schema, etc ... in addition to all the versioned state changes seen below.
>
> The version is a counter used to show the passage of time within a
> generation and is used to signal versioned gossip state changes. It starts
> at zero on process start and increases by one roughly every second. There
> are various pieces of metadata like a node's status, schema, rack, dc, host
> id, tokens, etc... which are all versioned using this version counter when
> they change (whatever shows up in nodetool gossipinfo is a good example of
> these states). When the gossiper is enabled, every second, each node
> increments
> their local version by one, picks another peer to gossip with, and sends
> out their map of versioned items to that peer; other nodes know to pick up
> any new data if the version has increased. Since nodes are all gossiping
> with each other, any update to one node's versioned data get's propagated
> out quickly even if that node may not have directly gossiped with everyone.
> Naturally, the version number only increases for a given generation, but if
> the generation changes the version moves backwards (resets to zero).
>
> So yea, think of (generation, version) as forming a logical clock which
> roughly corresponds to (~last process start in seconds since the epoch,
> ~seconds since last process start) for each node. This logical clock is
> used to create ordering in gossip state changes.
>
> Hope that was helpful,
> -Joey Lynch
>
> On Tue, Jun 26, 2018 at 3:09 PM Abdelkrim Fitouri 
> wrote:
>
> > Hello,
> >
> > I  am studying the gossip part on casssandra and wondering about the
> > difference between the heartbeat and generation data exchanged for the
> > autodiscovery.
> >
> > many thanks for any help.
> >
> > --
> >
> > Best Regards.
> >
> > Abdelkarim.
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.17

[Sam Tunnicliffe]

-1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the
effect on streaming is verified.  The concern is that the snitch change
could make cross DC streaming more likely. I’ve opened CASSANDRA-14555 for
this.


On 3 July 2018 at 04:02, Nate McCall  wrote:

> +1
>
> On Tue, Jul 3, 2018 at 8:10 AM, Michael Shuler 
> wrote:
> > I propose the following artifacts for release as 3.0.17.
> >
> > sha1: c4e6cd2a1aca84a88983192368bbcd4c8887c8b2
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.0.17-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1160/org/apache/cassandra/apache-cassandra/3.0.17/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1160/
> >
> > The Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler/
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt)
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative
> > [2]: (NEWS.txt)
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> blob_plain;f=NEWS.txt;hb=refs/tags/3.0.17-tentative
> >
> > --
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.11.3

[Sam Tunnicliffe]

-1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the
effect on streaming is verified.  The concern is that the snitch change
could make cross DC streaming more likely. I’ve opened CASSANDRA-14555 for
this.


On 3 July 2018 at 04:02, Nate McCall  wrote:

> +1
>
> On Tue, Jul 3, 2018 at 8:11 AM, Michael Shuler 
> wrote:
> > I propose the following artifacts for release as 3.11.3.
> >
> > sha1: aed1b5fdf1e953d19bdd021ba603618772208cdd
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.11.3-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1161/org/apache/cassandra/apache-cassandra/3.11.3/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1161/
> >
> > The Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler/
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt)
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative
> > [2]: (NEWS.txt)
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> blob_plain;f=NEWS.txt;hb=refs/tags/3.11.3-tentative
> >
> > --
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>