Yes? -- Jeff Jirsa
> On Jul 3, 2018, at 2:29 PM, Jonathan Ellis <jbel...@gmail.com> 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 <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 <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 >>> >> > > > > -- > 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
