Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benjamin Lerer]

>
> I am surprised this needs to be said, but - especially for long-running
> CEPs - you must involve yourself early, and certainly within some
> reasonable time of being notified the work is ready for broader input and
> review. In this case, more than six months ago.


It is unfortunately more complicated than that because six month ago
Ekaterina and I were working on supporting Java 17 and dropping Java 8
which was needed by different ongoing works. We both missed the
announcement that TCM was ready for review and anyway would not have been
available at that time. Maxim has asked me ages ago for a review of
CASSANDRA-15254 
more than 6 months ago and I have not been able to help him so far. We all
have a limited bandwidth and can miss some announcements.

The project has grown and a lot of things are going on in parallel. There
are also more interdependencies between the different projects. In my
opinion what we are lacking is a global overview of the different things
going on in the project and some rough ideas of the status of the different
significant pieces. It would allow us to better organize ourselves.

Le jeu. 26 oct. 2023 à 00:26, Benedict  a écrit :

> I have spoken privately with Ekaterina, and to clear up some possible
> ambiguity: I realise nobody has demanded a delay to this work to conduct
> additional reviews; a couple of folk have however said they would prefer
> one.
>
>
> My point is that, as a community, we need to work on ensuring folk that
> care about a CEP participate at an appropriate time. If they aren’t able
> to, the consequences of that are for them to bear.
>
>
> We should be working to avoid surprises as CEP start to land. To this end,
> I think we should work on some additional paragraphs for the governance doc
> covering expectations around the landing of CEPs.
>
> On 25 Oct 2023, at 21:55, Benedict  wrote:
>
> 
>
> I am surprised this needs to be said, but - especially for long-running
> CEPs - you must involve yourself early, and certainly within some
> reasonable time of being notified the work is ready for broader input and
> review. In this case, more than six months ago.
>
>
> This isn’t the first time this has happened, and it is disappointing to
> see it again. Clearly we need to make this explicit in the guidance docs.
>
>
> Regarding the release of 5.1, I understood the proposal to be that we cut
> an actual alpha, thereby sealing the 5.1 release from new features. Only
> features merged before we cut the alpha would be permitted, and the alpha
> should be cut as soon as practicable. What exactly would we be waiting for?
>
>
> If we don’t have a clear and near-term trigger for branching 5.1 for its
> own release, shortly after Accord and TCM merge, then I am in favour of
> instead delaying 5.0.
>
> On 25 Oct 2023, at 19:40, Mick Semb Wever  wrote:
>
> 
> I'm open to the suggestions of not branching cassandra-5.1 and/or naming a
> preview release something other than 5.1-alpha1.
>
> But… the codebases and release process (and upgrade tests) do not
> currently support releases with qualifiers that are not alpha, beta, or
> rc.  We can add a preview qualifier to this list, but I would not want to
> block getting a preview release out only because this wasn't yet in place.
>
> Hence the proposal used 5.1-alpha1 simply because that's what we know we
> can do today.  An alpha release also means (typically) the branch.
>
> Is anyone up for looking into adding a "preview" qualifier to our release
> process?
> This may also solve our previous discussions and desire to have quarterly
> releases that folk can use through the trunk dev cycle.
>
> Personally, with my understanding of timelines in front of us to fully
> review and stabilise tcm, it makes sense to branch it as soon as it's
> merged.  It's easiest to stabilise it on a branch, and there's definitely
> the desire and demand to do so, so it won't be getting forgotten or
> down-prioritised.
>
>
>
> On Wed, 25 Oct 2023 at 18:07, Jeremiah Jordan 
> wrote:
>
>> If we do a 5.1 release why not take it as an opportunity to release more
>>> things. I am not saying that we will. Just that we should let that door
>>> open.
>>>
>>
>> Agreed.  This is the reason I brought up the possibility of not branching
>> off 5.1 immediately.
>>
>>
>> On Oct 25, 2023 at 3:17:13 AM, Benjamin Lerer  wrote:
>>
>>> The proposal includes 3 things:
>>> 1. Do not include TCM and Accord in 5.0 to avoid delaying 5.0
>>> 2. The next release will be 5.1 and will include only Accord and TCM
>>> 3. Merge TCM and Accord right now in 5.1 (making an initial release)
>>>
>>> I am fine with question 1 and do not have a strong opinion on which way
>>> to go.
>>> 2. Means that every new feature will have to wait for post 5.1 even if
>>> it is ready before 5.1 is stabilized and shipped. If we do a 5.1 release
>>> why not take it as an opportunity to release more things. I am not saying
>>> that we wil

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benjamin Lerer]

>
> Regarding the release of 5.1, I understood the proposal to be that we cut
> an actual alpha, thereby sealing the 5.1 release from new features. Only
> features merged before we cut the alpha would be permitted, and the alpha
> should be cut as soon as practicable. What exactly would we be waiting for?


The problem I believe is about expectations. It seems that your expectation
is that a release with only TCM and Accord will reach GA quickly. Based on
the time it took us to release 4.1, I am simply expecting more delays (a GA
around end of May, June). In which case it seems to me that we could be
interested in shipping more stuff in the meantime (thinking of
CASSANDRA-15254 or CEP-29 for example).
I do not have a strong opinion, I just want to make sure that we all share
the same understanding and fully understand what we agree upon.

Le jeu. 26 oct. 2023 à 10:59, Benjamin Lerer  a écrit :

