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