git.net

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

Re: Testing 4.0 Post-Freeze


Yes?

-- 
Jeff Jirsa


> On Jul 3, 2018, at 2:29 PM, Jonathan Ellis <jbellis@xxxxxxxxx> 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 <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
>>> 
>> 
> 
> 
> 
> -- 
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced

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