> I am surprised this needs to be said, but - especially for long-running
>> CEPs - you must involve yourself early, and certainly within some
>> reasonable time of being notified the work is ready for broader input and
>> review. In this case, more than six months ago.
>
>
> It is unfortunately more complicated than that because six month ago
> Ekaterina and I were working on supporting Java 17 and dropping Java 8
> which was needed by different ongoing works. We both missed the
> announcement that TCM was ready for review and anyway would not have been
> available at that time. Maxim has asked me ages ago for a review of
> CASSANDRA-15254 
> more than 6 months ago and I have not been able to help him so far. We all
> have a limited bandwidth and can miss some announcements.
>
> The project has grown and a lot of things are going on in parallel. There
> are also more interdependencies between the different projects. In my
> opinion what we are lacking is a global overview of the different things
> going on in the project and some rough ideas of the status of the different
> significant pieces. It would allow us to better organize ourselves.
>
> Le jeu. 26 oct. 2023 à 00:26, Benedict  a écrit :
>
>> I have spoken privately with Ekaterina, and to clear up some possible
>> ambiguity: I realise nobody has demanded a delay to this work to conduct
>> additional reviews; a couple of folk have however said they would prefer
>> one.
>>
>>
>> My point is that, as a community, we need to work on ensuring folk that
>> care about a CEP participate at an appropriate time. If they aren’t able
>> to, the consequences of that are for them to bear.
>>
>>
>> We should be working to avoid surprises as CEP start to land. To this
>> end, I think we should work on some additional paragraphs for the
>> governance doc covering expectations around the landing of CEPs.
>>
>> On 25 Oct 2023, at 21:55, Benedict  wrote:
>>
>> 
>>
>> I am surprised this needs to be said, but - especially for long-running
>> CEPs - you must involve yourself early, and certainly within some
>> reasonable time of being notified the work is ready for broader input and
>> review. In this case, more than six months ago.
>>
>>
>> This isn’t the first time this has happened, and it is disappointing to
>> see it again. Clearly we need to make this explicit in the guidance docs.
>>
>>
>> Regarding the release of 5.1, I understood the proposal to be that we cut
>> an actual alpha, thereby sealing the 5.1 release from new features. Only
>> features merged before we cut the alpha would be permitted, and the alpha
>> should be cut as soon as practicable. What exactly would we be waiting for?
>>
>>
>> If we don’t have a clear and near-term trigger for branching 5.1 for its
>> own release, shortly after Accord and TCM merge, then I am in favour of
>> instead delaying 5.0.
>>
>> On 25 Oct 2023, at 19:40, Mick Semb Wever  wrote:
>>
>> 
>> I'm open to the suggestions of not branching cassandra-5.1 and/or naming
>> a preview release something other than 5.1-alpha1.
>>
>> But… the codebases and release process (and upgrade tests) do not
>> currently support releases with qualifiers that are not alpha, beta, or
>> rc.  We can add a preview qualifier to this list, but I would not want to
>> block getting a preview release out only because this wasn't yet in place.
>>
>> Hence the proposal used 5.1-alpha1 simply because that's what we know we
>> can do today.  An alpha release also means (typically) the branch.
>>
>> Is anyone up for looking into adding a "preview" qualifier to our release
>> process?
>> This may also solve our previous discussions and desire to have quarterly
>> releases that folk can use through the trunk dev cycle.
>>
>> Personally, with my understanding of timelines in front of us to fully
>> review and stabilise tcm, it makes sense to branch it as soon as it's
>> merged.  It's easiest to stabilise it on a branch, and there's definitely
>> the desire and demand to do so, so it won't be getting forgotten or
>>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Maxim Muzafarov]

Personally, I think frequent releases (2-3 per year) are better than
infrequent big releases. I can understand all the concerns from a
marketing perspective, as smaller major releases may not shine as
brightly as a single "game changer" release. However, smaller
releases, especially if they don't have backwards compatibility
issues, are better for the engineering and SRE teams because if a
long-awaited feature is delayed for any reason, there should be no
worry about getting it in right into the next release.

An analogy here might be that if you miss your train (small release)
due to circumstances, you can wait right here for the next one, but if
you miss a flight (big release), you will go back home :-) This is why
I think that the 5.0, 5.1, 5.2, etc. are better and I support Mick's
plan with the caveat that we should release 5.1 when we think we are
ready to do so. Here is an example of the Postgres releases [1].

[1] https://bucardo.org/postgres_all_versions.html


Another little thing that I'd like to mention is a release management
story. In the Apache Ignite project, we've got used to creating a
release thread and posting the release status updates and/or problems,
and/or delays there, and maybe some of the benchmarks at the end. Of
course, this was done by the release manager who volunteered to do
this work. I'm not saying we're doing anything wrong here, no, but the
publicity and openness, coupled with regular updates, could help
create a real sense of the remaining work in progress. These are my
personal feelings, and definitely not actions to be taken. The example
is here: [2].

[2] https://lists.apache.org/thread/m11m0nxq701f2cj8xxdcsc4nnn2sm8ql

On Thu, 26 Oct 2023 at 11:15, Benjamin Lerer  wrote:
>>
>> Regarding the release of 5.1, I understood the proposal to be that we cut an 
>> actual alpha, thereby sealing the 5.1 release from new features. Only 
>> features merged before we cut the alpha would be permitted, and the alpha 
>> should be cut as soon as practicable. What exactly would we be waiting for?
>
>
> The problem I believe is about expectations. It seems that your expectation 
> is that a release with only TCM and Accord will reach GA quickly. Based on 
> the time it took us to release 4.1, I am simply expecting more delays (a GA 
> around end of May, June). In which case it seems to me that we could be 
> interested in shipping more stuff in the meantime (thinking of 
> CASSANDRA-15254 or CEP-29 for example).
> I do not have a strong opinion, I just want to make sure that we all share 
> the same understanding and fully understand what we agree upon.
>
> Le jeu. 26 oct. 2023 à 10:59, Benjamin Lerer  a écrit :
>>>
>>> I am surprised this needs to be said, but - especially for long-running 
>>> CEPs - you must involve yourself early, and certainly within some 
>>> reasonable time of being notified the work is ready for broader input and 
>>> review. In this case, more than six months ago.
>>
>>
>> It is unfortunately more complicated than that because six month ago 
>> Ekaterina and I were working on supporting Java 17 and dropping Java 8 which 
>> was needed by different ongoing works. We both missed the announcement that 
>> TCM was ready for review and anyway would not have been available at that 
>> time. Maxim has asked me ages ago for a review of CASSANDRA-15254  more than 
>> 6 months ago and I have not been able to help him so far. We all have a 
>> limited bandwidth and can miss some announcements.
>>
>> The project has grown and a lot of things are going on in parallel. There 
>> are also more interdependencies between the different projects. In my 
>> opinion what we are lacking is a global overview of the different things 
>> going on in the project and some rough ideas of the status of the different 
>> significant pieces. It would allow us to better organize ourselves.
>>
>> Le jeu. 26 oct. 2023 à 00:26, Benedict  a écrit :
>>>
>>> I have spoken privately with Ekaterina, and to clear up some possible 
>>> ambiguity: I realise nobody has demanded a delay to this work to conduct 
>>> additional reviews; a couple of folk have however said they would prefer 
>>> one.
>>>
>>>
>>> My point is that, as a community, we need to work on ensuring folk that 
>>> care about a CEP participate at an appropriate time. If they aren’t able 
>>> to, the consequences of that are for them to bear.
>>>
>>>
>>> We should be working to avoid surprises as CEP start to land. To this end, 
>>> I think we should work on some additional paragraphs for the governance doc 
>>> covering expectations around the landing of CEPs.
>>>
>>>
>>> On 25 Oct 2023, at 21:55, Benedict  wrote:
>>>
>>> 
>>>
>>> I am surprised this needs to be said, but - especially for long-running 
>>> CEPs - you must involve yourself early, and certainly within some 
>>> reasonable time of being notified the work is ready for broader input and 
>>> review. In this case, more than six months ago.
>>>
>>>
>>> This isn’t the first 

