git.net

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

Re: Testing 4.0 Post-Freeze


Does anyone has any more feedback on this? 

> On Jul 4, 2018, at 05:36, Aleksey Yeshchenko <aleksey@xxxxxxxxx> wrote:
> 
> 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  
>>>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx