Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)
> I’m not sure we need any additional mechanisms beyond DISCUSS threads, polls > and lazy consensus? > ... > This likely means at least another DISCUSS thread and lazy consensus if you > want to knowingly go against it, or want to modify or clarify what’s meant. > ... > It can be chucked out or rewoven at zero cost, but if the norms have taken > hold and are broadly understood in the same way, it won’t change much or at > all, because the actual glue is the norm, not the words, which only serve to > broadcast some formulation of the norm. 100% agree on all counts. Hopefully this discussion is useful for other folks as well. So - with the clarification that our agreement on green CI represents a polled majority consensus of the folks participating on the discussion at the time but not some kind of hard unbendable obligation, is this something we want to consider relaxing for TCM and Accord? This thread ran long (and got detoured - mea culpa) - the tradeoffs seem like: 1. We merge them without green CI and cut a cassandra-5.1 branch so we can release an alpha-1 snapshot from that branch. This likely leaves cassandra-5.1 and trunk in an unstable place w/regards to CI. TCM/Accord devs can be expected to be pulled into fixing core issues / finalizing the features and the burden for test stabilization "leaking out" across others in the community who don't have context on their breakage (see: CASSANDRA-8099, cassandra-4.0 release, cassandra-4.1 release, now push for cassandra-5.0 QA stabilization). 2. Push for green CI on Accord / TCM before merge and alpha availability, almost certainly delaying their availability to the community. 3. Cut a preview / snapshot release from the accord feature branch, made available to the dev community. We could automate creation / update of docker images with snapshot releases of all HEAD for trunk and feature branches. 4. Some other approach I'm not thinking of / missed So as Mick asked earlier in the thread: > Is anyone up for looking into adding a "preview" qualifier to our release > process? I'm in favor of this. If we cut preview snapshots from trunk and all feature branches periodically (nightly? weekly?), preferably as docker images, this satisfies the desire to get these features into the hands of the dev and user community to test them out and provide feedback to the dev process while also allowing us to keep a high bar for merge to trunk. Referencing the ASF Release Policy: https://www.apache.org/legal/release-policy.html#release-definition, this is consistent with the guidance: > During the process of developing software and preparing a release, various > packages are made available to the development community for testing > purposes. Projects MUST direct outsiders towards official releases rather > than raw source repositories, nightly builds, snapshots, release candidates, > or any other similar packages. Projects SHOULD make available developer > resources to support individuals actively participating in development or > following the dev list and thus aware of the conditions placed on unreleased > materials. We direct people to the official downloads on the website and add a section below that references the latest snapshot releases for CEP-approved feature branch work in progress + trunk. > Generically, a release is anything that is published beyond the group that > owns it. For an Apache project, that means any publication outside the > development community, defined as individuals actively participating in > development or following the dev list. I think so long as we're clear about them being preview / snapshot releases of in-development work where we're looking for feedback on the dev process, as well as clearly directing people to the dev ML and #cassandra-dev on slack, this would be a pretty big win for the project. So - that's my bid. What do others think? On Wed, Nov 1, 2023, at 8:11 PM, Benedict wrote: > > So my view is that the community is strongly built on consensus, so > expressions of sentiment within the community have strong normative weight > even without any specific legislative effect. You shouldn’t knowingly go > against what appears to be a consensus (or even widely-held) view, even if it > has no formal weight. So I’m not sure we need any additional mechanisms > beyond DISCUSS threads, polls and lazy consensus? > > Let’s treat your thread as a POLL for arguments sake: lots of folk voted, and > every vote was positive. So clearly there’s strong endorsement for the > approach, or parts thereof, in some form. Given the goal of consensus in > decision-making, it would not be reasonable to ignore this widely held view > on contributions. This likely means at least another DISCUSS thread and lazy > consensus if you want to knowingly go against it, or want to modify or > clarify what’s meant. This just falls naturally out of how we do things here > I think, and is how we go about a l
Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)
My view is that we wait and see what the CI looks like at that time.My reading of ASF policy is that directing users to CEP preview releases that are not formally voted upon is not acceptable. The policy you quote indicates they should be intended only for active participants on dev@, whereas our explicit intention is to enable them to be advertised to users at the summit.On 2 Nov 2023, at 13:27, Josh McKenzie wrote:I’m not sure we need any additional mechanisms beyond DISCUSS threads, polls and lazy consensus?...This likely means at least another DISCUSS thread and lazy consensus if you want to knowingly go against it, or want to modify or clarify what’s meant. ...It can be chucked out or rewoven at zero cost, but if the norms have taken hold and are broadly understood in the same way, it won’t change much or at all, because the actual glue is the norm, not the words, which only serve to broadcast some formulation of the norm.100% agree on all counts. Hopefully this discussion is useful for other folks as well.So - with the clarification that our agreement on green CI represents a polled majority consensus of the folks participating on the discussion at the time but not some kind of hard unbendable obligation, is this something we want to consider relaxing for TCM and Accord?This thread ran long (and got detoured - mea culpa) - the tradeoffs seem like:We merge them without green CI and cut a cassandra-5.1 branch so we can release an alpha-1 snapshot from that branch. This likely leaves cassandra-5.1 and trunk in an unstable place w/regards to CI. TCM/Accord devs can be expected to be pulled into fixing core issues / finalizing the features and the burden for test stabilization "leaking out" across others in the community who don't have context on their breakage (see: CASSANDRA-8099, cassandra-4.0 release, cassandra-4.1 release, now push for cassandra-5.0 QA stabilization).Push for green CI on Accord / TCM before merge and alpha availability, almost certainly delaying their availability to the community.Cut a preview / snapshot release from the accord feature branch, made available to the dev community. We could automate creation / update of docker images with snapshot releases of all HEAD for trunk and feature branches.Some other approach I'm not thinking of / missedSo as Mick asked earlier in the thread:Is anyone up for looking into adding a "preview" qualifier to our release process? I'm in favor of this. If we cut preview snapshots from trunk and all feature branches periodically (nightly? weekly?), preferably as docker images, this satisfies the desire to get these features into the hands of the dev and user community to test them out and provide feedback to the dev process while also allowing us to keep a high bar for merge to trunk.Referencing the ASF Release Policy: https://www.apache.org/legal/release-policy.html#release-definition, this is consistent with the guidance:During the process of developing software and preparing a release, various packages are made available to the development community for testing purposes. Projects MUST direct outsiders towards official releases rather than raw source repositories, nightly builds, snapshots, release candidates, or any other similar packages. Projects SHOULD make available developer resources to support individuals actively participating in development or following the dev list and thus aware of the conditions placed on unreleased materials.We direct people to the official downloads on the website and add a section below that references the latest snapshot releases for CEP-approved feature branch work in progress + trunk.Generically, a release is anything that is published beyond the group that owns it. For an Apache project, that means any publication outside the development community, defined as individuals actively participating in development or following the dev list.I think so long as we're clear about them being preview / snapshot releases of in-development work where we're looking for feedback on the dev process, as well as clearly directing people to the dev ML and #cassandra-dev on slack, this would be a pretty big win for the project.So - that's my bid. What do others think?On Wed, Nov 1, 2023, at 8:11 PM, Benedict wrote:So my view is that the community is strongly built on consensus, so expressions of sentiment within the community have strong normative weight even without any specific legislative effect. You shouldn’t knowingly go against what appears to be a consensus (or even widely-held) view, even if it has no formal weight. So I’m not sure we need any additional mechanisms beyond DISCUSS threads, polls and lazy consensus?Let’s treat your thread as a POLL for arguments sake: lots of folk voted, and every vote was positive. So clearly there’s strong endorsement for the approach, or parts thereof, in some form. Given the goal of consensus in decision-making, it would not be reasonable to ignore this widely held view on contributions.
Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)
> > My reading of ASF policy is that directing users to CEP preview releases > that are not formally voted upon is not acceptable. The policy you quote > indicates they should be intended only for active participants on dev@, > whereas our explicit intention is to enable them to be advertised to users > at the summit. > Yes this is my read as well. If we want to announce anything at summit and have a wider audience getting involved in using it, then we need to make a “formal” preview release available, aka one that has been voted on and approved by the PMC. There is nothing stopping us from building and voting on a release that comes from a feature branch, it just needs to go through the normal artifact build and verification that any release goes through. So as Mick asked earlier in the thread: > > Is anyone up for looking into adding a "preview" qualifier to our release > process? > > > I'm in favor of this. If we cut preview snapshots from trunk and all > feature branches periodically (nightly? weekly?), preferably as docker > images, this satisfies the desire to get these features into the hands of > the dev and user community to test them out and provide feedback to the dev > process while also allowing us to keep a high bar for merge to trunk. > > I am also in favor of this, and if we can make it work there is nothing stopping us from having someone use the capability to make a preview release that can go to a formal vote. My view is that we wait and see what the CI looks like at that time. > I also agree we should see what CI looks like at the time and make the “go”/"no go" on merge decision based on the state then. But I think we need to have a plan for what happens if we end up with “no go”. We don’t want to be scrambling at the last minute in that case. Again “no go” is not my preferred outcome, but I want to make sure we have plans in place should it occur. -Jeremiah On Nov 2, 2023 at 9:16:54 AM, Benedict wrote: > My view is that we wait and see what the CI looks like at that time. > > > My reading of ASF policy is that directing users to CEP preview releases > that are not formally voted upon is not acceptable. The policy you quote > indicates they should be intended only for active participants on dev@, > whereas our explicit intention is to enable them to be advertised to users > at the summit. > > > > > On 2 Nov 2023, at 13:27, Josh McKenzie wrote: > > > > I’m not sure we need any additional mechanisms beyond DISCUSS threads, > polls and lazy consensus? > ... > This likely means at least another DISCUSS thread and lazy consensus if > you want to knowingly go against it, or want to modify or clarify what’s > meant. > ... > It can be chucked out or rewoven at zero cost, but if the norms have taken > hold and are broadly understood in the same way, it won’t change much or at > all, because the actual glue is the norm, not the words, which only serve > to broadcast some formulation of the norm. > > 100% agree on all counts. Hopefully this discussion is useful for other > folks as well. > > So - with the clarification that our agreement on green CI represents a > polled majority consensus of the folks participating on the discussion at > the time but not some kind of hard unbendable obligation, is this something > we want to consider relaxing for TCM and Accord? > > This thread ran long (and got detoured - mea culpa) - the tradeoffs seem > like: > >1. We merge them without green CI and cut a cassandra-5.1 branch so we >can release an alpha-1 snapshot from that branch. This likely leaves >cassandra-5.1 and trunk in an unstable place w/regards to CI. TCM/Accord >devs can be expected to be pulled into fixing core issues / finalizing the >features and the burden for test stabilization "leaking out" across others >in the community who don't have context on their breakage (see: >CASSANDRA-8099, cassandra-4.0 release, cassandra-4.1 release, now push for >cassandra-5.0 QA stabilization). >2. Push for green CI on Accord / TCM before merge and alpha >availability, almost certainly delaying their availability to the > community. >3. Cut a preview / snapshot release from the accord feature branch, >made available to the dev community. We could automate creation / update of >docker images with snapshot releases of all HEAD for trunk and feature >branches. >4. Some other approach I'm not thinking of / missed > > So as Mick asked earlier in the thread: > > Is anyone up for looking into adding a "preview" qualifier to our release > process? > > > I'm in favor of this. If we cut preview snapshots from trunk and all > feature branches periodically (nightly? weekly?), preferably as docker > images, this satisfies the desire to get these features into the hands of > the dev and user community to test them out and provide feedback to the dev > process while also allowing us to keep a high bar for merge to trunk. > > Referencing the ASF Relea
Re: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha2
+1 (nb) On Wed, 1 Nov 2023 at 03:26, guo Maxwell wrote: > > +1 > > German Eichberger via dev 于2023年11月1日周三 04:58写道： >> >> +1 >> >> Heck, yeah, we already tested the branch (build ourselves) and it works >> great so far. >> >> From: Mick Semb Wever >> Sent: Tuesday, October 31, 2023 1:43 PM >> Cc: dev >> Subject: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha2 >> >> > The vote will be open for 72 hours (longer if needed). Everyone who >> > has tested the build is invited to vote. Votes by PMC members are >> > considered binding. A vote passes if there are at least three binding >> > +1s and no -1's. >> >> >> +1 >> >> Checked >> - signing correct >> - checksums are correct >> - source artefact builds (JDK 11+17) >> - binary artefact runs (JDK 11+17) >> - debian package runs (JDK 11+17) >> - debian repo runs (JDK 11+17) >> - redhat* package runs (JDK11+17) >> - redhat* repo runs (JDK 11+17)
Re: [VOTE] Release Apache Cassandra 5.0-alpha2
+1 Kind Regards, Brandon On Mon, Oct 30, 2023 at 4:47 PM Mick Semb Wever wrote: > > Proposing the test build of Cassandra 5.0-alpha2 for release. > > DISCLAIMER, this alpha release does not contain the features: > Transactional Cluster Metadata (CEP-21) and Accord Transactions > (CEP-15). These features are under discussion to be pushed to a > 5.1-alpha1 release, with an eta still this year. > > This release does contain Vector Similarity Search (CEP-30). > > Please also note that this is an alpha release and what that means, > further info at > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle > > sha1: ea76d148c374198fede6978422895668857a927f > Git: https://github.com/apache/cassandra/tree/5.0-alpha2-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1317/org/apache/cassandra/cassandra-all/5.0-alpha2/ > > The Source and Build Artifacts, and the Debian and RPM packages and > repositories, are available here: > https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha2/ > > The vote will be open for 72 hours (longer if needed). Everyone who > has tested the build is invited to vote. Votes by PMC members are > considered binding. A vote passes if there are at least three binding > +1s and no -1's. > > [1]: CHANGES.txt: > https://github.com/apache/cassandra/blob/5.0-alpha2-tentative/CHANGES.txt > [2]: NEWS.txt: > https://github.com/apache/cassandra/blob/5.0-alpha2-tentative/NEWS.txt
Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)
Sorry, for changing the subject slightly. My understanding from the thread so far (correct me if I am wrong) is that there is at least an agreement on merging Accord and TCM in 5.1. I would like to move tickets to their correct target versions and update the dashboard tomorrow so that we have a clear view on what is needed to bring 5.0 to RC. Anybody has a concern with that? Le jeu. 2 nov. 2023 à 17:04, Benedict a écrit : > > Projects *MUST* direct outsiders towards *official releases rather than* > raw source repositories, nightly builds, *snapshots, release candidates, > or any other similar packages*. > > Admittedly, “direct” here is ambiguous, but I think the sentiment that > users should only be invited to use voted releases is reasonable either way. > > On 2 Nov 2023, at 15:59, Josh McKenzie wrote: > > > > My reading of ASF policy is that directing users to CEP preview releases > that are not formally voted upon is not acceptable. The policy you quote > indicates they should be intended only for active participants on dev@ > > I disagree with this interpretation; it'd be good to get some > clarification as I don't see the narrow requirement of "developers on dev@". > This interpretation would actively stifle any project's ability to get > early user input and testing on things that are in-development. The primary > reason I read it differently (aside from the negative implications) is the > following text (emphasis mine): > > Projects *SHOULD make available developer resources to support > individuals actively participating in development* or following the dev > list and thus aware of the conditions placed on unreleased materials. > > For example, a user downloading a snapshot release with the unified > compaction strategy in it to test it against their data set and provide > feedback to engineers working on it on the dev ML or dev slack is very much > someone actively participating in the development. It shouldn't just be > contributors or committers actively working on the code who touch it before > it's merged to trunk should it? > > On Thu, Nov 2, 2023, at 10:16 AM, Benedict wrote: > > > My view is that we wait and see what the CI looks like at that time. > > > My reading of ASF policy is that directing users to CEP preview releases > that are not formally voted upon is not acceptable. The policy you quote > indicates they should be intended only for active participants on dev@, > whereas our explicit intention is to enable them to be advertised to users > at the summit. > > > > > On 2 Nov 2023, at 13:27, Josh McKenzie wrote: > > > > I’m not sure we need any additional mechanisms beyond DISCUSS threads, > polls and lazy consensus? > ... > This likely means at least another DISCUSS thread and lazy consensus if > you want to knowingly go against it, or want to modify or clarify what’s > meant. > ... > It can be chucked out or rewoven at zero cost, but if the norms have taken > hold and are broadly understood in the same way, it won’t change much or at > all, because the actual glue is the norm, not the words, which only serve > to broadcast some formulation of the norm. > > 100% agree on all counts. Hopefully this discussion is useful for other > folks as well. > > So - with the clarification that our agreement on green CI represents a > polled majority consensus of the folks participating on the discussion at > the time but not some kind of hard unbendable obligation, is this something > we want to consider relaxing for TCM and Accord? > > This thread ran long (and got detoured - mea culpa) - the tradeoffs seem > like: > >1. We merge them without green CI and cut a cassandra-5.1 branch so we >can release an alpha-1 snapshot from that branch. This likely leaves >cassandra-5.1 and trunk in an unstable place w/regards to CI. TCM/Accord >devs can be expected to be pulled into fixing core issues / finalizing the >features and the burden for test stabilization "leaking out" across others >in the community who don't have context on their breakage (see: >CASSANDRA-8099, cassandra-4.0 release, cassandra-4.1 release, now push for >cassandra-5.0 QA stabilization). >2. Push for green CI on Accord / TCM before merge and alpha >availability, almost certainly delaying their availability to the > community. >3. Cut a preview / snapshot release from the accord feature branch, >made available to the dev community. We could automate creation / update of >docker images with snapshot releases of all HEAD for trunk and feature >branches. >4. Some other approach I'm not thinking of / missed > > So as Mick asked earlier in the thread: > > Is anyone up for looking into adding a "preview" qualifier to our release > process? > > > I'm in favor of this. If we cut preview snapshots from trunk and all > feature branches periodically (nightly? weekly?), preferably as docker > images, this satisfies the desire to get these features into the hands of > the dev
Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)
> Projects *SHOULD make available developer resources to support > individuals actively participating in development* or following the dev > list and thus aware of the conditions placed on unreleased materials. > > For example, a user downloading a snapshot release with the unified > compaction strategy in it to test it against their data set and provide > feedback to engineers working on it on the dev ML or dev slack is very much > someone actively participating in the development. It shouldn't just be > contributors or committers actively working on the code who touch it before > it's merged to trunk should it? > I think “actively participating in development” is the key phrase here. This to me reads as “they are on dev@“ or “they are in JIRA” or “they are actively looking through the source code". You can make nightly builds which do not have votes and talk about and promote them on dev@ all you want. But you can not promote them to people who are not actively involved in the development of the project. > Projects *MUST* direct outsiders towards *official releases rather than* raw > source repositories, nightly builds, *snapshots, release candidates, or > any other similar packages*. > > Admittedly, “direct” here is ambiguous, but I think the sentiment that > users should only be invited to use voted releases is reasonable either way. > I also read this the same way, that “outsiders” aka “people not on dev@“ aka “the room full of people at a user conference who are not day to day involved in the development of the software” should not be told to download a release which has not been voted on. As much as I think it is silly, end users should be able to see the providence of a release and understand what they are getting themselves into by using a nightly build, I can understand where the logic comes from and begrudgingly agree with it. -Jeremiah On Nov 2, 2023 at 10:58:49 AM, Josh McKenzie wrote: > My reading of ASF policy is that directing users to CEP preview releases > that are not formally voted upon is not acceptable. The policy you quote > indicates they should be intended only for active participants on dev@ > > I disagree with this interpretation; it'd be good to get some > clarification as I don't see the narrow requirement of "developers on dev@". > This interpretation would actively stifle any project's ability to get > early user input and testing on things that are in-development. The primary > reason I read it differently (aside from the negative implications) is the > following text (emphasis mine): > > Projects *SHOULD make available developer resources to support > individuals actively participating in development* or following the dev > list and thus aware of the conditions placed on unreleased materials. > > For example, a user downloading a snapshot release with the unified > compaction strategy in it to test it against their data set and provide > feedback to engineers working on it on the dev ML or dev slack is very much > someone actively participating in the development. It shouldn't just be > contributors or committers actively working on the code who touch it before > it's merged to trunk should it? > > On Thu, Nov 2, 2023, at 10:16 AM, Benedict wrote: > > > My view is that we wait and see what the CI looks like at that time. > > > My reading of ASF policy is that directing users to CEP preview releases > that are not formally voted upon is not acceptable. The policy you quote > indicates they should be intended only for active participants on dev@, > whereas our explicit intention is to enable them to be advertised to users > at the summit. > > > > > On 2 Nov 2023, at 13:27, Josh McKenzie wrote: > > > > I’m not sure we need any additional mechanisms beyond DISCUSS threads, > polls and lazy consensus? > ... > This likely means at least another DISCUSS thread and lazy consensus if > you want to knowingly go against it, or want to modify or clarify what’s > meant. > ... > It can be chucked out or rewoven at zero cost, but if the norms have taken > hold and are broadly understood in the same way, it won’t change much or at > all, because the actual glue is the norm, not the words, which only serve > to broadcast some formulation of the norm. > > 100% agree on all counts. Hopefully this discussion is useful for other > folks as well. > > So - with the clarification that our agreement on green CI represents a > polled majority consensus of the folks participating on the discussion at > the time but not some kind of hard unbendable obligation, is this something > we want to consider relaxing for TCM and Accord? > > This thread ran long (and got detoured - mea culpa) - the tradeoffs seem > like: > >1. We merge them without green CI and cut a cassandra-5.1 branch so we >can release an alpha-1 snapshot from that branch. This likely leaves >cassandra-5.1 and trunk in an unstable place w/regards to CI. TCM/Accord >devs can be expected to be pulled into fixing c
Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)
> Projects MUST direct outsiders towards official releases rather than raw source repositories, nightly builds, snapshots, release candidates, or any other similar packages.Admittedly, “direct” here is ambiguous, but I think the sentiment that users should only be invited to use voted releases is reasonable either way.On 2 Nov 2023, at 15:59, Josh McKenzie wrote:My reading of ASF policy is that directing users to CEP preview releases that are not formally voted upon is not acceptable. The policy you quote indicates they should be intended only for active participants on dev@I disagree with this interpretation; it'd be good to get some clarification as I don't see the narrow requirement of "developers on dev@". This interpretation would actively stifle any project's ability to get early user input and testing on things that are in-development. The primary reason I read it differently (aside from the negative implications) is the following text (emphasis mine):Projects SHOULD make available developer resources to support individuals actively participating in development or following the dev list and thus aware of the conditions placed on unreleased materials.For example, a user downloading a snapshot release with the unified compaction strategy in it to test it against their data set and provide feedback to engineers working on it on the dev ML or dev slack is very much someone actively participating in the development. It shouldn't just be contributors or committers actively working on the code who touch it before it's merged to trunk should it?On Thu, Nov 2, 2023, at 10:16 AM, Benedict wrote:My view is that we wait and see what the CI looks like at that time.My reading of ASF policy is that directing users to CEP preview releases that are not formally voted upon is not acceptable. The policy you quote indicates they should be intended only for active participants on dev@, whereas our explicit intention is to enable them to be advertised to users at the summit.On 2 Nov 2023, at 13:27, Josh McKenzie wrote:I’m not sure we need any additional mechanisms beyond DISCUSS threads, polls and lazy consensus?...This likely means at least another DISCUSS thread and lazy consensus if you want to knowingly go against it, or want to modify or clarify what’s meant. ...It can be chucked out or rewoven at zero cost, but if the norms have taken hold and are broadly understood in the same way, it won’t change much or at all, because the actual glue is the norm, not the words, which only serve to broadcast some formulation of the norm.100% agree on all counts. Hopefully this discussion is useful for other folks as well.So - with the clarification that our agreement on green CI represents a polled majority consensus of the folks participating on the discussion at the time but not some kind of hard unbendable obligation, is this something we want to consider relaxing for TCM and Accord?This thread ran long (and got detoured - mea culpa) - the tradeoffs seem like:We merge them without green CI and cut a cassandra-5.1 branch so we can release an alpha-1 snapshot from that branch. This likely leaves cassandra-5.1 and trunk in an unstable place w/regards to CI. TCM/Accord devs can be expected to be pulled into fixing core issues / finalizing the features and the burden for test stabilization "leaking out" across others in the community who don't have context on their breakage (see: CASSANDRA-8099, cassandra-4.0 release, cassandra-4.1 release, now push for cassandra-5.0 QA stabilization).Push for green CI on Accord / TCM before merge and alpha availability, almost certainly delaying their availability to the community.Cut a preview / snapshot release from the accord feature branch, made available to the dev community. We could automate creation / update of docker images with snapshot releases of all HEAD for trunk and feature branches.Some other approach I'm not thinking of / missedSo as Mick asked earlier in the thread:Is anyone up for looking into adding a "preview" qualifier to our release process? I'm in favor of this. If we cut preview snapshots from trunk and all feature branches periodically (nightly? weekly?), preferably as docker images, this satisfies the desire to get these features into the hands of the dev and user community to test them out and provide feedback to the dev process while also allowing us to keep a high bar for merge to trunk.Referencing the ASF Release Policy: https://www.apache.org/legal/release-policy.html#release-definition, this is consistent with the guidance:During the process of developing software and preparing a release, various packages are made available to the development community for testing purposes. Projects MUST direct outsiders towards official releases rather than raw source repositories, nightly builds, snapshots, release candidates, or any other similar packages. Projects SHOULD make available developer resources to support individuals actively participating in development or foll
