[DISCUSS] Next release cut

[Benjamin Lerer]

Hi everybody,

We discussed cutting the next release in May but did not provide more
clarity about it.
The cassandra-4.0 branch was created on the 1st of May last year. So it
would make sense to do something similar this year. Does it sound
reasonable?
Should we plan some soft freeze before that?
Do we want to start with an alpha or beta release?

It feels like it would be a good time to answer those questions as we are
slowly approaching the target month and we need to align our expectations.

Re: [DISCUSS] Next release cut

[Paulo Motta]

Thanks for bringing this topic for discussion Benjamin.

> The cassandra-4.0 branch was created on the 1st of May last year. So it
would make sense to do something similar this year. Does it sound
reasonable?

+1 to having a predictable release date and May 1st sounds good to me.

> Should we plan some soft freeze before that?

Doesn't the freeze start when we cut the branch? I have some in progress
work that I was hoping to wrap up by May 1st.

>  Do we want to start with an alpha or beta release?

I don't see why not. Can we do that after the branch is cut on May 1st or
were you thinking before that?

Em ter., 8 de mar. de 2022 às 10:29, Benjamin Lerer 
escreveu:

> Hi everybody,
>
> We discussed cutting the next release in May but did not provide more
> clarity about it.
> The cassandra-4.0 branch was created on the 1st of May last year. So it
> would make sense to do something similar this year. Does it sound
> reasonable?
> Should we plan some soft freeze before that?
> Do we want to start with an alpha or beta release?
>
> It feels like it would be a good time to answer those questions as we are
> slowly approaching the target month and we need to align our expectations.
>
>
>

Re: [DISCUSS] Next release cut

[Josh McKenzie]

Cut branch and freeze May 1st
Goal to GA July 1st

We talking something like that ^ w/8 weeks to stabilize, clean up straggler 
tests, and maybe do some fuzzing and property based testing against it?

On Tue, Mar 8, 2022, at 8:36 AM, Paulo Motta wrote:
> Thanks for bringing this topic for discussion Benjamin.
> 
> > The cassandra-4.0 branch was created on the 1st of May last year. So it 
> > would make sense to do something similar this year. Does it sound 
> > reasonable?
> +1 to having a predictable release date and May 1st sounds good to me.
> 
> > Should we plan some soft freeze before that?
> Doesn't the freeze start when we cut the branch? I have some in progress work 
> that I was hoping to wrap up by May 1st.
> 
> >  Do we want to start with an alpha or beta release?
> 
> I don't see why not. Can we do that after the branch is cut on May 1st or 
> were you thinking before that?
> 
> Em ter., 8 de mar. de 2022 às 10:29, Benjamin Lerer  
> escreveu:
>> Hi everybody,
>> 
>> We discussed cutting the next release in May but did not provide more 
>> clarity about it.
>> The cassandra-4.0 branch was created on the 1st of May last year. So it 
>> would make sense to do something similar this year. Does it sound reasonable?
>> 
>> Should we plan some soft freeze before that?
>> Do we want to start with an alpha or beta release?
>> 
>> It feels like it would be a good time to answer those questions as we are 
>> slowly approaching the target month and we need to align our expectations. 
>> 
>> 

Re: [DISCUSS] Next release cut

[Mick Semb Wever]

>
>
> Should we plan some soft freeze before that?
>


Good question! :-)

We do not want to encourage/enable the rush to commit stuff before the 1st
May cut-off. IMHO we should be comfortable leaning towards saving any
significant commits for the next dev cycle. How do we create the correct
incentive?

If we don't feel that we have achieved stable trunk this dev cycle then a
soft feature freeze during April makes sense to me. IMHO a need to first
cut alpha1 instead of going straight to a beta1 is an indicator we have not
achieved stable trunk;

I'd rather not see a long testing run on the release branch before rc1. And
I think this is necessary if we want GA by July.
So for me this boils down to… are we (and will we be) comfortable making
the first cut 4.1-beta1 ?

Re: [DISCUSS] Next release cut

[bened...@apache.org]

At the very least we should wait until the current issues with CI have 
resolved, so that pending work can merge, before declaring any freeze.

From: Mick Semb Wever 
Date: Tuesday, 8 March 2022 at 15:13
To: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] Next release cut

Should we plan some soft freeze before that?


Good question! :-)

We do not want to encourage/enable the rush to commit stuff before the 1st May 
cut-off. IMHO we should be comfortable leaning towards saving any significant 
commits for the next dev cycle. How do we create the correct incentive?

If we don't feel that we have achieved stable trunk this dev cycle then a soft 
feature freeze during April makes sense to me. IMHO a need to first cut alpha1 
instead of going straight to a beta1 is an indicator we have not achieved 
stable trunk;

