Re: Testing 4.0 Post-Freeze

[Aleksey Yeshchenko]

+1 from me too.

—
AY

On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org  
For additional commands, e-mail: dev-h...@cassandra.apache.org  

Re: Testing 4.0 Post-Freeze

[Ben Bromhead]

Well put Mick

+1

On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko 
wrote:

> +1 from me too.
>
> —
> AY
>
> On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> --
Ben Bromhead
CTO | Instaclustr 
+1 650 284 9692
Reliability at Scale
Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer

Re: Testing 4.0 Post-Freeze

[Jonathan Haddad]

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  wrote:
>
> Well put Mick
>
> +1
>
> On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko 
> wrote:
>
> > +1 from me too.
> >
> > —
> > AY
> >
> > On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > --
> Ben Bromhead
> CTO | Instaclustr 
> +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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Testing 4.0 Post-Freeze

[Jeff Jirsa]

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  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  wrote:
> >
> > Well put Mick
> >
> > +1
> >
> > On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko 
> > wrote:
> >
> > > +1 from me too.
> > >
> > > —
> > > AY
> > >
> > > On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > > --
> > Ben Bromhead
> > CTO | Instaclustr 
> > +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-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Testing 4.0 Post-Freeze

[Benedict Elliott Smith]

That’s a peculiar way of looking at it.  

Committer status is not an absolute right to autonomy over the codebase.  It’s 
an embodiment of trust that you will follow the community's prevailing rules 
around commit, and that you’re competent to do so. 

If the community wants to change those rules you’re trusted to follow, how does 
this modify your right, or the trust emplaced in you?





> On 10 Jul 2018, at 10:18, Jonathan Haddad  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  wrote:
>> 
>> Well put Mick
>> 
>> +1
>> 
>> On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko 
>> wrote:
>> 
>>> +1 from me too.
>>> 
>>> —
>>> AY
>>> 
>>> On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> --
>> Ben Bromhead
>> CTO | Instaclustr 
>> +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-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Testing 4.0 Post-Freeze

[Jonathan Haddad]

I guess I look at the idea of changing the branching strategy as a
means of blocking work as a very odd way of solving a human problem.
Having a majority of votes temporarily block potentially good work
might be a good thing, and it might not matter at all.  It might also
frustrate some folks who have been around for a really long time.

I'm also making the assumption that I don't know every plausible
reason someone might need / want to merge into trunk and considering
that there's valid cases for it that we'll be blocking.

With regard to "the process has been broken for years" I've already
said my bit on what I considered to different now, nobody has
responded to that yet.  I think I've said all I need to on this, it's
probably just noise now, so I won't respond any further on this
thread.  I don't anticipate having a personal need to commit to a
future 5.0 release before 4.0 is out, so it won't impact me
personally.

On Tue, Jul 10, 2018 at 10:32 AM Benedict Elliott Smith
 wrote:
>
> That’s a peculiar way of looking at it.
>
> Committer status is not an absolute right to autonomy over the codebase.  
> It’s an embodiment of trust that you will follow the community's prevailing 
> rules around commit, and that you’re competent to do so.
>
> If the community wants to change those rules you’re trusted to follow, how 
> does this modify your right, or the trust emplaced in you?
>
>
>
>
>
> > On 10 Jul 2018, at 10:18, Jonathan Haddad  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  wrote:
> >>
> >> Well put Mick
> >>
> >> +1
> >>
> >> On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko 
> >> wrote:
> >>
> >>> +1 from me too.
> >>>
> >>> —
> >>> AY
> >>>
> >>> On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>> --
> >> Ben Bromhead
> >> CTO | Instaclustr 
> >> +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-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>


-- 
Jon Haddad
http://www.rustyrazorblade.com
twitter: rustyrazorblade

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Testing 4.0 Post-Freeze

[Benedict Elliott Smith]

It’s not like this is an irrevocable change.  

If we encounter a scenario that seems to question its validity, or its general 
applicability, it can be raised on the mailing list and we can revisit the 
decision, surely?  I can think of at least one way to weaken the rules in such 
a scenario, without frustrating the goal, but why complicate things when we 
can’t even yet imagine a situation to need it - besides discouraging a new 
contributor who, let’s be honest, was going to have their patch languish for a 
few months while somebody found time to review it anyway.  At least this way we 
can give them a decent excuse!



> On 10 Jul 2018, at 10:43, Jonathan Haddad  wrote:
> 
> I guess I look at the idea of changing the branching strategy as a
> means of blocking work as a very odd way of solving a human problem.
> Having a majority of votes temporarily block potentially good work
> might be a good thing, and it might not matter at all.  It might also
> frustrate some folks who have been around for a really long time.
> 
> I'm also making the assumption that I don't know every plausible
> reason someone might need / want to merge into trunk and considering
> that there's valid cases for it that we'll be blocking.
> 
> With regard to "the process has been broken for years" I've already
> said my bit on what I considered to different now, nobody has
> responded to that yet.  I think I've said all I need to on this, it's
> probably just noise now, so I won't respond any further on this
> thread.  I don't anticipate having a personal need to commit to a
> future 5.0 release before 4.0 is out, so it won't impact me
> personally.
> 
> On Tue, Jul 10, 2018 at 10:32 AM Benedict Elliott Smith
>  wrote:
>> 
>> That’s a peculiar way of looking at it.
>> 
>> Committer status is not an absolute right to autonomy over the codebase.  
>> It’s an embodiment of trust that you will follow the community's prevailing 
>> rules around commit, and that you’re competent to do so.
>> 
>> If the community wants to change those rules you’re trusted to follow, how 
>> does this modify your right, or the trust emplaced in you?
>> 
>> 
>> 
>> 
>> 
>>> On 10 Jul 2018, at 10:18, Jonathan Haddad  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  wrote:
 
 Well put Mick
 
 +1
 
 On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko 
 wrote:
 
