Sorry, I realised that I hadn't included any completion date for CEP-7. At the current time we are looking at completion mid to end of April.
Mike On Mon, 13 Mar 2023 at 11:34, Mike Adamson <madam...@datastax.com> wrote: > 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> > > -- [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>