Re: [DISCUSS] Allow UPDATE on settings virtual table to change running configuration

[Maxim Muzafarov]

Josh,

Technically speaking, it will be the 3rd one, so yeah, the main goal
is to make the review process easier, my hands are trembling when I
look at the long technical discussion in that Jira issue :-) but I
also thought it might be a good idea to share the issue status with
the ML since the thread hasn't been updated for a while, and maybe get
some attention outside of the Community for this improvement by
writing a blog post. Sort of all in one.

On Wed, 25 Oct 2023 at 15:00, Josh McKenzie  wrote:
>
> Is the primary pain point you're trying to solve getting a 2nd committer 
> reviewer Maxim? And / or making the review process simpler / cleaner for 
> someone?
>
> On Wed, Oct 18, 2023, at 5:06 PM, Maxim Muzafarov wrote:
>
> Hello everyone,
>
> It has been a long time since the last update on this thread, so I
> wanted to share some status updates: The issue is still awaiting
> review, but all my hopes are pinned on Benjamin :-)
>
> My question here is, is there anything I can do to facilitate the
> review for anyone who wants to delve into the patch?
>
> I have a few thoughts to follow:
> - CEPify the changes - this will allow us to see the result of the
> discussion on a single page without having to re-read the whole
> thread;
> - Write a blog post with possible design solutions - this will both
> reveal the results of the discussion and potentially will draw some
> attention to the community;
> - Presenting and discussing slides at one of the Cassandra Town Halls;
>
> I tend to the 1-st and/or 2-nd points. What are the best practices we
> have here for such cases though? Any thoughts?
>
> On Tue, 11 Jul 2023 at 15:51, Maxim Muzafarov  wrote:
> >
> > Thank you for your comments and for sharing the ticket targeting
> > strategy, I'm really happy to see this page where I have found all the
> > answers to the questions I had. So, I tend towards your view and will
> > just land this ticket on the 5.0 release only for now as it makes
> > sense for me as well.
> >
> > I didn't add the feature flag for this feature because for 99% of the
> > source code changes it only works with Cassandra internals leaving the
> > public API unchanged. A few remarks on this are:
> > - the display format of the vtable property has changed to match the
> > yaml configuration style, this doesn't mean that we are displaying
> > property values in a completely different way in fact the formats
> > match with only 4 exceptions mentioned in the message above (this
> > should be fine for the major release I hope);
> > - a new column, which we've agreed to add (I'll fix the PR shortly);
> >
> >
> > I would also like to mention the follow-up todos required by this
> > issue to set the right expectations. Currently, we've brought a few
> > properties under the framework to make them updateable with the
> > SettingsTable, so that you can keep focusing on the framework itself
> > rather than on tagging the configuration properties themselves with
> > the @Mutable annotation. Although the solution is self-sufficient for
> > the already tagged properties, we still need to bring the rest of them
> > under the framework afterwards. I'll create an issue and do it right,
> > we'll be done with the inital patch.
> >
> >
> > On Fri, 7 Jul 2023 at 20:37, Josh McKenzie  wrote:
> > >
> > > This really is great work Maxim; definitely appreciate all the hard work 
> > > that's gone into it and I think the users will too.
> > >
> > > In terms of where it should land, we discussed this type of question at 
> > > length on the ML awhile ago and ended up codifying it in the wiki: 
> > > https://cwiki.apache.org/confluence/display/CASSANDRA/Patching%2C+versioning%2C+and+LTS+releases
> > >
> > > When working on a ticket, use the following guideline to determine which 
> > > branch to apply it to (Note: See How To Commit for details on the commit 
> > > and merge process)
> > >
> > > Bugfix: apply to oldest applicable LTS and merge up through latest GA to 
> > > trunk
> > >
> > > In the event you need to make changes on the merge commit, merge with -s 
> > > ours and revise the commit via --amend
> > >
> > > Improvement: apply to trunk only (next release)
> > >
> > > Note: refactoring and removing dead code qualifies as an Improvement; our 
> > > priority is stability on GA lines
> > >
> > > New Feature: apply to trunk only (next release)
> > >
> > > Our priority is to keep the 2 LTS releases and latest GA stable while 
> > > releasing new "latest GA" on a cadence that provides new improvements and 
> > > functionality to users soon enough to be valuable and relevant.
> > >
> > >
> > > So in this case, target whatever unreleased next feature release (i.e. 
> > > SEMVER MAJOR || MINOR) we have on deck.
> > >
> > > On Thu, Jul 6, 2023, at 1:21 PM, Ekaterina Dimitrova wrote:
> > >
> > > Hi,
> > >
> > > First of all, thank you for all the work!
> > > I personally think that it should be ok to add a new column.
> > >
> > > I will be very happy to see this land

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Miklosovic, Stefan via dev]

What Maxim proposes in the last paragraph would be definitely helpful. Not for 
the project only but for a broader audience, companies etc., too.

Until this thread was started, my assumption was that "there will be 5.0 on 
summit with TCM and Accord and it somehow just happens". More transparent 
communication where we are at with high-profile CEPs like these and knowing if 
deadlines are going to be met would be welcome.

I don't want to be that guy and don't take me wrong here, but really, these 
CEPs are being developed, basically, by devs from two companies, which have 
developers who do not have any real need to explain themselves like what they 
do, regularly, to outsiders. (or maybe you do, you just don't have time?) I get 
that. But on the other hand, you can not realistically expect that other folks 
will have any visibility into what is going on there and that there is a delay 
on the horizon and so on.


From: Maxim Muzafarov 
Sent: Thursday, October 26, 2023 12:21
To: dev@cassandra.apache.org
Subject: Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 
5.1-alpha1)

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




Personally, I think frequent releases (2-3 per year) are better than
infrequent big releases. I can understand all the concerns from a
marketing perspective, as smaller major releases may not shine as
brightly as a single "game changer" release. However, smaller
releases, especially if they don't have backwards compatibility
issues, are better for the engineering and SRE teams because if a
long-awaited feature is delayed for any reason, there should be no
worry about getting it in right into the next release.

