At Netflix, we use NDBench <https://github.com/Netflix/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 <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 <jmcken...@apache.org> > 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 <kohlisank...@gmail.com> > > 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