I'd rather not see a long testing run on the release branch before rc1. And I 
think this is necessary if we want GA by July.
So for me this boils down to… are we (and will we be) comfortable making the 
first cut 4.1-beta1 ?

Re: GSOD 2022

[Paulo Motta]

Any of the docs contributors interested in taking the lead on this? Perhaps
Dinesh could share some tips on how to create the GSoD application.

I think there is a lot of documentation that needs to be created/migrated,
would be nice to have some external help on this.

For instance, some virtual tables were added but we have no documentation
on them. Perhaps we could have a GSoD project to better document Virtual
Tables?

Em seg., 7 de mar. de 2022 às 17:54, Deepak Vohra 
escreveu:

> Has anyone applied for GSOD this year?  Organization application closes
> March 25th.
> https://developers.google.com/season-of-docs/docs/timeline
>
>
> thanks,
> Deepak
>

Re: [DISCUSS] Next release cut

[Josh McKenzie]

> We do not want to encourage/enable the rush to commit stuff before the 1st 
> May cut-off. IMHO we should be comfortable leaning towards saving any 
> significant commits for the next dev cycle.
With sufficient testing added for a new feature, feature flags for optionality, 
and a window of time to fuzz test things, why should we shy away from even 
large commits the day before we freeze if they have a green CI board?

It's up to each of us not to rush or cut corners to try and slip something in. 
The snapshot releases and yearly cadence should remove a lot of the sting from 
missing a release deadline I think.


On Tue, Mar 8, 2022, at 10:14 AM, bened...@apache.org wrote:
> At the very least we should wait until the current issues with CI have 
> resolved, so that pending work can merge, before declaring any freeze.
>  
> *From: *Mick Semb Wever 
> *Date: *Tuesday, 8 March 2022 at 15:13
> *To: *dev@cassandra.apache.org 
> *Subject: *Re: [DISCUSS] Next release cut
>>  
>> Should we plan some soft freeze before that?
>  
>  
> Good question! :-) 
>  
> We do not want to encourage/enable the rush to commit stuff before the 1st 
> May cut-off. IMHO we should be comfortable leaning towards saving any 
> significant commits for the next dev cycle. How do we create the correct 
> incentive?
>  
> If we don't feel that we have achieved stable trunk this dev cycle then a 
> soft feature freeze during April makes sense to me. IMHO a need to first cut 
> alpha1 instead of going straight to a beta1 is an indicator we have not 
> achieved stable trunk;
>  
> I'd rather not see a long testing run on the release branch before rc1. And I 
> think this is necessary if we want GA by July. 
> So for me this boils down to… are we (and will we be) comfortable making the 
> first cut 4.1-beta1 ?
>  

Re: [DISCUSS] Next release cut

[Jeremiah D Jordan]

I agree with Josh here.  If we can’t be adding things that pass review up until 
the moment we decide to cut the release it means people are not following our 
stated goals/process for suitability for merge.  If that is the case then we 
should work to fix that, not add arbitrary soft freeze windows to the release 
timeline.

-Jeremiah

> On Mar 8, 2022, at 10:46 AM, Josh McKenzie  wrote:
> 
>> We do not want to encourage/enable the rush to commit stuff before the 1st 
>> May cut-off. IMHO we should be comfortable leaning towards saving any 
>> significant commits for the next dev cycle.
> With sufficient testing added for a new feature, feature flags for 
> optionality, and a window of time to fuzz test things, why should we shy away 
> from even large commits the day before we freeze if they have a green CI 
> board?
> 
> It's up to each of us not to rush or cut corners to try and slip something 
> in. The snapshot releases and yearly cadence should remove a lot of the sting 
> from missing a release deadline I think.
> 
> 
> On Tue, Mar 8, 2022, at 10:14 AM, bened...@apache.org 
>  wrote:
>> At the very least we should wait until the current issues with CI have 
>> resolved, so that pending work can merge, before declaring any freeze.
>>  
>> From: Mick Semb Wever 
>> Date: Tuesday, 8 March 2022 at 15:13
>> To: dev@cassandra.apache.org 
>> Subject: Re: [DISCUSS] Next release cut
>> 
>>  
>> Should we plan some soft freeze before that?
>>  
>>  
>> Good question! :-) 
>>  
>> We do not want to encourage/enable the rush to commit stuff before the 1st 
>> May cut-off. IMHO we should be comfortable leaning towards saving any 
>> significant commits for the next dev cycle. How do we create the correct 
>> incentive?
>>  
>> If we don't feel that we have achieved stable trunk this dev cycle then a 
>> soft feature freeze during April makes sense to me. IMHO a need to first cut 
>> alpha1 instead of going straight to a beta1 is an indicator we have not 
>> achieved stable trunk;
>>  
>> I'd rather not see a long testing run on the release branch before rc1. And 
>> I think this is necessary if we want GA by July. 
>> So for me this boils down to… are we (and will we be) comfortable making the 
>> first cut 4.1-beta1 ?

