Re: [DISCUSS] CASSANDRA-13994
Where did we land on inclusion of this ticket in 4.0? Since it's now flagged as blocking beta rel, I am now very interested in this question. :) On Wed, May 27, 2020 at 7:52 PM Jordan West wrote: > On Wed, May 27, 2020 at 1:23 PM Joshua McKenzie > wrote: > > > Maybe. Do we just time box, say we're going to cut an RC and give it 4 > > weeks, if nothing awful surfaces we GA? > > > > I've seen that work well in the past on other projects. I agree with the > notion that RCs are real candidates for release if no one finds issues with > them. Ideally we would have as little RCs as possible and have more > alphas/betas. > > > > > On Wed, May 27, 2020 at 4:12 PM Brandon Williams > wrote: > > > > > Absolutely my understanding. > > > > > > On Wed, May 27, 2020, 2:49 PM Jeremiah D Jordan < > > jeremiah.jor...@gmail.com > > > > > > > wrote: > > > > > > > > A clear point to cut RC's doesn't surface from the above for me. > > > > Releasing > > > > > an RC before broad verification seems wrong, and cutting an RC > after > > > the > > > > 4 > > > > > points above may as well be GA because it's all known scope. > > > > > > > > Isn’t the whole point of an RC is that it could be the GA? It is a > > > > “release candidate”, meaning if no one finds any issues with it, that > > can > > > > them become the release? So that seems like exactly the right time > to > > > make > > > > RC releases? > > > > > > > > > On May 27, 2020, at 2:45 PM, Joshua McKenzie > > > > > wrote: > > > > > > > > > > I think we're all on the same page here; I was focusing more on the > > > > release > > > > > lifecycles and sequencing than the entire version cycle. Good to > > > broaden > > > > > scope I think. > > > > > > > > > > One thing we're not considering is the separation of API changes > from > > > > major > > > > > changes and how that intersects with release milestones. > > > > > > > > > > Meaning: > > > > > 1. alpha phase > > > > > 2. Milestone: API freeze (all API changes pushed to next major) > > > > > 3. beta phase > > > > > 4. Verification phase (all major disruptive pushed to next major) > > > > > > > > > > A clear point to cut RC's doesn't surface from the above for me. > > > > Releasing > > > > > an RC before broad verification seems wrong, and cutting an RC > after > > > the > > > > 4 > > > > > points above may as well be GA because it's all known scope. > > > > > > > > > > Thoughts? > > > > > > > > > > On Wed, May 27, 2020 at 3:28 PM Scott Andreas < > sc...@paradoxica.net> > > > > wrote: > > > > > > > > > >> That makes sense to me, yep. > > > > >> > > > > >> My hope and expectation is that the time required for > "verification > > > > work" > > > > >> will shrink dramatically in the not too distant future - ideally > to > > a > > > > >> period of less than a month. In this world, the cost of missing > one > > > > train > > > > >> is reduced to catching the next one. > > > > >> > > > > >> One of the main goals in shifting focus from "testing" and "test > > > plans" > > > > to > > > > >> "test engineering" is automating as many aspects of release > > > > qualification > > > > >> as possible, with an asymptotic ideal as a function of compute > > > capacity > > > > and > > > > >> time. While such automation will never be complete (it's likely > that > > > > >> development of new features will/must include qualification infra > > > > changes > > > > >> to exercise them), if we're able to apply the same rigor to major > > > > releases > > > > >> as we are to patchlevel builds with little incremental effort, I'd > > be > > > > >> thrilled. > > > > >> > > > > >> This is mostly a way of saying: > > > > >> – I like the cadence/sequencing Benedict proposes below. > > > > >> – I think improvements in test engineering can reduce/eliminate > > > > >> invalidation and may increase the scope of what can be a candidate > > for > > > > >> merge on a given branch > > > > >> – And if not, the cost of missing the train is lower because we'll > > be > > > > able > > > > >> to deliver major releases more often. > > > > >> > > > > >> Scott > > > > >> > > > > >> > > > > >> From: Jeremiah D Jordan > > > > >> Sent: Wednesday, May 27, 2020 11:54 AM > > > > >> To: Cassandra DEV > > > > >> Subject: Re: [DISCUSS] CASSANDRA-13994 > > > > >> > > > > >> +1 strongly agree. If we aren’t going to let something go into > > 4.0.0 > > > > >> because it would "invalidate testing” then we can not let such a > > thing > > > > go > > > > >> into 4.0.1 unless we plan to re-do said testing for the patch > > release. > > > > >> > > > > >>> On May 27, 2020, at 1:31 PM, Benedict Elliott Smith < > > > > bened...@apache.org> > > > > >> wrote: > > > > >>> > > > > >>> I'm being told this still isn't clear, so let me try in a > > > bullet-point > > > > >> timeline: > > > > >>> > > > > >>> * 4.0 Beta > > > > >>> * 4.0 Verification Work > > > > >>> * [Merge Window] > > > > >>> * 4.0 GA > > > > >>> * 4.0 Minor Releases > > > > >>> * ... >
Re: [DISCUSS] CASSANDRA-13994
It was moved to alpha following the lifecycle document and the latest discussion on the ML. Sylvain made a review yesterday. To me the biggest question is about the indexing. (Posted questions on the ticket itself, waiting for opinion and agreement) For the rest of the ticket I support Sylvain that it is primarily removal of dead code. My understanding is either it lands in alpha before the big testing in beta or it is delayed for v.5 Ekaterina On Wed, 10 Jun 2020 at 12:59, Joshua McKenzie wrote: > Where did we land on inclusion of this ticket in 4.0? Since it's now > flagged as blocking beta rel, I am now very interested in this question. > > :) > > > On Wed, May 27, 2020 at 7:52 PM Jordan West wrote: > > > On Wed, May 27, 2020 at 1:23 PM Joshua McKenzie > > wrote: > > > > > Maybe. Do we just time box, say we're going to cut an RC and give it 4 > > > weeks, if nothing awful surfaces we GA? > > > > > > > I've seen that work well in the past on other projects. I agree with the > > notion that RCs are real candidates for release if no one finds issues > with > > them. Ideally we would have as little RCs as possible and have more > > alphas/betas. > > > > > > > > On Wed, May 27, 2020 at 4:12 PM Brandon Williams > > wrote: > > > > > > > Absolutely my understanding. > > > > > > > > On Wed, May 27, 2020, 2:49 PM Jeremiah D Jordan < > > > jeremiah.jor...@gmail.com > > > > > > > > > wrote: > > > > > > > > > > A clear point to cut RC's doesn't surface from the above for me. > > > > > Releasing > > > > > > an RC before broad verification seems wrong, and cutting an RC > > after > > > > the > > > > > 4 > > > > > > points above may as well be GA because it's all known scope. > > > > > > > > > > Isn’t the whole point of an RC is that it could be the GA? It is a > > > > > “release candidate”, meaning if no one finds any issues with it, > that > > > can > > > > > them become the release? So that seems like exactly the right time > > to > > > > make > > > > > RC releases? > > > > > > > > > > > On May 27, 2020, at 2:45 PM, Joshua McKenzie < > jmcken...@apache.org > > > > > > > > wrote: > > > > > > > > > > > > I think we're all on the same page here; I was focusing more on > the > > > > > release > > > > > > lifecycles and sequencing than the entire version cycle. Good to > > > > broaden > > > > > > scope I think. > > > > > > > > > > > > One thing we're not considering is the separation of API changes > > from > > > > > major > > > > > > changes and how that intersects with release milestones. > > > > > > > > > > > > Meaning: > > > > > > 1. alpha phase > > > > > > 2. Milestone: API freeze (all API changes pushed to next major) > > > > > > 3. beta phase > > > > > > 4. Verification phase (all major disruptive pushed to next major) > > > > > > > > > > > > A clear point to cut RC's doesn't surface from the above for me. > > > > > Releasing > > > > > > an RC before broad verification seems wrong, and cutting an RC > > after > > > > the > > > > > 4 > > > > > > points above may as well be GA because it's all known scope. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > On Wed, May 27, 2020 at 3:28 PM Scott Andreas < > > sc...@paradoxica.net> > > > > > wrote: > > > > > > > > > > > >> That makes sense to me, yep. > > > > > >> > > > > > >> My hope and expectation is that the time required for > > "verification > > > > > work" > > > > > >> will shrink dramatically in the not too distant future - ideally > > to > > > a > > > > > >> period of less than a month. In this world, the cost of missing > > one > > > > > train > > > > > >> is reduced to catching the next one. > > > > > >> > > > > > >> One of the main goals in shifting focus from "testing" and "test > > > > plans" > > > > > to > > > > > >> "test engineering" is automating as many aspects of release > > > > > qualification > > > > > >> as possible, with an asymptotic ideal as a function of compute > > > > capacity > > > > > and > > > > > >> time. While such automation will never be complete (it's likely > > that > > > > > >> development of new features will/must include qualification > infra > > > > > changes > > > > > >> to exercise them), if we're able to apply the same rigor to > major > > > > > releases > > > > > >> as we are to patchlevel builds with little incremental effort, > I'd > > > be > > > > > >> thrilled. > > > > > >> > > > > > >> This is mostly a way of saying: > > > > > >> – I like the cadence/sequencing Benedict proposes below. > > > > > >> – I think improvements in test engineering can reduce/eliminate > > > > > >> invalidation and may increase the scope of what can be a > candidate > > > for > > > > > >> merge on a given branch > > > > > >> – And if not, the cost of missing the train is lower because > we'll > > > be > > > > > able > > > > > >> to deliver major releases more often. > > > > > >> > > > > > >> Scott > > > > > >> > > > > > >> > > > > > >> From: Jeremiah D Jordan > > > > > >> Sent: Wednesd
Re: [DISCUSS] governance on the Apache Cassandra project
On Mon, Jun 8, 2020 at 3:12 AM Mick Semb Wever wrote: > > > With regards to CEPs, I personally don't see any value in voting to > start > > one. > > > > Agree with this, and I'd go even further - requiring a vote in order to > > propose an idea runs so counter to the idea of a CEP that it would > default > > the purpose of even having them. The CEP is the _proposal_ for a change > > that gets fleshed out enough so people can understand the idea and _then_ > > vote on it, not the other way around. > > > Totally agree that CEPs should be as light-weight as possible, and with the > sentiments above. But would also like to keep the discussion open to > encourage and include as many voices as possible. > > My _questioning_ is around the value in "initial exposure and discussion". > It is implied already that there is lazy consensus in starting a CEP, and > that starting a CEP is more than just an initial proposal of an idea. One > example is we require a CEP to have a Shepherd that is a PMC member. > Encouraging a vote, or better-yet keeping it light-weight: an initial > DISCUSS thread as early as possible in the CEP lifecycle does come with > value. From openly calling out for a Shepherd, to allowing the more > experienced community members to add their insight (without having to get > formally involved in it), there's potential value in encouraging such > open-mode opening discussion early on (versus the cost of additional > process). > > Really interested in hearing from folk from other communities and projects > that do CEP/CIP and how their lifecycle through the process works and what > they have learnt. > Here is a description of the process Swift Programming Language uses - https://github.com/apple/swift-evolution/blob/master/process.md.
Proof of concept for Cassandra docs conversion
Hello all! Based on an earlier discussion about moving the OSS C* docs to asciidoc, to allow more flexibility in maintaining the docs, I've done a proof of concept about what it would take to accomplish a conversion. I converted rSt files to asciidoc files using pandoc, did some additional editing, and use antora (antora.org) as a static site generator to build the docs. The result is here: https://polandll.github.io/site/ASCIIDOC_POC/4.0/cassandra/getting_started/configuring.html#changing-the-location-of-directoriesThe editing of the docs is NOT complete, but I completed enough to feel confident that this process can be accomplished. Some YAML configuration for antora was required, and I did a minimum of UI configuration (added color banner, logo). Looking for feedback and questions anyone may have. Thanks, Lorina Poland (DataStax tech writer)
Re: [DISCUSS] governance on the Apache Cassandra project
Thanks for that insight Pavel. Will be a helpful and useful reference as we start to test out our CEP process after 4.0 solidifies. One thing that really stood out to me worth calling out: > > > >- Engage the wider Swift community in the ongoing evolution of Swift, >and > > >- Maintain the vision and conceptual coherence of Swift. > > There is a natural tension between these two goals. Open evolution > processes are, by nature, chaotic. Yet, maintaining a coherent vision for > something as complicated as a programming language requires some level of > coordination. The Swift evolution process aims to strike a balance that > best serves the Swift community as a whole. I'd love us to follow up on that topic (future vision, coherence, etc) on the project after we iron out our voting and governance process. So that being said - there's no further feedback on the doc in its current form. Anybody else have any thoughts on where things stand? On Wed, Jun 10, 2020 at 1:55 PM Pavel Yaskevich wrote: > On Mon, Jun 8, 2020 at 3:12 AM Mick Semb Wever wrote: > > > > > With regards to CEPs, I personally don't see any value in voting to > > start > > > one. > > > > > > Agree with this, and I'd go even further - requiring a vote in order to > > > propose an idea runs so counter to the idea of a CEP that it would > > default > > > the purpose of even having them. The CEP is the _proposal_ for a > change > > > that gets fleshed out enough so people can understand the idea and > _then_ > > > vote on it, not the other way around. > > > > > > Totally agree that CEPs should be as light-weight as possible, and with > the > > sentiments above. But would also like to keep the discussion open to > > encourage and include as many voices as possible. > > > > My _questioning_ is around the value in "initial exposure and > discussion". > > It is implied already that there is lazy consensus in starting a CEP, and > > that starting a CEP is more than just an initial proposal of an idea. One > > example is we require a CEP to have a Shepherd that is a PMC member. > > Encouraging a vote, or better-yet keeping it light-weight: an initial > > DISCUSS thread as early as possible in the CEP lifecycle does come with > > value. From openly calling out for a Shepherd, to allowing the more > > experienced community members to add their insight (without having to get > > formally involved in it), there's potential value in encouraging such > > open-mode opening discussion early on (versus the cost of additional > > process). > > > > Really interested in hearing from folk from other communities and > projects > > that do CEP/CIP and how their lifecycle through the process works and > what > > they have learnt. > > > > Here is a description of the process Swift Programming Language uses - > https://github.com/apple/swift-evolution/blob/master/process.md. >
Regarding JIRA Cassandra-14227
Hi Team We are not able to insert data with large TTLs (expiration time beyond 2038-01-19T03:14:06+00:00). Even though https://jira.apache.org/jira/browse/CASSANDRA-14092 prevented a workaround to avoid data loss, the permanent fix is still pending. I can see that the JIRA: https://jira.apache.org/jira/browse/CASSANDRA-14227 which was open for permanent fix is still in unassigned state. I think it’s a high priority issue as the timestamp limit is continuously reducing as we approach 2038. Are there any plans to prioritize this JIRA ticket : https://jira.apache.org/jira/browse/CASSANDRA-14227 Regards Manish
