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

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

[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

[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

[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

[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

[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

[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]

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

[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

[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

[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

[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

[Benedict Elliott Smith]

+1.



> On 9 Jul 2018, at 20:17, Mick Semb Wever  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

Re: Testing 4.0 Post-Freeze

[Mick Semb Wever]

> 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

[sankalp kohli]

Sure...thats an addition to the 3 states I was thinking(-1,+/-0 and +1) :)

On Mon, Jul 9, 2018 at 12:49 PM Josh McKenzie  wrote:

> >
> > I did not see a -1 but all +0s and a few +1s.
>
> It's more accurate to say you have quite a few -0's, some +0's, and a few
> +1's, probably some -0.5's if you're into that.
>
> On Mon, Jul 9, 2018 at 2:53 PM Jeremy Hanna 
> wrote:
>
> > What I’m saying is that for new contributors, not branching has a cost
> and
> > I think there are other ways to organize efforts.
> >
> > One of the suggestions was for each organization to test their own use
> > cases in the stabilization process.  I don’t think that’s been done very
> > effectively previously.  Most organizations only do any sort of
> significant
> > testing when they’re about to put their clusters on the line - i.e. once
> a
> > version has several post GA point releases.  That’s logical and no one
> > wants to be the first one to production.  However, if people were to
> agree
> > to do some form of testing pre-release, then I think that would be a step
> > in the right direction.  In the early days of the project I tried to do
> > this in a small way by testing the Hadoop support for every release
> (major
> > and minor) since it wasn’t on everyone’s radar but was important to me.
> > Then I would vote with a non-binding vote and described what was tested.
> >
> > > On Jul 9, 2018, at 1:30 PM, sankalp kohli 
> > 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?
> > >
> > > Not branching is one idea but we should discuss what will change now
> than
> > > iterating what has already happened.
> > >
> > > On Mon, Jul 9, 2018 at 11:25 AM Jeremy Hanna <
> jeremy.hanna1...@gmail.com
> > >
> > > wrote:
> > >
> > >> I wholeheartedly agree with efforts to make releases more stable and
> the
> > >> more contributors that add tests or test within the context of their
> own
> > >> use cases, the better.  +1 non-binding to the idea of better, more
> > complete
> > >> testing for releases.
> > >>
> > >> When it comes to how to do this, I think that’s where there is
> > >> disagreement.  I personally don’t think that branching detracts from
> the
> > >> goal of stabilization.  There are a couple of personas involved here:
> > >>
> > >> * Longtime contributors/committers: I think it’s sufficient to
> generally
> > >> ask that whatever time/effort they can contribute be towards
> > stabilizing,
> > >> testing, and especially testing their production scenarios to cover
> more
> > >> surface area when it comes to usage edge cases.  That along with
> testing
> > >> longer running things in those scenarios for other types of edge
> cases.
> > >>
> > >> * New contributors: They likely won’t know about the strategy.
> They’re
> > >> just poking around and looking at lhf tickets or tickets that they
> need
> > >> done.  Those are typically low risk but at the same time we don’t want
> > to
> > >> compromise stability by merging those in.  Reviewing low risk stuff
> for
> > >> inclusion doesn’t take a ton of time and gives them a sense that they
> > can
> > >> be of help and empowers them.  After they have that first experience,
> > then
> > >> a longer term contributor could share with them a blog post or tldr
> > thread
> > >> summary about the 4.0 stabilization efforts (would be nice to have one
> > to
> > >> point people too once we're done).  We could also start creating lhf
> > >> tickets with stabilization and testing in mind.
> > >>
> > >> Unless we want to make a fundamental change to the project’s process
> > >> (making trunk stable at all times going forward), then I don’t think
> > >> there’s a reason why branching would detract from these efforts.  In
> > other
> > >> words if we’re just trying to say that we want to focus on
> stabilization
> > >> for the alpha/beta/rc of 4.0, then I would prefer branching along with
> > >> clear messaging.
> > >>
> > >> Jeremy
> > >>
> > >>> On Jul 9, 2018, at 12:43 PM, sankalp kohli 
> > >> wrote:
> > >>>
> > >>> How is this preventing someone from working and collaborating on an
> > >> Apache
> > >>> Project? You can still collaborate on making 4.0 more stable.
> > >>>
> > >>> Why will these committers not work on making 4.0 more stable and fix
> > >> broken
> > >>> tests? Considering  we cannot release without test passing, how will
> > >> these
> > >>> features be used?
> > >>>
> > >>> On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad 
> > >> wrote:
> > >>>
> >  I don't see how changing the process and banning feature commits is
> >  going to be any help to the project. There may be a couple
> committers
> >  who are interested in committing new features.
> > 
> >  I'm a -1 on changing the branching strategy in a way that prevents
> >  people from working and collaborating

Re: Testing 4.0 Post-Freeze

[Josh McKenzie]

>
> I did not see a -1 but all +0s and a few +1s.

It's more accurate to say you have quite a few -0's, some +0's, and a few
+1's, probably some -0.5's if you're into that.

On Mon, Jul 9, 2018 at 2:53 PM Jeremy Hanna 
wrote:

> What I’m saying is that for new contributors, not branching has a cost and
> I think there are other ways to organize efforts.
>
> One of the suggestions was for each organization to test their own use
> cases in the stabilization process.  I don’t think that’s been done very
> effectively previously.  Most organizations only do any sort of significant
> testing when they’re about to put their clusters on the line - i.e. once a
> version has several post GA point releases.  That’s logical and no one
> wants to be the first one to production.  However, if people were to agree
> to do some form of testing pre-release, then I think that would be a step
> in the right direction.  In the early days of the project I tried to do
> this in a small way by testing the Hadoop support for every release (major
> and minor) since it wasn’t on everyone’s radar but was important to me.
> Then I would vote with a non-binding vote and described what was tested.
>
> > On Jul 9, 2018, at 1:30 PM, sankalp kohli 
> 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?
> >
> > Not branching is one idea but we should discuss what will change now than
> > iterating what has already happened.
> >
> > On Mon, Jul 9, 2018 at 11:25 AM Jeremy Hanna  >
> > wrote:
> >
> >> I wholeheartedly agree with efforts to make releases more stable and the
> >> more contributors that add tests or test within the context of their own
> >> use cases, the better.  +1 non-binding to the idea of better, more
> complete
> >> testing for releases.
> >>
> >> When it comes to how to do this, I think that’s where there is
> >> disagreement.  I personally don’t think that branching detracts from the
> >> goal of stabilization.  There are a couple of personas involved here:
> >>
> >> * Longtime contributors/committers: I think it’s sufficient to generally
> >> ask that whatever time/effort they can contribute be towards
> stabilizing,
> >> testing, and especially testing their production scenarios to cover more
> >> surface area when it comes to usage edge cases.  That along with testing
> >> longer running things in those scenarios for other types of edge cases.
> >>
> >> * New contributors: They likely won’t know about the strategy.  They’re
> >> just poking around and looking at lhf tickets or tickets that they need
> >> done.  Those are typically low risk but at the same time we don’t want
> to
> >> compromise stability by merging those in.  Reviewing low risk stuff for
> >> inclusion doesn’t take a ton of time and gives them a sense that they
> can
> >> be of help and empowers them.  After they have that first experience,
> then
> >> a longer term contributor could share with them a blog post or tldr
> thread
> >> summary about the 4.0 stabilization efforts (would be nice to have one
> to
> >> point people too once we're done).  We could also start creating lhf
> >> tickets with stabilization and testing in mind.
> >>
> >> Unless we want to make a fundamental change to the project’s process
> >> (making trunk stable at all times going forward), then I don’t think
> >> there’s a reason why branching would detract from these efforts.  In
> other
> >> words if we’re just trying to say that we want to focus on stabilization
> >> for the alpha/beta/rc of 4.0, then I would prefer branching along with
> >> clear messaging.
> >>
> >> Jeremy
> >>
> >>> On Jul 9, 2018, at 12:43 PM, sankalp kohli 
> >> wrote:
> >>>
> >>> How is this preventing someone from working and collaborating on an
> >> Apache
> >>> Project? You can still collaborate on making 4.0 more stable.
> >>>
> >>> Why will these committers not work on making 4.0 more stable and fix
> >> broken
> >>> tests? Considering  we cannot release without test passing, how will
> >> these
> >>> features be used?
> >>>
> >>> On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad 
> >> wrote:
> >>>
>  I don't see how changing the process and banning feature commits is
>  going to be any help to the project. There may be a couple committers
>  who are interested in committing new features.
> 
>  I'm a -1 on changing the branching strategy in a way that prevents
>  people from working and collaborating on an Apache project.
> 
>  On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli 
>  wrote:
> >
> > I did not see a -1 but all +0s and a few +1s.
> >
> > On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie 
>  wrote:
> >
> >> What did we land on? Sounds like we're pretty split without
> consensus
>  on
> >> "change the old branching strategy and reject new things on 

Re: Testing 4.0 Post-Freeze

[Jonathan Haddad]

The most impactful change that I can see is the people that are
involved with development who are willing to -1 a release.  Those of
us with votes are TLP have a big incentive for 4.0 to be stable - we
want people to upgrade.  I assume folks at Netflix, Apple are also
very incentivized to see a very stable 4.0. That's a lot of committer
head count already.

I don't remember much community call to action in the past with regard
to getting folks testing releases with real workloads.  If we want
help, it's on us to ask.  Making it as easy as possible to test stuff
out and get feedback is also on us.  Banning folks from committing to
trunk isn't solving the main problem: it's still pretty difficult to
get involved.  We need to lower the barrier to entry for setting &
tearing down test clusters.  We also need to recruit community members
to be part of a QA feedback cycle.  Once folks are in, keeping them
involved for multiple iterations will improve their ability to give
feedback.

The nice part is, if we do it right, eventually maybe those folks will
commit some code and become committers down the line.

On Mon, Jul 9, 2018 at 11:31 AM sankalp kohli  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?
>
> Not branching is one idea but we should discuss what will change now than
> iterating what has already happened.
>
> On Mon, Jul 9, 2018 at 11:25 AM Jeremy Hanna 
> wrote:
>
> > I wholeheartedly agree with efforts to make releases more stable and the
> > more contributors that add tests or test within the context of their own
> > use cases, the better.  +1 non-binding to the idea of better, more complete
> > testing for releases.
> >
> > When it comes to how to do this, I think that’s where there is
> > disagreement.  I personally don’t think that branching detracts from the
> > goal of stabilization.  There are a couple of personas involved here:
> >
> > * Longtime contributors/committers: I think it’s sufficient to generally
> > ask that whatever time/effort they can contribute be towards stabilizing,
> > testing, and especially testing their production scenarios to cover more
> > surface area when it comes to usage edge cases.  That along with testing
> > longer running things in those scenarios for other types of edge cases.
> >
> > * New contributors: They likely won’t know about the strategy.  They’re
> > just poking around and looking at lhf tickets or tickets that they need
> > done.  Those are typically low risk but at the same time we don’t want to
> > compromise stability by merging those in.  Reviewing low risk stuff for
> > inclusion doesn’t take a ton of time and gives them a sense that they can
> > be of help and empowers them.  After they have that first experience, then
> > a longer term contributor could share with them a blog post or tldr thread
> > summary about the 4.0 stabilization efforts (would be nice to have one to
> > point people too once we're done).  We could also start creating lhf
> > tickets with stabilization and testing in mind.
> >
> > Unless we want to make a fundamental change to the project’s process
> > (making trunk stable at all times going forward), then I don’t think
> > there’s a reason why branching would detract from these efforts.  In other
> > words if we’re just trying to say that we want to focus on stabilization
> > for the alpha/beta/rc of 4.0, then I would prefer branching along with
> > clear messaging.
> >
> > Jeremy
> >
> > > On Jul 9, 2018, at 12:43 PM, sankalp kohli 
> > wrote:
> > >
> > > How is this preventing someone from working and collaborating on an
> > Apache
> > > Project? You can still collaborate on making 4.0 more stable.
> > >
> > > Why will these committers not work on making 4.0 more stable and fix
> > broken
> > > tests? Considering  we cannot release without test passing, how will
> > these
> > > features be used?
> > >
> > > On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad 
> > wrote:
> > >
> > >> I don't see how changing the process and banning feature commits is
> > >> going to be any help to the project. There may be a couple committers
> > >> who are interested in committing new features.
> > >>
> > >> I'm a -1 on changing the branching strategy in a way that prevents
> > >> people from working and collaborating on an Apache project.
> > >>
> > >> On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli 
> > >> wrote:
> > >>>
> > >>> I did not see a -1 but all +0s and a few +1s.
> > >>>
> > >>> On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie 
> > >> wrote:
> > >>>
> >  What did we land on? Sounds like we're pretty split without consensus
> > >> on
> >  "change the old branching strategy and reject new things on trunk
> > >> during
> >  stabilization" vs. "keep doing things the way we did but message
> > >> strongly
> >  that we won't be reviewing new thing

Re: Testing 4.0 Post-Freeze

[Jeremy Hanna]

What I’m saying is that for new contributors, not branching has a cost and I 
think there are other ways to organize efforts.

One of the suggestions was for each organization to test their own use cases in 
the stabilization process.  I don’t think that’s been done very effectively 
previously.  Most organizations only do any sort of significant testing when 
they’re about to put their clusters on the line - i.e. once a version has 
several post GA point releases.  That’s logical and no one wants to be the 
first one to production.  However, if people were to agree to do some form of 
testing pre-release, then I think that would be a step in the right direction.  
In the early days of the project I tried to do this in a small way by testing 
the Hadoop support for every release (major and minor) since it wasn’t on 
everyone’s radar but was important to me.  Then I would vote with a non-binding 
vote and described what was tested.

> On Jul 9, 2018, at 1:30 PM, sankalp kohli  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?
> 
> Not branching is one idea but we should discuss what will change now than
> iterating what has already happened.
> 
> On Mon, Jul 9, 2018 at 11:25 AM Jeremy Hanna 
> wrote:
> 
>> I wholeheartedly agree with efforts to make releases more stable and the
>> more contributors that add tests or test within the context of their own
>> use cases, the better.  +1 non-binding to the idea of better, more complete
>> testing for releases.
>> 
>> When it comes to how to do this, I think that’s where there is
>> disagreement.  I personally don’t think that branching detracts from the
>> goal of stabilization.  There are a couple of personas involved here:
>> 
>> * Longtime contributors/committers: I think it’s sufficient to generally
>> ask that whatever time/effort they can contribute be towards stabilizing,
>> testing, and especially testing their production scenarios to cover more
>> surface area when it comes to usage edge cases.  That along with testing
>> longer running things in those scenarios for other types of edge cases.
>> 
>> * New contributors: They likely won’t know about the strategy.  They’re
>> just poking around and looking at lhf tickets or tickets that they need
>> done.  Those are typically low risk but at the same time we don’t want to
>> compromise stability by merging those in.  Reviewing low risk stuff for
>> inclusion doesn’t take a ton of time and gives them a sense that they can
>> be of help and empowers them.  After they have that first experience, then
>> a longer term contributor could share with them a blog post or tldr thread
>> summary about the 4.0 stabilization efforts (would be nice to have one to
>> point people too once we're done).  We could also start creating lhf
>> tickets with stabilization and testing in mind.
>> 
>> Unless we want to make a fundamental change to the project’s process
>> (making trunk stable at all times going forward), then I don’t think
>> there’s a reason why branching would detract from these efforts.  In other
>> words if we’re just trying to say that we want to focus on stabilization
>> for the alpha/beta/rc of 4.0, then I would prefer branching along with
>> clear messaging.
>> 
>> Jeremy
>> 
>>> On Jul 9, 2018, at 12:43 PM, sankalp kohli 
>> wrote:
>>> 
>>> How is this preventing someone from working and collaborating on an
>> Apache
>>> Project? You can still collaborate on making 4.0 more stable.
>>> 
>>> Why will these committers not work on making 4.0 more stable and fix
>> broken
>>> tests? Considering  we cannot release without test passing, how will
>> these
>>> features be used?
>>> 
>>> On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad 
>> wrote:
>>> 
 I don't see how changing the process and banning feature commits is
 going to be any help to the project. There may be a couple committers
 who are interested in committing new features.
 
 I'm a -1 on changing the branching strategy in a way that prevents
 people from working and collaborating on an Apache project.
 
 On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli 
 wrote:
> 
> I did not see a -1 but all +0s and a few +1s.
> 
> On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie 
 wrote:
> 
>> What did we land on? Sounds like we're pretty split without consensus
 on
>> "change the old branching strategy and reject new things on trunk
 during
>> stabilization" vs. "keep doing things the way we did but message
 strongly
>> that we won't be reviewing new things until 4.0 is stable".
>> 
>> On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli 
>> wrote:
>> 
>>> Does anyone has any more feedback on this?
>>> 
 On Jul 4, 2018, at 05:36, Aleksey Yeshchenko 
>> wrote:
 
 For wh

Re: Testing 4.0 Post-Freeze

[sankalp kohli]

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?

Not branching is one idea but we should discuss what will change now than
iterating what has already happened.

On Mon, Jul 9, 2018 at 11:25 AM Jeremy Hanna 
wrote:

> I wholeheartedly agree with efforts to make releases more stable and the
> more contributors that add tests or test within the context of their own
> use cases, the better.  +1 non-binding to the idea of better, more complete
> testing for releases.
>
> When it comes to how to do this, I think that’s where there is
> disagreement.  I personally don’t think that branching detracts from the
> goal of stabilization.  There are a couple of personas involved here:
>
> * Longtime contributors/committers: I think it’s sufficient to generally
> ask that whatever time/effort they can contribute be towards stabilizing,
> testing, and especially testing their production scenarios to cover more
> surface area when it comes to usage edge cases.  That along with testing
> longer running things in those scenarios for other types of edge cases.
>
> * New contributors: They likely won’t know about the strategy.  They’re
> just poking around and looking at lhf tickets or tickets that they need
> done.  Those are typically low risk but at the same time we don’t want to
> compromise stability by merging those in.  Reviewing low risk stuff for
> inclusion doesn’t take a ton of time and gives them a sense that they can
> be of help and empowers them.  After they have that first experience, then
> a longer term contributor could share with them a blog post or tldr thread
> summary about the 4.0 stabilization efforts (would be nice to have one to
> point people too once we're done).  We could also start creating lhf
> tickets with stabilization and testing in mind.
>
> Unless we want to make a fundamental change to the project’s process
> (making trunk stable at all times going forward), then I don’t think
> there’s a reason why branching would detract from these efforts.  In other
> words if we’re just trying to say that we want to focus on stabilization
> for the alpha/beta/rc of 4.0, then I would prefer branching along with
> clear messaging.
>
> Jeremy
>
> > On Jul 9, 2018, at 12:43 PM, sankalp kohli 
> wrote:
> >
> > How is this preventing someone from working and collaborating on an
> Apache
> > Project? You can still collaborate on making 4.0 more stable.
> >
> > Why will these committers not work on making 4.0 more stable and fix
> broken
> > tests? Considering  we cannot release without test passing, how will
> these
> > features be used?
> >
> > On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad 
> wrote:
> >
> >> I don't see how changing the process and banning feature commits is
> >> going to be any help to the project. There may be a couple committers
> >> who are interested in committing new features.
> >>
> >> I'm a -1 on changing the branching strategy in a way that prevents
> >> people from working and collaborating on an Apache project.
> >>
> >> On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli 
> >> wrote:
> >>>
> >>> I did not see a -1 but all +0s and a few +1s.
> >>>
> >>> On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie 
> >> wrote:
> >>>
>  What did we land on? Sounds like we're pretty split without consensus
> >> on
>  "change the old branching strategy and reject new things on trunk
> >> during
>  stabilization" vs. "keep doing things the way we did but message
> >> strongly
>  that we won't be reviewing new things until 4.0 is stable".
> 
>  On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli 
>  wrote:
> 
> > Does anyone has any more feedback on this?
> >
> >> On Jul 4, 2018, at 05:36, Aleksey Yeshchenko 
>  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 (kohlisank...@gmail.com)
> > 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  >>>
> > wrote:
> >>
> 
>  We propose that between the S

Re: Testing 4.0 Post-Freeze

[Jeremy Hanna]

I wholeheartedly agree with efforts to make releases more stable and the more 
contributors that add tests or test within the context of their own use cases, 
the better.  +1 non-binding to the idea of better, more complete testing for 
releases.

When it comes to how to do this, I think that’s where there is disagreement.  I 
personally don’t think that branching detracts from the goal of stabilization.  
There are a couple of personas involved here:

* Longtime contributors/committers: I think it’s sufficient to generally ask 
that whatever time/effort they can contribute be towards stabilizing, testing, 
and especially testing their production scenarios to cover more surface area 
when it comes to usage edge cases.  That along with testing longer running 
things in those scenarios for other types of edge cases.

* New contributors: They likely won’t know about the strategy.  They’re just 
poking around and looking at lhf tickets or tickets that they need done.  Those 
are typically low risk but at the same time we don’t want to compromise 
stability by merging those in.  Reviewing low risk stuff for inclusion doesn’t 
take a ton of time and gives them a sense that they can be of help and empowers 
them.  After they have that first experience, then a longer term contributor 
could share with them a blog post or tldr thread summary about the 4.0 
stabilization efforts (would be nice to have one to point people too once we're 
done).  We could also start creating lhf tickets with stabilization and testing 
in mind.

Unless we want to make a fundamental change to the project’s process (making 
trunk stable at all times going forward), then I don’t think there’s a reason 
why branching would detract from these efforts.  In other words if we’re just 
trying to say that we want to focus on stabilization for the alpha/beta/rc of 
4.0, then I would prefer branching along with clear messaging.

Jeremy

> On Jul 9, 2018, at 12:43 PM, sankalp kohli  wrote:
> 
> How is this preventing someone from working and collaborating on an Apache
> Project? You can still collaborate on making 4.0 more stable.
> 
> Why will these committers not work on making 4.0 more stable and fix broken
> tests? Considering  we cannot release without test passing, how will these
> features be used?
> 
> On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad  wrote:
> 
>> I don't see how changing the process and banning feature commits is
>> going to be any help to the project. There may be a couple committers
>> who are interested in committing new features.
>> 
>> I'm a -1 on changing the branching strategy in a way that prevents
>> people from working and collaborating on an Apache project.
>> 
>> On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli 
>> wrote:
>>> 
>>> I did not see a -1 but all +0s and a few +1s.
>>> 
>>> On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie 
>> wrote:
>>> 
 What did we land on? Sounds like we're pretty split without consensus
>> on
 "change the old branching strategy and reject new things on trunk
>> during
 stabilization" vs. "keep doing things the way we did but message
>> strongly
 that we won't be reviewing new things until 4.0 is stable".
 
 On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli 
 wrote:
 
> Does anyone has any more feedback on this?
> 
>> On Jul 4, 2018, at 05:36, Aleksey Yeshchenko 
 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 (kohlisank...@gmail.com)
> 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 >> 
> 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 <
>> alek

Re: Testing 4.0 Post-Freeze

[Jonathan Haddad]

My proposal is that we implement everything you're suggesting, except
we branch off as we have in the past rather than locking down trunk.
I'd encourage everyone to work to improve 4.0 in some way or another,
whether it be fixing bugs, testing in a staging environment
(feedback), writing tooling (data loaders, stress testing, cluster
deployment tools), improving unit / dtests tests and writing docs.
But outright blocking folks from committing a feature they may have
been working on for months makes me very uncomfortable.  I don't think
there's going to be much of this, but it seems a little authoritarian
to me to mandate that it's not allowed.

My personal preference is that everyone commit to making 4.0 stable on
day 1, and we work towards that goal as a community, but not in a
manner that's so heavy handed.

On Mon, Jul 9, 2018 at 11:06 AM sankalp kohli  wrote:
>
> If some committers want to bring in features without a path forward for
> releasing(as tests are broken), is that an acceptable state for you? How do
> we get out of this state.
>
> Like I said in my original email, this is a "proposal" and I am trying to
> see how we can improve things here. So if you are -1 on this, please help
> us propose something else to get these tests pass?
>
> And thanks for giving your feedback.
>
> On Mon, Jul 9, 2018 at 10:50 AM Jonathan Haddad  wrote:
>
> > Not everyone wants to work and collaborate the way you do.  It seems
> > absurd to me to force everyone to hold off on merging into a single
> > branch just because a lot of us want to prioritize testing 4.0.
> >
> > I think most committers are going to want to contribute to the 4.0
> > testing process more than they want to commit new features to trunk,
> > but I also think people shouldn't be banned from new bringing in new
> > features if that's what they want to do.
> >
> > You're essentially giving a blanket -1 to all new features for a 3-6
> > month period.
> > On Mon, Jul 9, 2018 at 10:44 AM sankalp kohli 
> > wrote:
> > >
> > > How is this preventing someone from working and collaborating on an
> > Apache
> > > Project? You can still collaborate on making 4.0 more stable.
> > >
> > > Why will these committers not work on making 4.0 more stable and fix
> > broken
> > > tests? Considering  we cannot release without test passing, how will
> > these
> > > features be used?
> > >
> > > On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad 
> > wrote:
> > >
> > > > I don't see how changing the process and banning feature commits is
> > > > going to be any help to the project. There may be a couple committers
> > > > who are interested in committing new features.
> > > >
> > > > I'm a -1 on changing the branching strategy in a way that prevents
> > > > people from working and collaborating on an Apache project.
> > > >
> > > > On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli 
> > > > wrote:
> > > > >
> > > > > I did not see a -1 but all +0s and a few +1s.
> > > > >
> > > > > On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie 
> > > > wrote:
> > > > >
> > > > > > What did we land on? Sounds like we're pretty split without
> > consensus
> > > > on
> > > > > > "change the old branching strategy and reject new things on trunk
> > > > during
> > > > > > stabilization" vs. "keep doing things the way we did but message
> > > > strongly
> > > > > > that we won't be reviewing new things until 4.0 is stable".
> > > > > >
> > > > > > On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli <
> > kohlisank...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Does anyone has any more feedback on this?
> > > > > > >
> > > > > > > > On Jul 4, 2018, at 05:36, Aleksey Yeshchenko <
> > alek...@apple.com>
> > > > > > 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 (
> > kohlisank...@gmail.com)
> > > > > > > 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 <
> > jmcken...@apache.org
> > > > >
> > > > > > > wrote:
> > > > 

Re: Testing 4.0 Post-Freeze

[sankalp kohli]

If some committers want to bring in features without a path forward for
releasing(as tests are broken), is that an acceptable state for you? How do
we get out of this state.

Like I said in my original email, this is a "proposal" and I am trying to
see how we can improve things here. So if you are -1 on this, please help
us propose something else to get these tests pass?

And thanks for giving your feedback.

On Mon, Jul 9, 2018 at 10:50 AM Jonathan Haddad  wrote:

> Not everyone wants to work and collaborate the way you do.  It seems
> absurd to me to force everyone to hold off on merging into a single
> branch just because a lot of us want to prioritize testing 4.0.
>
> I think most committers are going to want to contribute to the 4.0
> testing process more than they want to commit new features to trunk,
> but I also think people shouldn't be banned from new bringing in new
> features if that's what they want to do.
>
> You're essentially giving a blanket -1 to all new features for a 3-6
> month period.
> On Mon, Jul 9, 2018 at 10:44 AM sankalp kohli 
> wrote:
> >
> > How is this preventing someone from working and collaborating on an
> Apache
> > Project? You can still collaborate on making 4.0 more stable.
> >
> > Why will these committers not work on making 4.0 more stable and fix
> broken
> > tests? Considering  we cannot release without test passing, how will
> these
> > features be used?
> >
> > On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad 
> wrote:
> >
> > > I don't see how changing the process and banning feature commits is
> > > going to be any help to the project. There may be a couple committers
> > > who are interested in committing new features.
> > >
> > > I'm a -1 on changing the branching strategy in a way that prevents
> > > people from working and collaborating on an Apache project.
> > >
> > > On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli 
> > > wrote:
> > > >
> > > > I did not see a -1 but all +0s and a few +1s.
> > > >
> > > > On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie 
> > > wrote:
> > > >
> > > > > What did we land on? Sounds like we're pretty split without
> consensus
> > > on
> > > > > "change the old branching strategy and reject new things on trunk
> > > during
> > > > > stabilization" vs. "keep doing things the way we did but message
> > > strongly
> > > > > that we won't be reviewing new things until 4.0 is stable".
> > > > >
> > > > > On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli <
> kohlisank...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Does anyone has any more feedback on this?
> > > > > >
> > > > > > > On Jul 4, 2018, at 05:36, Aleksey Yeshchenko <
> alek...@apple.com>
> > > > > 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 (
> kohlisank...@gmail.com)
> > > > > > 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 <
> jmcken...@apache.org
> > > >
> > > > > > 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 <
> > > alek...@apple.com>
> > > > > > >> 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

Re: Testing 4.0 Post-Freeze

[Jonathan Haddad]

Not everyone wants to work and collaborate the way you do.  It seems
absurd to me to force everyone to hold off on merging into a single
branch just because a lot of us want to prioritize testing 4.0.

I think most committers are going to want to contribute to the 4.0
testing process more than they want to commit new features to trunk,
but I also think people shouldn't be banned from new bringing in new
features if that's what they want to do.

You're essentially giving a blanket -1 to all new features for a 3-6
month period.
On Mon, Jul 9, 2018 at 10:44 AM sankalp kohli  wrote:
>
> How is this preventing someone from working and collaborating on an Apache
> Project? You can still collaborate on making 4.0 more stable.
>
> Why will these committers not work on making 4.0 more stable and fix broken
> tests? Considering  we cannot release without test passing, how will these
> features be used?
>
> On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad  wrote:
>
> > I don't see how changing the process and banning feature commits is
> > going to be any help to the project. There may be a couple committers
> > who are interested in committing new features.
> >
> > I'm a -1 on changing the branching strategy in a way that prevents
> > people from working and collaborating on an Apache project.
> >
> > On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli 
> > wrote:
> > >
> > > I did not see a -1 but all +0s and a few +1s.
> > >
> > > On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie 
> > wrote:
> > >
> > > > What did we land on? Sounds like we're pretty split without consensus
> > on
> > > > "change the old branching strategy and reject new things on trunk
> > during
> > > > stabilization" vs. "keep doing things the way we did but message
> > strongly
> > > > that we won't be reviewing new things until 4.0 is stable".
> > > >
> > > > On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli 
> > > > wrote:
> > > >
> > > > > Does anyone has any more feedback on this?
> > > > >
> > > > > > On Jul 4, 2018, at 05:36, Aleksey Yeshchenko 
> > > > 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 (kohlisank...@gmail.com)
> > > > > 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  > >
> > > > > 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 <
> > alek...@apple.com>
> > > > > >> 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 (jji...@gmail.com) wrote:
> > > > > >>>
> > > > > >>> I think there's value in the psychological commit

Re: Testing 4.0 Post-Freeze

[sankalp kohli]

How is this preventing someone from working and collaborating on an Apache
Project? You can still collaborate on making 4.0 more stable.

Why will these committers not work on making 4.0 more stable and fix broken
tests? Considering  we cannot release without test passing, how will these
features be used?

On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad  wrote:

> I don't see how changing the process and banning feature commits is
> going to be any help to the project. There may be a couple committers
> who are interested in committing new features.
>
> I'm a -1 on changing the branching strategy in a way that prevents
> people from working and collaborating on an Apache project.
>
> On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli 
> wrote:
> >
> > I did not see a -1 but all +0s and a few +1s.
> >
> > On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie 
> wrote:
> >
> > > What did we land on? Sounds like we're pretty split without consensus
> on
> > > "change the old branching strategy and reject new things on trunk
> during
> > > stabilization" vs. "keep doing things the way we did but message
> strongly
> > > that we won't be reviewing new things until 4.0 is stable".
> > >
> > > On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli 
> > > wrote:
> > >
> > > > Does anyone has any more feedback on this?
> > > >
> > > > > On Jul 4, 2018, at 05:36, Aleksey Yeshchenko 
> > > 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 (kohlisank...@gmail.com)
> > > > 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  >
> > > > 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 <
> alek...@apple.com>
> > > > >> 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 (jji...@gmail.com) 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 <
> j...@jonhaddad.com>
> > > > >>> 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
> 

Re: Testing 4.0 Post-Freeze

[Jonathan Haddad]

I don't see how changing the process and banning feature commits is
going to be any help to the project. There may be a couple committers
who are interested in committing new features.

I'm a -1 on changing the branching strategy in a way that prevents
people from working and collaborating on an Apache project.

On Mon, Jul 9, 2018 at 9:56 AM sankalp kohli  wrote:
>
> I did not see a -1 but all +0s and a few +1s.
>
> On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie  wrote:
>
> > What did we land on? Sounds like we're pretty split without consensus on
> > "change the old branching strategy and reject new things on trunk during
> > stabilization" vs. "keep doing things the way we did but message strongly
> > that we won't be reviewing new things until 4.0 is stable".
> >
> > On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli 
> > wrote:
> >
> > > Does anyone has any more feedback on this?
> > >
> > > > On Jul 4, 2018, at 05:36, Aleksey Yeshchenko 
> > 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 (kohlisank...@gmail.com)
> > > 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 
> > > 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 
> > > >> 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 (jji...@gmail.com) 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 
> > > >>> 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=
> > >
> > > >>>
> 

Re: Testing 4.0 Post-Freeze

[sankalp kohli]

I did not see a -1 but all +0s and a few +1s.

On Mon, Jul 9, 2018 at 5:49 AM Josh McKenzie  wrote:

> What did we land on? Sounds like we're pretty split without consensus on
> "change the old branching strategy and reject new things on trunk during
> stabilization" vs. "keep doing things the way we did but message strongly
> that we won't be reviewing new things until 4.0 is stable".
>
> On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli 
> wrote:
>
> > Does anyone has any more feedback on this?
> >
> > > On Jul 4, 2018, at 05:36, Aleksey Yeshchenko 
> 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 (kohlisank...@gmail.com)
> > 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 
> > 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 
> > >> 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 (jji...@gmail.com) 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 
> > >>> 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  >
> >
> >  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 ko

Re: Testing 4.0 Post-Freeze

[Josh McKenzie]

What did we land on? Sounds like we're pretty split without consensus on
"change the old branching strategy and reject new things on trunk during
stabilization" vs. "keep doing things the way we did but message strongly
that we won't be reviewing new things until 4.0 is stable".

On Sat, Jul 7, 2018 at 5:01 PM Sankalp Kohli  wrote:

> Does anyone has any more feedback on this?
>
> > On Jul 4, 2018, at 05:36, Aleksey Yeshchenko  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 (kohlisank...@gmail.com)
> 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 
> 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 
> >> 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 (jji...@gmail.com) 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 
> >>> 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 
>
>  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 
> >>>
> >>>
> > 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

Re: Testing 4.0 Post-Freeze

[Sankalp Kohli]

Does anyone has any more feedback on this? 

> On Jul 4, 2018, at 05:36, Aleksey Yeshchenko  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 (kohlisank...@gmail.com) 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  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   
>> 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 (jji...@gmail.com) 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   
>>> 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   
 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 >> 
>>> 
> 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 S

Re: Testing 4.0 Post-Freeze

[Aleksey Yeshchenko]

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 (kohlisank...@gmail.com) 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  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   
> 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 (jji...@gmail.com) 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   
> > 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   
> > > 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  >  
> >  
> > > > 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 

Re: Testing 4.0 Post-Freeze

[kurt greaves]

Correct.

On Wed., 4 Jul. 2018, 15:21 sankalp kohli,  wrote:

> Hi Kurt,
>Thank you for your feedback. I am reading your comment as +1 on
> the idea of working on making a solid release but +0 on branching model. Is
> that correct?
> Thanks,
> Sankalp
>
> On Tue, Jul 3, 2018 at 10:09 PM kurt greaves  wrote:
>
> > >
> > > but by committing to reserving trunk for stabilizing changes until the
> > > beta, we focus our effort on polishing and delivering the release.
> >
> > No, committing to testing, bug fixing, and validating focuses our effort
> on
> > polishing and delivering the release.
> > Committing to reserving trunk for stabilising changes doesn't actually do
> > anything. We could reserve trunk and no one could ever commit a single
> > patch to it, or we could reserve trunk and everyone continues working on
> > features. Whatever we do to trunk doesn't have any impact on how our
> > attention is directed.
> >
> > Granted, you could argue that there is some great beneficial
> psychological
> > aspect and having no feature branch will make everyone suddenly start
> > working on bug fixes, but to people this actually affects (committers),
> > it's not going to mean much to them. They are either already going to be
> > motivated and tasked with getting 4.0 out the door, or they are going to
> do
> > their own thing.
> >
> > I'm fairly positive that better communication around the release, and
> > progress towards the release would be a better motivator. And it would go
> > further to getting new contributors (who definitely don't care about the
> > branches) involved, because anyone on the ML could see progress getting
> > made and be a part of any call to arms.
> >
> > But at the end of the day, bikeshedding about this is not important. This
> > is one of those issues which someone should just stand up and say "We're
> > doing it this way because I said so", because either way, it really
> doesn't
> > matter and the impact is going to be minimal, so we may as well get on
> with
> > our lives.
> >
> > On 4 July 2018 at 04:06, Scott Andreas  wrote:
> >
> > > Here’s why I really like this proposal:
> > >
> > > – It focuses our thought and effort on what it’ll take for each of us
> to
> > > become confident in running Apache Cassandra 4.0 for our most critical
> > > applications *prior* to cutting the dot-zero release.
> > > – It marks a commitment we can make to our user community: delivering
> > > 4.0’s featureset with safety and stability is our top priority.
> > > – There are many different perspectives each contributor can bring:
> > > correctness, performance, durability, automation, documentation,
> > > operational safety, etc; and many ways to gain confidence in each –
> perf
> > > tests, profiling, shadow writes/traffic mirroring, diff tests, replay
> > > tests, fuzz tests, fault injection, chaos engineering, and so many
> > others.
> > > By bringing diverse methods to bear on the same class of problem
> > (quality),
> > > we’re more likely to identify issues that could impact our users and to
> > > ship a better release.
> > > – It’s disciplined and courageous!
> > >
> > > Here’s why I think this won’t discourage new contributors from joining
> –
> > > in fact, the opposite:
> > >
> > > – It provides a very simple step that any contributor can take toward
> > > shipping 4.0: running it.
> > > – We raise spirits by delivering enhancements the community has been
> > > working on for two years rather than fracturing our attention.
> > > – If members of the community are interested in post-4.0 work, they’re
> > not
> > > blocked from making progress toward that – but it’s not the focus, and
> > > unlikely that review bandwidth would be available given that focus. I
> > agree
> > > with Kurt’s note that nobody can be “forced" to do anything - but by
> > > committing to reserving trunk for stabilizing changes until the beta,
> we
> > > focus our effort on polishing and delivering the release.
> > >
> > > On the last question:
> > > > On another note, we are still planning on accepting/reviewing bug
> fixes
> > > for previous versions as well correct?
> > >
> > > I’d expect so – and to take it a step further, it’s likely that this
> > rigor
> > > will result in us identifying serious issues that were not regressions
> in
> > > 4.0 warranting backports. As with any investment in testing /
> validation,
> > > I’m hoping we do … but also hoping we don’t. :-)
> > >
> > >
> > > > On Jul 3, 2018, at 7:21 PM, kurt greaves 
> wrote:
> > > >
> > > > tl;dr: +1 for committing to testing + bugfixing after feature freeze,
> > > but I
> > > > can't really see how changing the branching strategy is going to have
> > any
> > > > impact at all.
> > > >
> > > > I really don't think it's a big deal. People will work based on
> > whatever
> > > > priorities they've been assigned, regardless of what you do to the
> > > > branching. That's essentially just red tape and adding unnecessary
> > > > complexity to an a

Re: Testing 4.0 Post-Freeze

[sankalp kohli]

Hi Kurt,
   Thank you for your feedback. I am reading your comment as +1 on
the idea of working on making a solid release but +0 on branching model. Is
that correct?
Thanks,
Sankalp

On Tue, Jul 3, 2018 at 10:09 PM kurt greaves  wrote:

> >
> > but by committing to reserving trunk for stabilizing changes until the
> > beta, we focus our effort on polishing and delivering the release.
>
> No, committing to testing, bug fixing, and validating focuses our effort on
> polishing and delivering the release.
> Committing to reserving trunk for stabilising changes doesn't actually do
> anything. We could reserve trunk and no one could ever commit a single
> patch to it, or we could reserve trunk and everyone continues working on
> features. Whatever we do to trunk doesn't have any impact on how our
> attention is directed.
>
> Granted, you could argue that there is some great beneficial psychological
> aspect and having no feature branch will make everyone suddenly start
> working on bug fixes, but to people this actually affects (committers),
> it's not going to mean much to them. They are either already going to be
> motivated and tasked with getting 4.0 out the door, or they are going to do
> their own thing.
>
> I'm fairly positive that better communication around the release, and
> progress towards the release would be a better motivator. And it would go
> further to getting new contributors (who definitely don't care about the
> branches) involved, because anyone on the ML could see progress getting
> made and be a part of any call to arms.
>
> But at the end of the day, bikeshedding about this is not important. This
> is one of those issues which someone should just stand up and say "We're
> doing it this way because I said so", because either way, it really doesn't
> matter and the impact is going to be minimal, so we may as well get on with
> our lives.
>
> On 4 July 2018 at 04:06, Scott Andreas  wrote:
>
> > Here’s why I really like this proposal:
> >
> > – It focuses our thought and effort on what it’ll take for each of us to
> > become confident in running Apache Cassandra 4.0 for our most critical
> > applications *prior* to cutting the dot-zero release.
> > – It marks a commitment we can make to our user community: delivering
> > 4.0’s featureset with safety and stability is our top priority.
> > – There are many different perspectives each contributor can bring:
> > correctness, performance, durability, automation, documentation,
> > operational safety, etc; and many ways to gain confidence in each – perf
> > tests, profiling, shadow writes/traffic mirroring, diff tests, replay
> > tests, fuzz tests, fault injection, chaos engineering, and so many
> others.
> > By bringing diverse methods to bear on the same class of problem
> (quality),
> > we’re more likely to identify issues that could impact our users and to
> > ship a better release.
> > – It’s disciplined and courageous!
> >
> > Here’s why I think this won’t discourage new contributors from joining –
> > in fact, the opposite:
> >
> > – It provides a very simple step that any contributor can take toward
> > shipping 4.0: running it.
> > – We raise spirits by delivering enhancements the community has been
> > working on for two years rather than fracturing our attention.
> > – If members of the community are interested in post-4.0 work, they’re
> not
> > blocked from making progress toward that – but it’s not the focus, and
> > unlikely that review bandwidth would be available given that focus. I
> agree
> > with Kurt’s note that nobody can be “forced" to do anything - but by
> > committing to reserving trunk for stabilizing changes until the beta, we
> > focus our effort on polishing and delivering the release.
> >
> > On the last question:
> > > On another note, we are still planning on accepting/reviewing bug fixes
> > for previous versions as well correct?
> >
> > I’d expect so – and to take it a step further, it’s likely that this
> rigor
> > will result in us identifying serious issues that were not regressions in
> > 4.0 warranting backports. As with any investment in testing / validation,
> > I’m hoping we do … but also hoping we don’t. :-)
> >
> >
> > > On Jul 3, 2018, at 7:21 PM, kurt greaves  wrote:
> > >
> > > tl;dr: +1 for committing to testing + bugfixing after feature freeze,
> > but I
> > > can't really see how changing the branching strategy is going to have
> any
> > > impact at all.
> > >
> > > I really don't think it's a big deal. People will work based on
> whatever
> > > priorities they've been assigned, regardless of what you do to the
> > > branching. That's essentially just red tape and adding unnecessary
> > > complexity to an already established process. Granted, you'll have to
> do
> > > one less merge, but it should be an effortless merge, and it saves
> there
> > > being any confusion about what people should do with features. If
> someone
> > > decided to commit a feature, they could, and we wouldn't have 

Re: Testing 4.0 Post-Freeze

[kurt greaves]

>
> but by committing to reserving trunk for stabilizing changes until the
> beta, we focus our effort on polishing and delivering the release.

No, committing to testing, bug fixing, and validating focuses our effort on
polishing and delivering the release.
Committing to reserving trunk for stabilising changes doesn't actually do
anything. We could reserve trunk and no one could ever commit a single
patch to it, or we could reserve trunk and everyone continues working on
features. Whatever we do to trunk doesn't have any impact on how our
attention is directed.

Granted, you could argue that there is some great beneficial psychological
aspect and having no feature branch will make everyone suddenly start
working on bug fixes, but to people this actually affects (committers),
it's not going to mean much to them. They are either already going to be
motivated and tasked with getting 4.0 out the door, or they are going to do
their own thing.

I'm fairly positive that better communication around the release, and
progress towards the release would be a better motivator. And it would go
further to getting new contributors (who definitely don't care about the
branches) involved, because anyone on the ML could see progress getting
made and be a part of any call to arms.

But at the end of the day, bikeshedding about this is not important. This
is one of those issues which someone should just stand up and say "We're
doing it this way because I said so", because either way, it really doesn't
matter and the impact is going to be minimal, so we may as well get on with
our lives.

On 4 July 2018 at 04:06, Scott Andreas  wrote:

> Here’s why I really like this proposal:
>
> – It focuses our thought and effort on what it’ll take for each of us to
> become confident in running Apache Cassandra 4.0 for our most critical
> applications *prior* to cutting the dot-zero release.
> – It marks a commitment we can make to our user community: delivering
> 4.0’s featureset with safety and stability is our top priority.
> – There are many different perspectives each contributor can bring:
> correctness, performance, durability, automation, documentation,
> operational safety, etc; and many ways to gain confidence in each – perf
> tests, profiling, shadow writes/traffic mirroring, diff tests, replay
> tests, fuzz tests, fault injection, chaos engineering, and so many others.
> By bringing diverse methods to bear on the same class of problem (quality),
> we’re more likely to identify issues that could impact our users and to
> ship a better release.
> – It’s disciplined and courageous!
>
> Here’s why I think this won’t discourage new contributors from joining –
> in fact, the opposite:
>
> – It provides a very simple step that any contributor can take toward
> shipping 4.0: running it.
> – We raise spirits by delivering enhancements the community has been
> working on for two years rather than fracturing our attention.
> – If members of the community are interested in post-4.0 work, they’re not
> blocked from making progress toward that – but it’s not the focus, and
> unlikely that review bandwidth would be available given that focus. I agree
> with Kurt’s note that nobody can be “forced" to do anything - but by
> committing to reserving trunk for stabilizing changes until the beta, we
> focus our effort on polishing and delivering the release.
>
> On the last question:
> > On another note, we are still planning on accepting/reviewing bug fixes
> for previous versions as well correct?
>
> I’d expect so – and to take it a step further, it’s likely that this rigor
> will result in us identifying serious issues that were not regressions in
> 4.0 warranting backports. As with any investment in testing / validation,
> I’m hoping we do … but also hoping we don’t. :-)
>
>
> > On Jul 3, 2018, at 7:21 PM, kurt greaves  wrote:
> >
> > tl;dr: +1 for committing to testing + bugfixing after feature freeze,
> but I
> > can't really see how changing the branching strategy is going to have any
> > impact at all.
> >
> > I really don't think it's a big deal. People will work based on whatever
> > priorities they've been assigned, regardless of what you do to the
> > branching. That's essentially just red tape and adding unnecessary
> > complexity to an already established process. Granted, you'll have to do
> > one less merge, but it should be an effortless merge, and it saves there
> > being any confusion about what people should do with features. If someone
> > decided to commit a feature, they could, and we wouldn't have to be all
> > over every ticket making sure people don't commit things that shouldn't
> be
> > committed.
> >
> > Cutting to the point, all we're really aiming for here is a commitment
> from
> > the community to only dev on bugfixes, only review bugfixes, and
> > testing/validation during the freeze period. That's not going to be
> > enforced by a change in branching strategy, it's going to be enforced by
> > the contributors them

Re: Testing 4.0 Post-Freeze

[Scott Andreas]

Here’s why I really like this proposal:

– It focuses our thought and effort on what it’ll take for each of us to become 
confident in running Apache Cassandra 4.0 for our most critical applications 
*prior* to cutting the dot-zero release.
– It marks a commitment we can make to our user community: delivering 4.0’s 
featureset with safety and stability is our top priority.
– There are many different perspectives each contributor can bring: 
correctness, performance, durability, automation, documentation, operational 
safety, etc; and many ways to gain confidence in each – perf tests, profiling, 
shadow writes/traffic mirroring, diff tests, replay tests, fuzz tests, fault 
injection, chaos engineering, and so many others. By bringing diverse methods 
to bear on the same class of problem (quality), we’re more likely to identify 
issues that could impact our users and to ship a better release.
– It’s disciplined and courageous!

Here’s why I think this won’t discourage new contributors from joining – in 
fact, the opposite:

– It provides a very simple step that any contributor can take toward shipping 
4.0: running it.
– We raise spirits by delivering enhancements the community has been working on 
for two years rather than fracturing our attention.
– If members of the community are interested in post-4.0 work, they’re not 
blocked from making progress toward that – but it’s not the focus, and unlikely 
that review bandwidth would be available given that focus. I agree with Kurt’s 
note that nobody can be “forced" to do anything - but by committing to 
reserving trunk for stabilizing changes until the beta, we focus our effort on 
polishing and delivering the release.

On the last question:
> On another note, we are still planning on accepting/reviewing bug fixes for 
> previous versions as well correct?

I’d expect so – and to take it a step further, it’s likely that this rigor will 
result in us identifying serious issues that were not regressions in 4.0 
warranting backports. As with any investment in testing / validation, I’m 
hoping we do … but also hoping we don’t. :-)


> On Jul 3, 2018, at 7:21 PM, kurt greaves  wrote:
> 
> tl;dr: +1 for committing to testing + bugfixing after feature freeze, but I
> can't really see how changing the branching strategy is going to have any
> impact at all.
> 
> I really don't think it's a big deal. People will work based on whatever
> priorities they've been assigned, regardless of what you do to the
> branching. That's essentially just red tape and adding unnecessary
> complexity to an already established process. Granted, you'll have to do
> one less merge, but it should be an effortless merge, and it saves there
> being any confusion about what people should do with features. If someone
> decided to commit a feature, they could, and we wouldn't have to be all
> over every ticket making sure people don't commit things that shouldn't be
> committed.
> 
> Cutting to the point, all we're really aiming for here is a commitment from
> the community to only dev on bugfixes, only review bugfixes, and
> testing/validation during the freeze period. That's not going to be
> enforced by a change in branching strategy, it's going to be enforced by
> the contributors themselves (and their respective priority-setters).
> The best we can do is encourage a commitment to testing and bugfixing for
> the freeze period. This is a volunteer based project after all, so we can't
> really force anyone to do anything. If contributors make proposals for
> features in the freeze period we can just tell them that there is a focus
> on 4.0 testing and it's unlikely to be reviewed until 4.0 is released at
> best.
> 
> On another note, we are still planning on accepting/reviewing bug fixes for
> previous versions as well correct?  Just to clarify because it doesn't seem
> to be mentioned here and we don't want people getting in arguments over
> reviewing patches that only affect older releases.
> 
> I think not having your patch reviewed for months is more
>> discouraging than following the community and helping with stability of
>> 4.0.
> 
> Patches not getting reviewed for months on end already occurs. Changing how
> we branch isn't going to change this or make anyone feel better about it.
> The best we can do is communicate why their patches aren't getting
> reviewed, and we should be doing this on individual feature tickets that
> get raised and on the ML.
> 
> On 4 July 2018 at 00:44, Mick Semb Wever  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.
>>> 
>> 
>> 
>> +1, like really yes!! because it's a step towards a more stable-master
>> project.
>> 
>> If trunk is focused on stabilising (which ideally it shouldn't have to, if
>> stable-master were true) then new features remaining in their respective
>> branches shouldn't be a big co

Re: Testing 4.0 Post-Freeze

[kurt greaves]

tl;dr: +1 for committing to testing + bugfixing after feature freeze, but I
can't really see how changing the branching strategy is going to have any
impact at all.

I really don't think it's a big deal. People will work based on whatever
priorities they've been assigned, regardless of what you do to the
branching. That's essentially just red tape and adding unnecessary
complexity to an already established process. Granted, you'll have to do
one less merge, but it should be an effortless merge, and it saves there
being any confusion about what people should do with features. If someone
decided to commit a feature, they could, and we wouldn't have to be all
over every ticket making sure people don't commit things that shouldn't be
committed.

Cutting to the point, all we're really aiming for here is a commitment from
the community to only dev on bugfixes, only review bugfixes, and
testing/validation during the freeze period. That's not going to be
enforced by a change in branching strategy, it's going to be enforced by
the contributors themselves (and their respective priority-setters).
The best we can do is encourage a commitment to testing and bugfixing for
the freeze period. This is a volunteer based project after all, so we can't
really force anyone to do anything. If contributors make proposals for
features in the freeze period we can just tell them that there is a focus
on 4.0 testing and it's unlikely to be reviewed until 4.0 is released at
best.

On another note, we are still planning on accepting/reviewing bug fixes for
previous versions as well correct?  Just to clarify because it doesn't seem
to be mentioned here and we don't want people getting in arguments over
reviewing patches that only affect older releases.

I think not having your patch reviewed for months is more
> discouraging than following the community and helping with stability of
> 4.0.

Patches not getting reviewed for months on end already occurs. Changing how
we branch isn't going to change this or make anyone feel better about it.
The best we can do is communicate why their patches aren't getting
reviewed, and we should be doing this on individual feature tickets that
get raised and on the ML.

On 4 July 2018 at 00:44, Mick Semb Wever  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.
> >
>
>
> +1, like really yes!! because it's a step towards a more stable-master
> project.
>
> If trunk is focused on stabilising (which ideally it shouldn't have to, if
> stable-master were true) then new features remaining in their respective
> branches shouldn't be a big cost or risk (nor seen as anything negative).
> And hopefully any additional practices/lessons learnt from during the
> freeze period get carried on for good.
>
> Although, and unfortunately, there's just not the testing infrastructure
> available to the public to ensure feature branches are solid before
> merging. But I struggle to see that as an excuse to only "stabilise" on
> release branches.
>
> 2¢,
> mick
>

Re: Testing 4.0 Post-Freeze

[Mick Semb Wever]

>
>
> 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.
>


+1, like really yes!! because it's a step towards a more stable-master
project.

If trunk is focused on stabilising (which ideally it shouldn't have to, if
stable-master were true) then new features remaining in their respective
branches shouldn't be a big cost or risk (nor seen as anything negative).
And hopefully any additional practices/lessons learnt from during the
freeze period get carried on for good.

Although, and unfortunately, there's just not the testing infrastructure
available to the public to ensure feature branches are solid before
merging. But I struggle to see that as an excuse to only "stabilise" on
release branches.

2¢,
mick

Re: Testing 4.0 Post-Freeze

[Jeff Jirsa]

Yes?

-- 
Jeff Jirsa


> On Jul 3, 2018, at 2:29 PM, Jonathan Ellis  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  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  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 
>>> 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 
 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Testing 4.0 Post-Freeze

[sankalp kohli]

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  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 
> 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 (jji...@gmail.com) 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 
> > 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 
> > > 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  >
> >
> > > > 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.
> > > > >
> > > > 

Re: Testing 4.0 Post-Freeze

[Josh McKenzie]

>
> 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  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 (jji...@gmail.com) 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 
> 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 
> > 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 
>
> > > 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 r

Re: Testing 4.0 Post-Freeze

[Roopa Tangirala]

At Netflix, we use NDBench  extensively
to ensure there are no performance regressions introduced between major
releases since all our micro services are very sensitive to any latency
changes. I see a value in community organizing efforts around the
production readiness and stability of a release which builds confidence in
using the particular release in production. Once 4.0 is freezed, we will
run it through our build pipeline which not only validates the performance
but also regular maintenances like repair, compactions, node terminations,
replacements, streaming and share the results.


*Regards,*

*Roopa Tangirala*

Engineering Manager CDE

*(408) 438-3156 - mobile*






On Tue, Jul 3, 2018 at 2:32 PM dinesh.jo...@yahoo.com.INVALID
 wrote:

> I think the call to action for the community here is to focus efforts on
> testing and bug fixes than spending time on reviewing features. That said,
> tlp-stress looks interesting.
> Dinesh
>
> On Tuesday, July 3, 2018, 1:03:54 PM PDT, Jonathan Haddad <
> j...@jonhaddad.com> 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 
> 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 
> > 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

Re: Testing 4.0 Post-Freeze

[Aleksey Yeshchenko]

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 (jji...@gmail.com) 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  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   
> 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   
> > 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  
>  

Re: Testing 4.0 Post-Freeze

[dinesh.jo...@yahoo.com.INVALID]

I think the call to action for the community here is to focus efforts on 
testing and bug fixes than spending time on reviewing features. That said, 
tlp-stress looks interesting.
Dinesh 

On Tuesday, July 3, 2018, 1:03:54 PM PDT, Jonathan Haddad 
 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  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 
> 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  

Re: Testing 4.0 Post-Freeze

[Jonathan Ellis]

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  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  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 
> > 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 
> > > 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

Re: Testing 4.0 Post-Freeze

[Jeff Jirsa]

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  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 
> 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 
> > 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
>

Re: Testing 4.0 Post-Freeze

[Jonathan Haddad]

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  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 
> 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

Re: Testing 4.0 Post-Freeze

[Josh McKenzie]

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  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

Testing 4.0 Post-Freeze

[sankalp kohli]

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