An analogy here might be that if you miss your train (small release)
due to circumstances, you can wait right here for the next one, but if
you miss a flight (big release), you will go back home :-) This is why
I think that the 5.0, 5.1, 5.2, etc. are better and I support Mick's
plan with the caveat that we should release 5.1 when we think we are
ready to do so. Here is an example of the Postgres releases [1].

[1] https://bucardo.org/postgres_all_versions.html


Another little thing that I'd like to mention is a release management
story. In the Apache Ignite project, we've got used to creating a
release thread and posting the release status updates and/or problems,
and/or delays there, and maybe some of the benchmarks at the end. Of
course, this was done by the release manager who volunteered to do
this work. I'm not saying we're doing anything wrong here, no, but the
publicity and openness, coupled with regular updates, could help
create a real sense of the remaining work in progress. These are my
personal feelings, and definitely not actions to be taken. The example
is here: [2].

[2] https://lists.apache.org/thread/m11m0nxq701f2cj8xxdcsc4nnn2sm8ql

On Thu, 26 Oct 2023 at 11:15, Benjamin Lerer  wrote:
>>
>> Regarding the release of 5.1, I understood the proposal to be that we cut an 
>> actual alpha, thereby sealing the 5.1 release from new features. Only 
>> features merged before we cut the alpha would be permitted, and the alpha 
>> should be cut as soon as practicable. What exactly would we be waiting for?
>
>
> The problem I believe is about expectations. It seems that your expectation 
> is that a release with only TCM and Accord will reach GA quickly. Based on 
> the time it took us to release 4.1, I am simply expecting more delays (a GA 
> around end of May, June). In which case it seems to me that we could be 
> interested in shipping more stuff in the meantime (thinking of 
> CASSANDRA-15254 or CEP-29 for example).
> I do not have a strong opinion, I just want to make sure that we all share 
> the same understanding and fully understand what we agree upon.
>
> Le jeu. 26 oct. 2023 à 10:59, Benjamin Lerer  a écrit :
>>>
>>> I am surprised this needs to be said, but - especially for long-running 
>>> CEPs - you must involve yourself early, and certainly within some 
>>> reasonable time of being notified the work is ready for broader input and 
>>> review. In this case, more than six months ago.
>>
>>
>> It is unfortunately more complicated than that because six month ago 
>> Ekaterina and I were working on supporting Java 17 and dropping Java 8 which 
>> was needed by different ongoing works. We both missed the announcement that 
>> TCM was ready for review and anyway would not have been available at that 
>> time. Maxim has asked me ages ago for a review of CASSANDRA-15254  more than 
>> 6 months ago and I have not been able to help him so far. We all have a 
>> limited bandwidth and can miss some announcements.
>>
>> The project has grown and a lot of things are going on in parallel. There 
>> are also more interdependencies between the different projects. In my 
>> opinion what we are lacking is a g

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benedict]

The time to stabilise is orthogonal to the time we branch. Once we branch we stop accepting new features for the branch, and work to stabilise.My understanding is we will branch as soon as we have a viable alpha containing TCM and Accord. That means pretty soon after they land in the project, which we expect to be around the summit.If this isn’t the expectation we should make that clear, as it will affect how this decision is made.On 26 Oct 2023, at 10:14, Benjamin Lerer  wrote:
Regarding the release of 5.1, I 
understood the proposal to be that we cut an actual alpha, thereby 
sealing the 5.1 release from new features. Only features merged before 
we cut the alpha would be permitted, and the alpha should be cut as soon
 as practicable. What exactly would we be waiting for? The problem I believe is about expectations. It seems that your expectation is that a release with only TCM and Accord will reach GA quickly. Based on the time it took us to release 4.1, I am simply expecting more delays (a GA around end of May, June). In which case it seems to me that we could be interested in shipping more stuff in the meantime (thinking of CASSANDRA-15254 or CEP-29 for example).I do not have a strong opinion, I just want to make sure that we all share the same understanding and fully understand what we agree upon.    

Le jeu. 26 oct. 2023 à 10:59, Benjamin Lerer  a écrit :
I am surprised this needs to be said, 
but - especially for long-running CEPs - you must involve yourself 
early, and certainly within some reasonable time of being notified the 
work is ready for broader input and review. In this case, more than six 
months ago.It is unfortunately more complicated than that because six month ago Ekaterina and I were working on supporting Java 17 and dropping Java 8 which was needed by different ongoing works. We both missed the announcement that TCM was ready for review and anyway would not have been available at that time. Maxim has asked me ages ago for a review of 
CASSANDRA-15254  more than 6 months ago and I have not been able to help him so far. We all have a limited bandwidth and can miss some announcements.    

The project has grown and a lot of things are going on in parallel. There are also more interdependencies between the different projects. In my opinion what we are lacking is a global overview of the different things going on in the project and some rough ideas of the status of the different significant pieces. It would allow us to better organize ourselves.    

Le jeu. 26 oct. 2023 à 00:26, Benedict  a écrit :I have spoken privately with Ekaterina, and to clear up some possible ambiguity: I realise nobody has demanded a delay to this work to conduct additional reviews; a couple of folk have however said they would prefer one.

My point is that, as a community, we need to work on ensuring folk that care about a CEP participate at an appropriate time. If they aren’t able to, the consequences of that are for them to bear. We should be working to avoid surprises as CEP start to land. To this end, I think we should work on some additional paragraphs for the governance doc covering expectations around the landing of CEPs.On 25 Oct 2023, at 21:55, Benedict  wrote:I am surprised this needs to be said, but - especially for long-running CEPs - you must involve yourself early, and certainly within some reasonable time of being notified the work is ready for broader input and review. In this case, more than six months ago.

This isn’t the first time this has happened, and it is disappointing to see it again. Clearly we need to make this explicit in the guidance docs.

Regarding the release of 5.1, I understood the proposal to be that we cut an actual alpha, thereby sealing the 5.1 release from new features. Only features merged before we cut the alpha would be permitted, and the alpha should be cut as soon as practicable. What exactly would we be waiting for? 

