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
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
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 applicati
>
> 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
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 window
> 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
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 t
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
>
>
> 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
incent
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 discussio
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
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?
D
12 matches
Mail list logo