> +1 from me too.
> 
> —
> AY
> 
> On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> --
 Ben Bromhead
 CTO | Instaclustr 
 +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-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional comma

Re: Testing 4.0 Post-Freeze

[Marcus Eriksson]

+1 here as well

On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko 
wrote:

> +1 from me too.
>
> —
> AY
>
> On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Testing 4.0 Post-Freeze

[Jonathan Haddad]

You're right - if we do decide we're wrong we can always create the
branch later.

I retract my -1.
On Tue, Jul 10, 2018 at 10:50 AM Benedict Elliott Smith
 wrote:
>
> It’s not like this is an irrevocable change.
>
> If we encounter a scenario that seems to question its validity, or its 
> general applicability, it can be raised on the mailing list and we can 
> revisit the decision, surely?  I can think of at least one way to weaken the 
> rules in such a scenario, without frustrating the goal, but why complicate 
> things when we can’t even yet imagine a situation to need it - besides 
> discouraging a new contributor who, let’s be honest, was going to have their 
> patch languish for a few months while somebody found time to review it 
> anyway.  At least this way we can give them a decent excuse!
>
>
>
> > On 10 Jul 2018, at 10:43, Jonathan Haddad  wrote:
> >
> > I guess I look at the idea of changing the branching strategy as a
> > means of blocking work as a very odd way of solving a human problem.
> > Having a majority of votes temporarily block potentially good work
> > might be a good thing, and it might not matter at all.  It might also
> > frustrate some folks who have been around for a really long time.
> >
> > I'm also making the assumption that I don't know every plausible
> > reason someone might need / want to merge into trunk and considering
> > that there's valid cases for it that we'll be blocking.
> >
> > With regard to "the process has been broken for years" I've already
> > said my bit on what I considered to different now, nobody has
> > responded to that yet.  I think I've said all I need to on this, it's
> > probably just noise now, so I won't respond any further on this
> > thread.  I don't anticipate having a personal need to commit to a
> > future 5.0 release before 4.0 is out, so it won't impact me
> > personally.
> >
> > On Tue, Jul 10, 2018 at 10:32 AM Benedict Elliott Smith
> >  wrote:
> >>
> >> That’s a peculiar way of looking at it.
> >>
> >> Committer status is not an absolute right to autonomy over the codebase.  
> >> It’s an embodiment of trust that you will follow the community's 
> >> prevailing rules around commit, and that you’re competent to do so.
> >>
> >> If the community wants to change those rules you’re trusted to follow, how 
> >> does this modify your right, or the trust emplaced in you?
> >>
> >>
> >>
> >>
> >>
> >>> On 10 Jul 2018, at 10:18, Jonathan Haddad  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  
> >>> wrote:
> 
>  Well put Mick
> 
>  +1
> 
>  On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko 
>  wrote:
> 
> > +1 from me too.
> >
> > —
> > AY
> >
> > On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> > --
>  Ben Bromhead
>  CTO | Instaclustr 
>  +1 650 284 9692
>  Reliability at Scale
>  Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
> >>>
> >>>
> >>>
> >>> --
> >>> Jon Haddad
> >>> http://www.rustyrazorblade.co

Re: Testing 4.0 Post-Freeze

[Dinesh Joshi]

> On Jul 10, 2018, at 10:18 AM, Jonathan Haddad  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.

Is it so bad to leave features in branches for a bit longer while we try to get 
a stable release out? The proposal is for committers to hold off committing 
features into trunk while we test and stabilize it. Why don’t we give it a try 
and see if it works?

If we fail to get consensus, we have failed even without trying something new. 
What is worse?

Dinesh

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Testing 4.0 Post-Freeze

[Sam Tunnicliffe]

+1 here too

On Tue, 10 Jul 2018 at 18:52, Marcus Eriksson  wrote:

> +1 here as well
>
> On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko 
> wrote:
>
> > +1 from me too.
> >
> > —
> > AY
> >
> > On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: Testing 4.0 Post-Freeze

[Jeremy Hanna]

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  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  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  wrote:
>>> 
>>> Well put Mick
>>> 
>>> +1
>>> 
>>> On Tue, Jul 10, 2018 at 1:06 PM Aleksey Yeshchenko 
>>> wrote:
>>> 
 +1 from me too.
 
 —
 AY
 
 On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
 --
>>> Ben Bromhead
>>> CTO | Instaclustr 
>>> +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-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Testing 4.0 Post-Freeze

[Blake Eggleston]

+1 from me as well. Let's try it out

On 7/10/18, 11:23 AM, "Sam Tunnicliffe"  wrote:

+1 here too

On Tue, 10 Jul 2018 at 18:52, Marcus Eriksson  wrote:

> +1 here as well
>
> On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko 
> wrote:
>
> > +1 from me too.
> >
> > —
> > AY
> >
> > On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) 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-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>




-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org