If we don’t have a clear and near-term trigger for branching 5.1 for its own release, shortly after Accord and TCM merge, then I am in favour of instead delaying 5.0.On 25 Oct 2023, at 19:40, Mick Semb Wever  wrote:I'm open to the suggestions of not branching cassandra-5.1 and/or naming a preview release something other than 5.1-alpha1.But… the codebases and release process (and upgrade tests) do not currently support releases with qualifiers that are not alpha, beta, or rc.  We can add a preview qualifier to this list, but I would not want to block getting a preview release out only because this wasn't yet in place.  Hence the proposal used 5.1-alpha1 simply because that's what we know we can do today.  An alpha release also means (typically) the branch.Is anyone up for looking into adding a "preview" qualifier to our release process? This may also solve our previous discussions and desire to have quarterly releases that folk can use through the trunk dev cycle.Personal

RE: [DISCUSS] CommitLog default disk access mode

[Pawar, Amit]

[Public]

Default behavior won’t be changed as per your feedback and a ‘direct’ mode can 
be used to enable this feature. Thank you all again.

--
Amit

I think introducing the  feature is a good idea.
I also think that it should _NOT_ be enabled by default for all the reasons 
stated above.
Finding a cohort of users who are interested in turning it on would provide a 
nice testbed to shake out any issues without affecting everyone.

On Tue, Oct 17, 2023 at 3:58 PM C. Scott Andreas 
mailto:sc...@paradoxica.net>> wrote:
Let’s please not change the default at the same time the feature is introduced.

Making the capability available will allow users to evaluate and quantify the 
benefit of the work, as well as to call out any unintended consequences. As 
users and the project gain confidence in the results, we can evaluate changing 
the default.

– Scott


On Oct 17, 2023, at 4:25 AM, guo Maxwell 
mailto:cclive1...@gmail.com>> wrote:

-1

I still think we should keep it as it is until the  direct io  for commitlog 
(read and write) is ready and relatively stable. And then we may change the 
default value to direct io from mmap in a future version, such as 5.2, or 6.0.

Pawar, Amit mailto:amit.pa...@amd.com>> 于2023年10月17日周二 
19:03写道：

[AMD Official Use Only - General]

Thank you all for your input. Received total 6 replies and below is the summary.

1. Mmap   : 2/6
2. Direct-I/O : 4/6

Default should be changed to Direct-IO then ? please confirm.

Thanks,
Amit

Strongly agree with this point of view that direct IO  can bring great benefits.

I have reviewed part of the code, and my preliminary judgment is that it is not 
very common and limited in some situations, for example, it  works for 
commitlog's write path only for this patch.So I suggest that the default value 
should not be modified until the entire function is comprehensive and stable, 
and then modified in a future version.

Sam mailto:samueldlightf...@gmail.com>> 
于2023年10月17日周二 05:39写道：
Glad you brought up compaction here - I think there would be a significant 
benefit to moving compaction to direct i/o.

+1. Would love to see this get traction.

On Mon, 16 Oct 2023 at 19:38, Jon Haddad 
mailto:rustyrazorbl...@apache.org>> wrote:
Glad you brought up compaction here - I think there would be a significant 
benefit to moving compaction to direct i/o.


On 2023/10/16 16:14:28 Benedict wrote:
> I have some plans to (eventually) use the commit log as memtable payload 
> storage (ie memtables would reference the commit log entries directly, 
> storing only indexing info), and to back first level of sstables by reference 
> to commit log entries. This will permit us to deliver not only much bigger 
> memtables (cutting compaction throughput requirements by the ratio of size 
> increase - so pretty dramatically), and faster flushing (so better behaviour 
> ling write bursts), but also a fairly cheap and simple way to support MVCC - 
> which will be helpful for transaction throughput.
>
> There is also a new commit log (“journal”) coming with Accord, that the rest 
> of C* may or may not transition to.
>
> I only say this because this makes the utility of direct IO for commit log 
> suspect, as we will be reading from the files as a matter of course should 
> this go ahead; and we may end up relying on a different commit log 
> implementation before long anyway.
>
> This is obviously a big suggestion and is not guaranteed to transpire, and 
> probably won’t within the next year or so, but it should perhaps form some 
> minimal part of any calculus. If the patch is otherwise simple and beneficial 
> I don’t have anything against it, and the use of direct IO could well be of 
> benefit eg in compaction - and also in future if we manage to bring a page 
> management in process. So laying foundations there could be of benefit, even 
> if the commit log eventually does not use it.
>
> > On 16 Oct 2023, at 17:00, Jon Haddad 
> > mailto:rustyrazorbl...@apache.org>> wrote:
> >
> > I haven't looked at the patch, but at a high level, defaulting to direct 
> > I/O for commit logs makes a lot of sense to me.
> >
> >> On 2023/10/16 06:34:05 "Pawar, Amit" wrote:
> >> [Public]
> >>
> >> Hi,
> >>
> >> CommitLog uses mmap (memory mapped ) segments by default. Direct-IO 
> >> feature is proposed through new PR[1] to improve the CommitLog IO speed. 
> >> Enabling this by default could be useful feature to address IO bottleneck 
> >> seen during peak load.
> >>
> >> Need your input regarding changing this default. Please suggest.
> >>
> >> https://issues.apache.org/jira/browse/CASSANDRA-18464
> >>
> >> thanks,
> >> Amit Pawar
> >>
> >> [1] - https://github.com/apache/cassandra/pull/2777
> >>
>


--
you are the apple of my eye !


--
you are the apple of my eye !

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Ekaterina Dimitrova]

Benedict, what is your expectation for stabilization time? And what is the
suggestion for the patches Benjamin mentioned, which are on their way to
land in trunk? (Or any other patch on its way to be merged)

On Thu, 26 Oct 2023 at 8:20, Benedict  wrote:

> The time to stabilise is orthogonal to the time we branch. Once we branch
> we stop accepting new features for the branch, and work to stabilise.
>
> My understanding is we will branch as soon as we have a viable alpha
> containing TCM and Accord. That means pretty soon after they land in the
> project, which we expect to be around the summit.
>
> If this isn’t the expectation we should make that clear, as it will affect
> how this decision is made.
>
> On 26 Oct 2023, at 10:14, Benjamin Lerer  wrote:
>
> 
>
> Regarding the release of 5.1, I understood the proposal to be that we cut
>> an actual alpha, thereby sealing the 5.1 release from new features. Only
>> features merged before we cut the alpha would be permitted, and the alpha
>> should be cut as soon as practicable. What exactly would we be waiting for?
>
>
> The problem I believe is about expectations. It seems that your
> expectation is that a release with only TCM and Accord will reach GA
> quickly. Based on the time it took us to release 4.1, I am simply expecting
> more delays (a GA around end of May, June). In which case it seems to me
> that we could be interested in shipping more stuff in the meantime
> (thinking of CASSANDRA-15254 or CEP-29 for example).
> I do not have a strong opinion, I just want to make sure that we all share
> the same understanding and fully understand what we agree upon.
>
> Le jeu. 26 oct. 2023 à 10:59, Benjamin Lerer  a écrit :
>
>> I am surprised this needs to be said, but - especially for long-running
>>> CEPs - you must involve yourself early, and certainly within some
>>> reasonable time of being notified the work is ready for broader input and
>>> review. In this case, more than six months ago.
>>
>>
>> It is unfortunately more complicated than that because six month ago
>> Ekaterina and I were working on supporting Java 17 and dropping Java 8
>> which was needed by different ongoing works. We both missed the
>> announcement that TCM was ready for review and anyway would not have been
>> available at that time. Maxim has asked me ages ago for a review of
>> CASSANDRA-15254 
>> more than 6 months ago and I have not been able to help him so far. We all
>> have a limited bandwidth and can miss some announcements.
>>
>> The project has grown and a lot of things are going on in parallel. There
>> are also more interdependencies between the different projects. In my
>> opinion what we are lacking is a global overview of the different things
>> going on in the project and some rough ideas of the status of the different
>> significant pieces. It would allow us to better organize ourselves.
>>
>> Le jeu. 26 oct. 2023 à 00:26, Benedict  a écrit :
>>
>>> I have spoken privately with Ekaterina, and to clear up some possible
>>> ambiguity: I realise nobody has demanded a delay to this work to conduct
>>> additional reviews; a couple of folk have however said they would prefer
>>> one.
>>>
>>>
>>> My point is that, as a community, we need to work on ensuring folk that
>>> care about a CEP participate at an appropriate time. If they aren’t able
>>> to, the consequences of that are for them to bear.
>>>
>>>
>>> We should be working to avoid surprises as CEP start to land. To this
>>> end, I think we should work on some additional paragraphs for the
>>> governance doc covering expectations around the landing of CEPs.
>>>
>>> On 25 Oct 2023, at 21:55, Benedict  wrote:
>>>
>>> 
>>>
>>> I am surprised this needs to be said, but - especially for long-running
>>> CEPs - you must involve yourself early, and certainly within some
>>> reasonable time of being notified the work is ready for broader input and
>>> review. In this case, more than six months ago.
>>>
>>>
>>> This isn’t the first time this has happened, and it is disappointing to
>>> see it again. Clearly we need to make this explicit in the guidance docs.
>>>
>>>
>>> Regarding the release of 5.1, I understood the proposal to be that we
>>> cut an actual alpha, thereby sealing the 5.1 release from new features.
>>> Only features merged before we cut the alpha would be permitted, and the
>>> alpha should be cut as soon as practicable. What exactly would we be
>>> waiting for?
>>>
>>>
>>> If we don’t have a clear and near-term trigger for branching 5.1 for its
>>> own release, shortly after Accord and TCM merge, then I am in favour of
>>> instead delaying 5.0.
>>>
>>> On 25 Oct 2023, at 19:40, Mick Semb Wever  wrote:
>>>
>>> 
>>> I'm open to the suggestions of not branching cassandra-5.1 and/or naming
>>> a preview release something other than 5.1-alpha1.
>>>
>>> But… the codebases and release process (and upgrade tests) do not
>>> currently support releases with qu

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benedict]

I don’t want to take a view on how long stabilisation will take, as it’s guesswork. I hope it won’t be lengthy, but that I don’t think these guesses should affect the branch date.The question is only when we branch. The proposal I would endorse is that we branch as soon as TCM and Accord land. I think our normal branch rules should apply besides that - work landing in trunk between now and then makes the cut, but once branched new work lands in trunk, not 5.1.Since we’re also stabilising 5.0, I don’t expect lots of work to land between now and then. But that’s a question of focus and practicality, not a procedurally position.On 26 Oct 2023, at 13:36, Ekaterina Dimitrova  wrote:Benedict, what is your expectation for stabilization time? And what is the suggestion for the patches Benjamin mentioned, which are on their way to land in trunk? (Or any other patch on its way to be merged)On Thu, 26 Oct 2023 at 8:20, Benedict  wrote:The time to stabilise is orthogonal to the time we branch. Once we branch we stop accepting new features for the branch, and work to stabilise.My understanding is we will branch as soon as we have a viable alpha containing TCM and Accord. That means pretty soon after they land in the project, which we expect to be around the summit.If this isn’t the expectation we should make that clear, as it will affect how this decision is made.On 26 Oct 2023, at 10:14, Benjamin Lerer  wrote:
Regarding the release of 5.1, I 
understood the proposal to be that we cut an actual alpha, thereby 
sealing the 5.1 release from new features. Only features merged before 
we cut the alpha would be permitted, and the alpha should be cut as soon
 as practicable. What exactly would we be waiting for? The problem I believe is about expectations. It seems that your expectation is that a release with only TCM and Accord will reach GA quickly. Based on the time it took us to release 4.1, I am simply expecting more delays (a GA around end of May, June). In which case it seems to me that we could be interested in shipping more stuff in the meantime (thinking of CASSANDRA-15254 or CEP-29 for example).I do not have a strong opinion, I just want to make sure that we all share the same understanding and fully understand what we agree upon.    

Le jeu. 26 oct. 2023 à 10:59, Benjamin Lerer  a écrit :
I am surprised this needs to be said, 
but - especially for long-running CEPs - you must involve yourself 
early, and certainly within some reasonable time of being notified the 
work is ready for broader input and review. In this case, more than six 
months ago.It is unfortunately more complicated than that because six month ago Ekaterina and I were working on supporting Java 17 and dropping Java 8 which was needed by different ongoing works. We both missed the announcement that TCM was ready for review and anyway would not have been available at that time. Maxim has asked me ages ago for a review of 
CASSANDRA-15254  more than 6 months ago and I have not been able to help him so far. We all have a limited bandwidth and can miss some announcements.    

The project has grown and a lot of things are going on in parallel. There are also more interdependencies between the different projects. In my opinion what we are lacking is a global overview of the different things going on in the project and some rough ideas of the status of the different significant pieces. It would allow us to better organize ourselves.    

Le jeu. 26 oct. 2023 à 00:26, Benedict  a écrit :I have spoken privately with Ekaterina, and to clear up some possible ambiguity: I realise nobody has demanded a delay to this work to conduct additional reviews; a couple of folk have however said they would prefer one.