Re: [DISCUSS] Next release cut

[Mick Semb Wever]

>
> We do not want to encourage/enable the rush to commit stuff before the 1st
> May cut-off. IMHO we should be comfortable leaning towards saving any
> significant commits for the next dev cycle.
>
> With sufficient testing added for a new feature, feature flags for
> optionality, and a window of time to fuzz test things, why should we shy
> away from even large commits the day before we freeze if they have a green
> CI board?
>


Yes, we are aligned here. If things are done properly then that's not "a
rush", and there's no reason we shouldn't be _working as normal_ up until
the 1st May. Keeping in mind that the time to do it properly can be
something out of your control: CI not working, rebasing if there's a lot
landing in trunk, etc.

We also have the requirement that there will be no release without green
CI. Do we cut a release branch on the 1st May if we don't yet have a green
CI and can't be making a cut off it?

Re: GSOD 2022

[Lorina Poland]

I'm willing to take the lead on GSoD. Let me think about what projects I think 
would benefit the docs.

Lorina

On 2022/03/08 16:03:48 Paulo Motta wrote:
> Any of the docs contributors interested in taking the lead on this? Perhaps
> Dinesh could share some tips on how to create the GSoD application.
> 
> I think there is a lot of documentation that needs to be created/migrated,
> would be nice to have some external help on this.
> 
> For instance, some virtual tables were added but we have no documentation
> on them. Perhaps we could have a GSoD project to better document Virtual
> Tables?
> 
> Em seg., 7 de mar. de 2022 às 17:54, Deepak Vohra 
> escreveu:
> 
> > Has anyone applied for GSOD this year?  Organization application closes
> > March 25th.
> > https://developers.google.com/season-of-docs/docs/timeline
> >
> >
> > thanks,
> > Deepak
> >
> 

Re: [DISCUSS] Next release cut

[Ekaterina Dimitrova]

I tend to agree with Mick. We should have a bit of time to look around and
do a final cross check. Also, our CI is really painful these days and I am
not talking only about test failures, but infra.

On Tue, 8 Mar 2022 at 13:56, Mick Semb Wever  wrote:

> We do not want to encourage/enable the rush to commit stuff before the 1st
>> May cut-off. IMHO we should be comfortable leaning towards saving any
>> significant commits for the next dev cycle.
>>
>> With sufficient testing added for a new feature, feature flags for
>> optionality, and a window of time to fuzz test things, why should we shy
>> away from even large commits the day before we freeze if they have a green
>> CI board?
>>
>
>
> Yes, we are aligned here. If things are done properly then that's not "a
> rush", and there's no reason we shouldn't be _working as normal_ up until
> the 1st May. Keeping in mind that the time to do it properly can be
> something out of your control: CI not working, rebasing if there's a lot
> landing in trunk, etc.
>
> We also have the requirement that there will be no release without green
> CI. Do we cut a release branch on the 1st May if we don't yet have a green
> CI and can't be making a cut off it?
>
>

Re: GSOD 2022

[Dinesh Joshi]

I haven't looked into GSoD this year. However, the scope of a GSoD project has 
to be sufficient for the amount of time that is allocated by GSoD. They had 2 
project lengths when we last participated - short & long. Projects need to be 
defined accordingly. It is a lot of work and I personally don't have time to 
select and mentor the technical writers. I can definitely help guide the 
application process as I think we also require someone from the PMC to actually 
submit the application. Nate helped me out when we last participated in GSoD so 
I'll be happy to help out on that front.

Here's the page we created for tracking the GSoD Participation and project 
ideas: 
https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+GSoD+2019+application

It would be a good idea to do something similar and get a sense of where our 
documentation is lacking and then proceed from there.

> On Mar 8, 2022, at 1:56 PM, Lorina Poland  wrote:
> 
> I'm willing to take the lead on GSoD. Let me think about what projects I 
> think would benefit the docs.
> 
> Lorina
> 
> On 2022/03/08 16:03:48 Paulo Motta wrote:
>> Any of the docs contributors interested in taking the lead on this? Perhaps
>> Dinesh could share some tips on how to create the GSoD application.
>> 
>> I think there is a lot of documentation that needs to be created/migrated,
>> would be nice to have some external help on this.
>> 
>> For instance, some virtual tables were added but we have no documentation
>> on them. Perhaps we could have a GSoD project to better document Virtual
>> Tables?
>> 
>> Em seg., 7 de mar. de 2022 às 17:54, Deepak Vohra 
>> escreveu:
>> 
>>> Has anyone applied for GSOD this year?  Organization application closes
>>> March 25th.
>>> https://developers.google.com/season-of-docs/docs/timeline
>>> 
>>> 
>>> thanks,
>>> Deepak
>>> 
>>