git.net

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

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 off 4.0, and keep trunk technically active. But so long as there is a critical mass of active contributors who are on board with only/mostly working on stability, bug fixes, and validation - both as assignees and reviewers - we’ll have a de-facto freeze.

And I have a feeling that there is such a critical mass.

—
AY

On 3 July 2018 at 22:23:38, Jeff Jirsa (jjirsa@xxxxxxxxx) 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 <jon@xxxxxxxxxxxxx> 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 <jmckenzie@xxxxxxxxxx>  
> 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 <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  
> >  
> --  
> Jon Haddad  
> http://www.rustyrazorblade.com  
> twitter: rustyrazorblade  
>