[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 and new features in an open-ended way.

On Tue, Jul 3, 2018 at 1:33 PM sankalp kohli <kohlisankalp@xxxxxxxxx> 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