osdir.com


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

Re: Testing 4.0 Post-Freeze


If this motivates individuals and organizations to contribute time and resources to testing more before the release then +1.  The varied testing before the release will make a huge difference.

> On Jul 10, 2018, at 12:30 PM, Jeff Jirsa <jjirsa@xxxxxxxxx> wrote:
> 
> Ultimately, we have a consensus driven development. If Jonathan or Dave
> strongly disagrees with this, they can share their strong disagreement.
> 
> Jonathan shared his concern about dissuading contributors.
> 
> What's absurd is trying the same thing we've tried for 10 years and
> expecting things to magically change. We know that a lot of folks are
> lining up to test the 4.0 release. If people who have contributed enough to
> be able to commit have time to work on features, the proposal is that the
> project make it known that we'd rather have them work on testing than
> commit their patch, or hold their patch until testing is done. That doesn't
> mean they're suddenly not allowed to commit, it's that we'd prefer they use
> their time and attention in a more constructive manner.
> 
> - Jeff
> 
> 
> 
> On Tue, Jul 10, 2018 at 10:18 AM, Jonathan Haddad <jon@xxxxxxxxxxxxx> wrote:
> 
>> I guess I look at the initial voting in of committers as the process
>> by which people are trusted to merge things in.  This proposed process
>> revokes that trust. If Jonathan Ellis or Dave Brosius (arbitrarily
>> picked) wants to merge a new feature into trunk during the freeze, now
>> they're not allowed?  That's absurd.  People have already met the bar
>> and have been voted in by merit, they should not have their privilege
>> revoked.
>> On Tue, Jul 10, 2018 at 10:14 AM Ben Bromhead <ben@xxxxxxxxxxxxxxx> wrote:
>>> 
>>> Well put Mick
>>> 
>>> +1
>>> 
>>> On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko <aleksey@xxxxxxxxx>
>>> wrote:
>>> 
>>>> +1 from me too.
>>>> 
>>>> —
>>>> AY
>>>> 
>>>> On 10 July 2018 at 04:17:26, Mick Semb Wever (mck@xxxxxxxxxx) wrote:
>>>> 
>>>> 
>>>>> We have done all this for previous releases and we know it has not
>>>> worked
>>>>> well. So how giving it one more try is going to help here. Can
>> someone
>>>>> outline what will change for 4.0 which will make it more successful?
>>>> 
>>>> 
>>>> I (again) agree with you Sankalp :-)
>>>> 
>>>> Why not try something new?
>>>> It's easier to discuss these things more genuinely after trying it out.
>>>> 
>>>> One of the differences in the branching approaches: to feature-freeze
>> on a
>>>> 4.0 branch or on trunk; is who it is that has to then merge and work
>> with
>>>> multiple branches.
>>>> 
>>>> Where that small but additional effort is placed I think becomes a
>> signal
>>>> to what the community values most: new features or stability.
>>>> 
>>>> I think most folk would vote for stability, so why not give this
>> approach
>>>> a go and to learn from it.
>>>> It also creates an incentive to make the feature-freeze period as
>> short as
>>>> possible, moving us towards an eventual goal of not needing to
>>>> feature-freeze at all.
>>>> 
>>>> regards,
>>>> Mick
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
>>>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>>>> 
>>>> --
>>> Ben Bromhead
>>> CTO | Instaclustr <https://www.instaclustr.com/>
>>> +1 650 284 9692
>>> Reliability at Scale
>>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
>> 
>> 
>> 
>> --
>> Jon Haddad
>> http://www.rustyrazorblade.com
>> twitter: rustyrazorblade
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
>> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>> 
>> 


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