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
