Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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 stabi

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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:

Re: Testing 4.0 Post-Freeze

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

Re: [VOTE] Release Apache Cassandra 2.2.13

+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

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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 s

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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 re

Re: Testing 4.0 Post-Freeze

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 o

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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

Re: Testing 4.0 Post-Freeze

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 conv

Re: [VOTE] Release Apache Cassandra 2.2.13

+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=cas

Re: Testing 4.0 Post-Freeze

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 littl

Re: Testing 4.0 Post-Freeze

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

Testing 4.0 Post-Freeze

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 re

Re: [VOTE] Release Apache Cassandra 2.2.13

+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://rep

Re: Difference between heartbeat and generation on a Gossip packet

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 combi

Re: [VOTE] Release Apache Cassandra 3.0.17

-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

Re: [VOTE] Release Apache Cassandra 3.11.3

-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