git.net

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

Re: Testing 4.0 Post-Freeze


For what it’s worth, I’m fine with both formal branching-level freeze and informal ‘let people commit to trunk if they can find a reviewer’ one and will support either.

So long as either/both are communicated to the contributors, the only difference is in where new feature work gets accumulated: will stay a bit longer in personal branches in the latter way.

—
AY

On 4 July 2018 at 01:30:40, sankalp kohli (kohlisankalp@xxxxxxxxx) wrote:

Having an explicit way to tell the community that we all will work on  
testing is better than writing a patch which will sit without review for  
months. I think not having your patch reviewed for months is more  
discouraging than following the community and helping with stability of  
4.0.  



On Tue, Jul 3, 2018 at 3:02 PM Josh McKenzie <jmckenzie@xxxxxxxxxx> wrote:  

> >  
> > 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.  
>  
>  
> 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.  
>  
> These are two very different statements. :) Which is it?  
>  
> On Tue, Jul 3, 2018 at 5:57 PM Aleksey Yeshchenko <aleksey@xxxxxxxxx>  
> wrote:  
>  
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_thelastpickle_tlp-2Dstress&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ&s=f8gf_JCP6JRQIRkL_1R_zJOS_6gdAAsLleDr2PZHppE&e=  
> >  
> > >  
> > > 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  
> > >  
> >  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rustyrazorblade.com&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=qK2RkRAsGtixYf0IgKlRBYLfTrXyOKED9OOTyMVvDf4&m=l_G2ByhfCyu3k9TzNVqiagdVQ8vOMJqHZvDq_JKvbiQ&s=paSngQpMm3DhoWay8lDuWEYELVOrti8evQeT1LodXdY&e=  
> >  
> > > twitter: rustyrazorblade  
> > >  
>  


( ! ) Warning: include(msgfooter.php): failed to open stream: No such file or directory in /var/www/git/apache-cassandra-development/msg02308.html on line 250
Call Stack
#TimeMemoryFunctionLocation
10.0009358472{main}( ).../msg02308.html:0

( ! ) Warning: include(): Failed opening 'msgfooter.php' for inclusion (include_path='.:/var/www/git') in /var/www/git/apache-cassandra-development/msg02308.html on line 250
Call Stack
#TimeMemoryFunctionLocation
10.0009358472{main}( ).../msg02308.html:0