Here is my 2 cents. Maybe we need to differentiate the user-facing improvements and ecosystem-internal improvements, or have a discussion about it. I guess when the current policy of "improvements and new features on trunk only" was made, it was to target the user-facing improvements. The internal changes are not exposed to cassandra users directly. As Josh pointed out, with more projects (sidecar and analytics have dependency on cassandra public interface) in the ecosystem, we are more likely to encounter the scenarios where we want to modify the mainline branches for integration purposes.
The downside of preventing the integration updates to the older branches is having different solutions per Cassandra version in the other projects under the Cassandra umbrella. It is a maintenance pain and potentially causes errors. It is my original motivation of backporting the patch to the other branches. - Yifan On Tue, Jul 30, 2024 at 6:04 AM Josh McKenzie <jmcken...@apache.org> wrote: > Some thoughts: > > 1. Most of our PMC votes are majority-based, not binding -1. So Jeff > being -1 doesn't mean the whole PMC being -1. So don't take his -1 as being > a show stopper or indicative of everyone on the PMC (and don't take me > saying this as the converse ;)) > 2. I expect we have a lot of debt when it comes to our ecosystem > integrations on older branches. Bringing those projects into the ASF > umbrella and into the project ecosystem is at odds with a hard policy of > "we don't add improvements or new features to old branches", > *specifically* in cases like this where the desire is to get uniform > support for ecosystem projects across all supported branches of C* > 3. We're moving into a world where we will likely more frequently > modify the mainline branch with new functionality to integrate with > ecosystem changes (sidecar, analytics, drivers?). It's probably at least > worth a conversation as to whether our current policy (improvements and new > features main branch only) is optimal across everything equally or if there > should be nuance for ecosystem integrations. > 4. To Jeff's point: everyone is always going to have some minor > improvement they'd like to back-port to older branches. > > I haven't thought deeply enough about this specific situation to have a > well formed opinion, but figured calling out the above things is worth > doing. This probably won't be the last time we look at our supported > branches and have some pain we'd like to address based on the inconsistent > ecosystem support and API piece across them. > > On Mon, Jul 29, 2024, at 1:32 PM, Yifan Cai wrote: > > It sounds like we are all good with backporting to 5.0. > > Thank you all for the feedback. > > - Yifan > > On Fri, Jul 26, 2024 at 12:21 PM Jeff Jirsa <jji...@gmail.com> wrote: > > > > > On Jul 26, 2024, at 11:09 AM, Yifan Cai <yc25c...@gmail.com> wrote: > > > Thanks Jeff for restating the policy. > > According to the release lifecycle doc > > > - Missing features from newer generation releases are back-ported on > per - PMC vote basis. > > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle > > We do not have a policy to prevent new features strictly for the branches > in maintenance state. > > IMO, the patch qualifies as the missing feature. (As said, it is useful > for Cassandra Analytics, and it is good to have the same bridge > implementation amongst different cassandra versions) > > Therefore, I would like to call for a vote. > > > Sure > > I’m -1 on 4.0 and 4.1 > > - Jeff > > > On Fri, Jul 26, 2024 at 10:25 AM Jeff Jirsa <jji...@gmail.com> wrote: > > Everyone has a low risk change they want to backport to every branch, 4.0 > and 4.1 in particular are way past the point we should be adding features > > The policy exists and it’s a pure feature not a regression > > > > > > > On Jul 26, 2024, at 9:59 AM, Brandon Williams <dri...@gmail.com> wrote: > > > > Given how low risk this is, I don't see an issue with backporting it > > and I'm sure the usefulness outweighs what risk there is. +1 (5.0.1 > > though, not 5.0.0) > > > > Kind Regards, > > Brandon > > > >> On Fri, Jul 26, 2024 at 11:52 AM Yifan Cai <yc25c...@gmail.com> wrote: > >> > >> Hi everyone, > >> > >> CASSANDRA-19800 is currently in the state of ready to be committed. > Before that, I want to propose backporting it to 4.0, 4.1 and 5.0. > >> > >> The ability to notify CQLSSTableWriter user when new sstables are > produced is especially useful for Cassandra Analytics and other consumers. > The API is more reliable than monitoring the file directory. > >> > >> That being said, I am aware that the patch is an improvement and trunk > only. I want to ask for an exemption on backporting the patch for two > reasons. It is useful for Cassandra Analytics. The patch is low risk for > Cassandra server as it only touches CQLSSTableWriter, which is only used by > toolings. > >> > >> - Yifan > > >
