CEP-7 Storage Attached Index is in review with ~430 files and ~70k LOC. The bulk of the project is in 3 main patches. The first patch (in-memory index and query path) is merged to the feature branch CASSANDRA-16052 and the second patch (on-disk write and literal / string index) is in review.
Mike On Thu, 9 Mar 2023 at 09:13, Branimir Lambov <blam...@apache.org> wrote: > CEPs 25 (trie-indexed sstables) and 26 (unified compaction strategy) > should both be ready for review by mid-April. > > Both are around 10k LOC, fairly isolated, and in need of a committer to > review. > > Regards, > Branimir > > On Mon, Mar 6, 2023 at 11:25 AM Benjamin Lerer <b.le...@gmail.com> wrote: > >> Sorry, I realized that when I started the discussion I probably did not >> frame it enough as I see that it is now going into different directions. >> The concerns I am seeing are: >> 1) A too small amount of time between releases is inefficient from a >> development perspective and from a user perspective. From a development >> point of view because we are missing time to deliver some features. From a >> user perspective because they cannot follow with the upgrade. >> 2) Some features are so anticipated (Accord being the one mentioned) that >> people would prefer to delay the release to make sure that it is available >> as soon as possible. >> 3) We do not know how long we need to go from the freeze to GA. We hope >> for 2 months but our last experience was 6 months. So delaying the release >> could mean not releasing this year. >> 4) For people doing marketing it is really hard to promote a product when >> you do not know when the release will come and what features might be there. >> >> All those concerns are probably even made worse by the fact that we do >> not have a clear visibility on where we are. >> >> Should we clarify that part first by getting an idea of the status of the >> different CEPs and other big pieces of work? From there we could agree on >> some timeline for the freeze. We could then discuss how to make predictable >> the time from freeze to GA. >> >> >> >> Le sam. 4 mars 2023 à 18:14, Josh McKenzie <jmcken...@apache.org> a >> écrit : >> >>> (for convenience sake, I'm referring to both Major and Minor semver >>> releases as "major" in this email) >>> >>> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I >>> would advocate to delay until this has sufficient quality to be in >>> production. >>> >>> This approach can be pretty unpredictable in this domain; often >>> unforeseen things come up in implementation that can give you a long tail >>> on something being production ready. For the record - I don't intend to >>> single Accord out *at all* on this front, quite the opposite given how >>> much rigor's gone into the design and implementation. I'm just thinking >>> from my personal experience: everything I've worked on, overseen, or >>> followed closely on this codebase always has a few tricks up its sleeve >>> along the way to having edge-cases stabilized. >>> >>> Much like on some other recent topics, I think there's a nuanced middle >>> ground where we take things on a case-by-case basis. Some factors that have >>> come up in this thread that resonated with me: >>> >>> For a given potential release date 'X': >>> 1. How long has it been since the last release? >>> 2. How long do we expect qualification to take from a "freeze" (i.e. no >>> new improvement or features, branch) point? >>> 3. What body of merged production ready work is available? >>> 4. What body of new work do we have high confidence will be ready within >>> Y time? >>> >>> I think it's worth defining a loose "minimum bound and upper bound" on >>> release cycles we want to try and stick with barring extenuating >>> circumstances. For instance: try not to release sooner than maybe 10 months >>> out from a prior major, and try not to release later than 18 months out >>> from a prior major. Make exceptions if truly exceptional things land, are >>> about to land, or bugs are discovered around those boundaries. >>> >>> Applying the above framework to what we have in flight, our last release >>> date, expectations on CI, etc - targeting an early fall freeze (pending CEP >>> status) and mid to late fall or December release "feels right" to me. >>> >>> With the exception, of course, that if something merges earlier, is >>> stable, and we feel is valuable enough to cut a major based on that, we do >>> it. >>> >>> ~Josh >>> >>> On Fri, Mar 3, 2023, at 7:37 PM, German Eichberger via dev wrote: >>> >>> Hi, >>> >>> We shouldn't release just for releases sake. Are there enough new >>> features and are they working well enough (quality!). >>> >>> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I >>> would advocate to delay until this has sufficient quality to be in >>> production. >>> >>> Just because something is released doesn't mean anyone is gonna use it. >>> To add some operator perspective: Every time there is a new release we need >>> to decide >>> 1) are we supporting it >>> 2) which other release can we deprecate >>> >>> and potentially migrate people - which is also a tough sell if there are >>> no significant features and/or breaking changes. So from my perspective >>> less frequent releases are better - after all we haven't gotten around to >>> support 4.1 🙂 >>> >>> The 5.0 release is also coupled with deprecating 3.11 which is what a >>> significant amount of people are using - given 4.1 took longer I am not >>> sure how many people are assuming that 5 will be delayed and haven't made >>> plans (OpenJDK support for 8 is longer than Java 17 🙂) . So being a >>> bit more deliberate with releasing 5.0 and having a longer beta phase are >>> all things we should consider. >>> >>> My 2cts, >>> German >>> >>> *From:* Benedict <bened...@apache.org> >>> *Sent:* Wednesday, March 1, 2023 5:59 AM >>> *To:* dev@cassandra.apache.org <dev@cassandra.apache.org> >>> *Subject:* [EXTERNAL] Re: [DISCUSS] Next release date >>> >>> >>> It doesn’t look like we agreed to a policy of annual branch dates, only >>> annual releases and that we would schedule this for 4.1 based on 4.0’s >>> branch date. Given this was the reasoning proposed I can see why folk would >>> expect this would happen for the next release. I don’t think there was a >>> strong enough commitment here to be bound by, it if we think different >>> maths would work better. >>> >>> I recall the goal for an annual cadence was to ensure we don’t have >>> lengthy periods between releases like 3.x to 4.0, and to try to reduce the >>> pressure certain contributors might feel to hit a specific release with a >>> given feature. >>> >>> I think it’s better to revisit these underlying reasons and check how >>> they apply than to pick a mechanism and stick to it too closely. >>> >>> The last release was quite recent, so we aren’t at risk of slow releases >>> here. Similarly, there are some features that the *project* would probably >>> benefit from landing prior to release, if this doesn’t push release back >>> too far. >>> >>> >>> >>> >>> >>> On 1 Mar 2023, at 13:38, Mick Semb Wever <m...@apache.org> wrote: >>> >>> >>> >>> My thoughts don't touch on CEPs inflight. >>> >>> >>> >>> >>> For the sake of broadening the discussion, additional questions I think >>> worthwhile to raise are… >>> >>> 1. What third parties, or other initiatives, are invested and/or >>> working against the May deadline? and what are their views on changing it? >>> 1a. If we push branching back to September, how confident are we that >>> we'll get to GA before the December Summit? >>> 2. What CEPs look like not landing by May that we consider a must-have >>> this year? >>> 2a. Is it just tail-end commits in those CEPs that won't make it? Can >>> these land (with or without a waiver) during the alpha phase? >>> 2b. If the final components to specified CEPs are not >>> approved/appropriate to land during alpha, would it be better if the >>> project commits to a one-off half-year release later in the year? >>> >>> >>> -- [image: DataStax Logo Square] <https://www.datastax.com/> *Mike Adamson* Engineering +1 650 389 6000 <16503896000> | datastax.com <https://www.datastax.com/> Find DataStax Online: [image: LinkedIn Logo] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=akx0E6l2bnTjOvA-YxtonbW0M4b6bNg4nRwmcHNDo4Q&e=> [image: Facebook Logo] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_datastax&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=uHzE4WhPViSF0rsjSxKhfwGDU1Bo7USObSc_aIcgelo&s=ncMlB41-6hHuqx-EhnM83-KVtjMegQ9c2l2zDzHAxiU&e=> [image: Twitter Logo] <https://twitter.com/DataStax> [image: RSS Feed] <https://www.datastax.com/blog/rss.xml> [image: Github Logo] <https://github.com/datastax>