My point is that, as a community, we need to work on ensuring folk that care about a CEP participate at an appropriate time. If they aren’t able to, the consequences of that are for them to bear. We should be working to avoid surprises as CEP start to land. To this end, I think we should work on some additional paragraphs for the governance doc covering expectations around the landing of CEPs.On 25 Oct 2023, at 21:55, Benedict  wrote:I am surprised this needs to be said, but - especially for long-running CEPs - you must involve yourself early, and certainly within some reasonable time of being notified the work is ready for broader input and review. In this case, more than six months ago.

This isn’t the first time this has happened, and it is disappointing to see it again. Clearly we need to make this explicit in the guidance docs.

Regarding the release of 5.1, I understood the proposal to be that we cut an actual alpha, thereby sealing the 5.1 release from new features. Only features merged before we cut the alpha would be permitted, and the alpha should be cut as soon as practicable. What exactly would we be waiting for? 

If we don’t have a clear

RE: [DISCUSS] CommitLog default disk access mode

[Pawar, Amit]

[Public]

Default behavior is not changed. Thank you, Josh for your appreciation. This is 
my first patch, and it means lot to me.

Thanks again,
Amit

+1 to adding the feature, clear and easy configurability, and if after a major 
cycle we can say with confidence it's beating the status quo in the vast 
majority of general cases, flip default. I mean, logically it should be, but 
infra software at the scale we do requires great care. :)

This is great work Amit - well done.

On Mon, Oct 16, 2023, at 4:28 PM, Dinesh Joshi wrote:
I haven't looked at the patch yet so take whatever I say here with a pinch of 
salt.

Philosophically, defaults should not change unless there is a clear 
demonstrable benefit in majority cases for our users. In this case DirectIO 
should have clear benefits. That said, this is a new feature and I would 
personally default it to off. We should document it and allow for our users to 
enable it. This derisks the project in case there is an inadvertent change in 
behavior.

Dinesh

On Oct 15, 2023, at 11:34 PM, Pawar, Amit 
mailto:amit.pa...@amd.com>> wrote:


[Public]

Hi,

CommitLog uses mmap (memory mapped ) segments by default. Direct-IO feature is 
proposed through new PR[1] to improve the CommitLog IO speed. Enabling this by 
default could be useful feature to address IO bottleneck seen during peak load.

Need your input regarding changing this default. Please suggest.

https://issues.apache.org/jira/browse/CASSANDRA-18464

thanks,
Amit Pawar

[1] - https://github.com/apache/cassandra/pull/2777

Re: [DISCUSS] CommitLog default disk access mode

[guo Maxwell]

Thanks  for your contribution 😀

Pawar, Amit 于2023年10月26日 周四下午11:41写道：

> [Public]
>
> Default behavior is not changed. Thank you, Josh for your appreciation.
> This is my first patch, and it means lot to me.
>
>
>
> Thanks again,
>
> Amit
>
>
>
> +1 to adding the feature, clear and easy configurability, and if after a
> major cycle we can say with confidence it's beating the status quo in the
> vast majority of general cases, flip default. I mean, logically it
> *should* be, but infra software at the scale we do requires great care. :)
>
>
>
> This is great work Amit - well done.
>
>
>
> On Mon, Oct 16, 2023, at 4:28 PM, Dinesh Joshi wrote:
>
> I haven't looked at the patch yet so take whatever I say here with a pinch
> of salt.
>
>
>
> Philosophically, defaults should not change unless there is a clear
> demonstrable benefit in majority cases for our users. In this case DirectIO
> should have clear benefits. That said, this is a new feature and I would
> personally default it to off. We should document it and allow for our users
> to enable it. This derisks the project in case there is an inadvertent
> change in behavior.
>
>
>
> Dinesh
>
>
>
> On Oct 15, 2023, at 11:34 PM, Pawar, Amit  wrote:
>
>
>
> [Public]
>
>
>
> Hi,
>
>
>
> CommitLog uses mmap (memory mapped ) segments by default. Direct-IO
> feature is proposed through new PR[1] to improve the CommitLog IO speed.
> Enabling this by default could be useful feature to address IO bottleneck
> seen during peak load.
>
>
>
> Need your input regarding changing this default. Please suggest.
>
>
>
> https://issues.apache.org/jira/browse/CASSANDRA-18464
>
>
>
> thanks,
>
> Amit Pawar
>
>
>
> [1] - https://github.com/apache/cassandra/pull/2777
>
>
>

Re: [EXTERNAL] Re: [DISCUSS] Add JVector as a dependency for CEP-30

[Mick Semb Wever]

Legal (Roman) helped clarify the situation for us, see comment on LEGAL-656.

We have the comments on CASSANDRA-18715 confirming ownership of both the
work being contributed and that belonging in the jvector library.

For our (downstream) users and their companies, these legal guarantees are
important and we are respectful that many folk place trust in the ASF's
projects because of them.  It is appreciated that it's brought to light and
dealt with, and I learnt a few things along the way.




On Wed, 25 Oct 2023 at 00:12, Benedict  wrote:

> [LEGAL-656] Application of Generative AI policy to dependencies - ASF JIRA
> 
> issues.apache.org 
> [image: fav-jsw.png] 
> 
>
> Legal’s opinion is that this is not an acceptable workaround to the policy.
>
> On 22 Sep 2023, at 23:51, German Eichberger via dev <
> dev@cassandra.apache.org> wrote:
>
> 
> +1 with taking it to legal
>
> As anyone else I enjoy speculating about legal stuff and I think for jars
> you probably need possible deniability aka no paper trail that we
> knowingly... but that horse is out of the barn. So really interested in
> what legal says 🙂
>
> If you can stomach non Java here is an alternate DiskANN implementation: 
> microsoft/DiskANN:
> Graph-structured Indices for Scalable, Fast, Fresh and Filtered Approximate
> Nearest Neighbor Search (github.com)
> 
>
> Thanks,
> German
>
> --
> *From:* Josh McKenzie 
> *Sent:* Friday, September 22, 2023 7:43 AM
> *To:* dev 
> *Subject:* [EXTERNAL] Re: [DISCUSS] Add JVector as a dependency for CEP-30
>
>
> I highly doubt liability works like that in all jurisdictions
>
> That's a fantastic point. When speculating there, I overlooked the fact
> that there are literally dozens of legal jurisdictions in which this
> project is used and the foundation operates.
>
> As a PMC let's take this to legal.
>
> On Fri, Sep 22, 2023, at 9:16 AM, Jeff Jirsa wrote:
>
> To do that, the cassandra PMC can open a legal JIRA and ask for a
> (durable, concrete) opinion.
>
>
> On Fri, Sep 22, 2023 at 5:59 AM Benedict  wrote:
>
>
>
>1. my understanding is that with the former the liability rests on the
>provider of the lib to ensure it's in compliance with their claims to
>copyright
>
> I highly doubt liability works like that in all jurisdictions, even if it
> might in some. I can even think of some historic cases related to Linux
> where patent trolls went after users of Linux, though I’m not sure where
> that got to and I don’t remember all the details.
>
> But anyway, none of us are lawyers and we shouldn’t be depending on this
> kind of analysis. At minimum we should invite legal to proffer an opinion
> on whether dependencies are a valid loophole to the policy.
>
>
>
> On 22 Sep 2023, at 13:48, J. D. Jordan  wrote:
>
> 
>
> This Gen AI generated code use thread should probably be its own mailing
> list DISCUSS thread?  It applies to all source code we take in, and accept
> copyright assignment of, not to jars we depend on and not only to vector
> related code contributions.
>
> On Sep 22, 2023, at 7:29 AM, Josh McKenzie  wrote:
>
> 
> So if we're going to chat about GenAI on this thread here, 2 things:
>
>1. A dependency we pull in != a code contribution (I am not a lawyer
>but my understanding is that with the former the liability rests on the
>provider of the lib to ensure it's in compliance with their claims to
>copyright and it's not sticky). Easier to transition to a different dep if
>there's something API compatible or similar.
>2. With code contributions we take in, we take on some exposure in
>terms of copyright and infringement. git revert can be painful.
>
> For this thread, here's an excerpt from the ASF policy:
>
> a recommended practice when using generative AI tooling is to use tools
> with features that identify any included content that is similar to parts
> of the tool’s training data, as well as the license of that content.
>
> Given the above, code generated in whole or in part using AI can be
> contributed if the contributor ensures that:
>
>1. The terms and conditions of the generative AI tool do not place any
>restrictions on use of the output that would be inconsistent with the Open
>Source Definition (e.g., ChatGPT’s terms are inconsistent).
>2. At least one of the following conditions is met:
>1. The output is not copyrightable subject matter (and would not be
>   even if produced by a human)
>   2. No third party materials are included in the output
>   3. Any third party materials that are included in the output are
>   being used with permission (e.g., under a compatible open source 
> license)
>   of the third party copyright holders and in compliance wi

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[German Eichberger via dev]

+1 to Maxim's idea

Like Stefan my assumption was that we would get some version of TCM + ACCORD in 
5.0 but it wouldn't be ready for production use. My own testing and 
conversations at Community over Code in Halifax confirmed this.

From this perspective as disappointing as TCM+ACCORD slipping is moving it to 
5.1 makes sense and I am supporting of this - but I am worried if 5.1 is 
basically 5.0 + TCM/ACCORD and this slips again we draw ourselves into a corner 
where we can't release 5.2 before 5.1 or something. I would like some more 
elaboration on that.

I am also very worried about ANN vector search being in jeopardy for 5.0 which 
is an important feature for me to win some internal company bet 🙂

My 2 cents,
German


From: Miklosovic, Stefan via dev 
Sent: Thursday, October 26, 2023 4:23 AM
To: dev@cassandra.apache.org 
Cc: Miklosovic, Stefan 
Subject: [EXTERNAL] Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut 
an immediate 5.1-alpha1)

What Maxim proposes in the last paragraph would be definitely helpful. Not for 
the project only but for a broader audience, companies etc., too.

Until this thread was started, my assumption was that "there will be 5.0 on 
summit with TCM and Accord and it somehow just happens". More transparent 
communication where we are at with high-profile CEPs like these and knowing if 
deadlines are going to be met would be welcome.

I don't want to be that guy and don't take me wrong here, but really, these 
CEPs are being developed, basically, by devs from two companies, which have 
developers who do not have any real need to explain themselves like what they 
do, regularly, to outsiders. (or maybe you do, you just don't have time?) I get 
that. But on the other hand, you can not realistically expect that other folks 
will have any visibility into what is going on there and that there is a delay 
on the horizon and so on.


From: Maxim Muzafarov 
Sent: Thursday, October 26, 2023 12:21
To: dev@cassandra.apache.org
Subject: Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 
5.1-alpha1)

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




Personally, I think frequent releases (2-3 per year) are better than
infrequent big releases. I can understand all the concerns from a
marketing perspective, as smaller major releases may not shine as
brightly as a single "game changer" release. However, smaller
releases, especially if they don't have backwards compatibility
issues, are better for the engineering and SRE teams because if a
long-awaited feature is delayed for any reason, there should be no
worry about getting it in right into the next release.

An analogy here might be that if you miss your train (small release)
due to circumstances, you can wait right here for the next one, but if
you miss a flight (big release), you will go back home :-) This is why
I think that the 5.0, 5.1, 5.2, etc. are better and I support Mick's
plan with the caveat that we should release 5.1 when we think we are
ready to do so. Here is an example of the Postgres releases [1].

[1] 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbucardo.org%2Fpostgres_all_versions.html&data=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cc811f6a430d1466acc3f08dbd61639c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638339163187354112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zjMpuN%2FQMhBtFTemLswn8BRaLyQ9eLZTIeZfeWYwhQk%3D&reserved=0


Another little thing that I'd like to mention is a release management
story. In the Apache Ignite project, we've got used to creating a
release thread and posting the release status updates and/or problems,
and/or delays there, and maybe some of the benchmarks at the end. Of
course, this was done by the release manager who volunteered to do
this work. I'm not saying we're doing anything wrong here, no, but the
publicity and openness, coupled with regular updates, could help
create a real sense of the remaining work in progress. These are my
personal feelings, and definitely not actions to be taken. The example
is here: [2].

[2] 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fm11m0nxq701f2cj8xxdcsc4nnn2sm8ql&data=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cc811f6a430d1466acc3f08dbd61639c2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638339163187360611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BG0wgMItsMv83XDLzRgbfJoi%2FiwSywWU0qAzN%2BmMBZU%3D&reserved=0

On Thu, 26 Oct 2023 at 11:15, Benjamin Lerer  wrote:
>>
>> Regarding the release of 5.1, I understood the proposal