Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?
I have left some comments on the document. Apart from a few clarifications and some minor changes, I feel its in a good shape. I think we should move forward with it. We can refine the process, definitions & criteria as we learn. Dinesh > On Sep 11, 2019, at 11:15 AM, Sumanth Pasupuleti > wrote: > > One more call for any additional comments/ feedback on the release > lifecycle document > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# > > Thanks, > Sumanth > > On Sat, Jul 27, 2019 at 1:01 AM Sumanth Pasupuleti < > sumanth.pasupuleti...@gmail.com> wrote: > >> Submitted patch to add release lifecycle information to the website >> https://issues.apache.org/jira/browse/CASSANDRA-15249 >> >> On Tue, Jun 25, 2019 at 6:57 AM Oleksandr Petrov < >> oleksandr.pet...@gmail.com> wrote: >> >>> Maybe a bit off-topic: >>> >>> Before we cut a release, we should make sure we take care of beta protocol >>> [1], include released driver versions [2] and remove compact storage >>> remainders [3]. Third one is optional, but I'd argue we should do it >>> sooner >>> rather than later. >>> >>> [1] https://issues.apache.org/jira/browse/CASSANDRA-14973 >>> [2] https://issues.apache.org/jira/browse/CASSANDRA-13951 >>> [3] https://issues.apache.org/jira/browse/CASSANDRA-13994 >>> >>> >>> >>> On Sat, Jun 22, 2019 at 1:25 AM Sumanth Pasupuleti < >>> sumanth.pasupuleti...@gmail.com> wrote: >>> Thanks for the feedback Scott. I have incorporated all the incremental feedback I have thus far. Looking for any additional feedback folks may have. >>> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# On Tue, Jun 11, 2019 at 11:54 AM Scott Andreas wrote: > Thanks for starting this discussion, Sumanth! Added a round of >>> comments as > well. > > Summarizing my non-binding feedback: I feel that many of the items >>> under > "Alpha" and "Beta" should be achieved prior to the release of an >>> alpha, > especially those related to correctness/safety, scope lock, feature > completeness, deprecation, and backwards compatibility. Establishing a > higher standard for official project releases (even at the alpha and >>> beta > stage) will help us really polish the final build together. > > Ideally, I feel that contributors should have completed extensive > testing/validation to ensure that no critical or severe bugs exist >>> prior to > the release of an alpha (e.g., data loss, consistency violations, incorrect > responses to queries, etc). Perhaps we can add a line to this effect. > > Ensuring that we've met that bar prior to alpha will help us focus the > final stages of the release on gathering feedback from users + >>> developers > to validate tooling and automation; compatibility with less >>> commonly-used > client libraries, testing new features, evaluating performance and > stability under their workloads, etc. > > – Scott > > On 6/11/19, 6:45 AM, "Sumanth Pasupuleti" < > sumanth.pasupuleti...@gmail.com> wrote: > >Thanks for the feedback on the product stages/ release life cycle > document. >I have incorporated the suggestions and looking for any additional > feedback >folks may have. > > >>> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# > >Thanks, >Sumanth > >On Tue, May 28, 2019 at 10:43 PM Scott Andreas < >>> sc...@paradoxica.net > > wrote: > >> Echoing Jon’s point here – >> >> JH: “My thinking is I'd like to be able to recommend 4.0.0 as a > production >> ready >> database for business critical cases” >> >> I feel that this is a standard that is both appropriate and > achievable, >> and one I’m legitimately excited about. >> >> Re: the current state of the test plan wiki in Confluence, I owe > another >> pass through. There has been a lot of progress here, but I’ve >>> let > perfect >> be the enemy of the good in getting updates out. I’ll complete >>> that > pass >> later this week. >> >> Cheers, >> >> — Scott >> >>> On May 28, 2019, at 10:48 AM, Dinesh Joshi >>> > wrote: >>> >>> +1. Wiki could be useful to document what the overall plan. >>> Jira to >> track progress. >>> >>> Dinesh >>> > On May 28, 2019, at 10:20 AM, Joshua McKenzie < > jmcken...@apache.org> >> wrote: > > > The unofficial rule is to not upgrade to prod till .10 is >>> cut. FWIW, I believe it's historically .6. Which is still not a >>> great > look >> for the project. There's a ton of work going into testing 4.0 already. Wh
Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?
Is it common to have such strict release criteria from RC to GA... Release Candidate (RC) - Thorough testing is performed, and if no bugs are found within a testing period of one month, release is promoted to GA. - If bugs are found, fixes are made and above step is repeated That seems overly tough criteria (no bugs for a month?). Maybe this needs to be clarified to state the severity of bug in which a promotion will not happen, and the clock will start over? Or am I misinterpretting. Otherwise, yes, this is something I can get onboard with. Thanks! On Wed, Sep 11, 2019, 11:16 AM Sumanth Pasupuleti < sumanth.pasupuleti...@gmail.com> wrote: > One more call for any additional comments/ feedback on the release > lifecycle document > > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# > > Thanks, > Sumanth > > On Sat, Jul 27, 2019 at 1:01 AM Sumanth Pasupuleti < > sumanth.pasupuleti...@gmail.com> wrote: > > > Submitted patch to add release lifecycle information to the website > > https://issues.apache.org/jira/browse/CASSANDRA-15249 > > > > On Tue, Jun 25, 2019 at 6:57 AM Oleksandr Petrov < > > oleksandr.pet...@gmail.com> wrote: > > > >> Maybe a bit off-topic: > >> > >> Before we cut a release, we should make sure we take care of beta > protocol > >> [1], include released driver versions [2] and remove compact storage > >> remainders [3]. Third one is optional, but I'd argue we should do it > >> sooner > >> rather than later. > >> > >> [1] https://issues.apache.org/jira/browse/CASSANDRA-14973 > >> [2] https://issues.apache.org/jira/browse/CASSANDRA-13951 > >> [3] https://issues.apache.org/jira/browse/CASSANDRA-13994 > >> > >> > >> > >> On Sat, Jun 22, 2019 at 1:25 AM Sumanth Pasupuleti < > >> sumanth.pasupuleti...@gmail.com> wrote: > >> > >> > Thanks for the feedback Scott. I have incorporated all the incremental > >> > feedback I have thus far. > >> > > >> > Looking for any additional feedback folks may have. > >> > > >> > > >> > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# > >> > > >> > On Tue, Jun 11, 2019 at 11:54 AM Scott Andreas > >> > wrote: > >> > > >> > > Thanks for starting this discussion, Sumanth! Added a round of > >> comments > >> > as > >> > > well. > >> > > > >> > > Summarizing my non-binding feedback: I feel that many of the items > >> under > >> > > "Alpha" and "Beta" should be achieved prior to the release of an > >> alpha, > >> > > especially those related to correctness/safety, scope lock, feature > >> > > completeness, deprecation, and backwards compatibility. > Establishing a > >> > > higher standard for official project releases (even at the alpha and > >> beta > >> > > stage) will help us really polish the final build together. > >> > > > >> > > Ideally, I feel that contributors should have completed extensive > >> > > testing/validation to ensure that no critical or severe bugs exist > >> prior > >> > to > >> > > the release of an alpha (e.g., data loss, consistency violations, > >> > incorrect > >> > > responses to queries, etc). Perhaps we can add a line to this > effect. > >> > > > >> > > Ensuring that we've met that bar prior to alpha will help us focus > the > >> > > final stages of the release on gathering feedback from users + > >> developers > >> > > to validate tooling and automation; compatibility with less > >> commonly-used > >> > > client libraries, testing new features, evaluating performance and > >> > > stability under their workloads, etc. > >> > > > >> > > – Scott > >> > > > >> > > On 6/11/19, 6:45 AM, "Sumanth Pasupuleti" < > >> > > sumanth.pasupuleti...@gmail.com> wrote: > >> > > > >> > > Thanks for the feedback on the product stages/ release life > cycle > >> > > document. > >> > > I have incorporated the suggestions and looking for any > additional > >> > > feedback > >> > > folks may have. > >> > > > >> > > > >> > > >> > https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# > >> > > > >> > > Thanks, > >> > > Sumanth > >> > > > >> > > On Tue, May 28, 2019 at 10:43 PM Scott Andreas < > >> sc...@paradoxica.net > >> > > > >> > > wrote: > >> > > > >> > > > Echoing Jon’s point here – > >> > > > > >> > > > JH: “My thinking is I'd like to be able to recommend 4.0.0 as > a > >> > > production > >> > > > ready > >> > > > database for business critical cases” > >> > > > > >> > > > I feel that this is a standard that is both appropriate and > >> > > achievable, > >> > > > and one I’m legitimately excited about. > >> > > > > >> > > > Re: the current state of the test plan wiki in Confluence, I > owe > >> > > another > >> > > > pass through. There has been a lot of progress here, but I’ve > >> let > >> > > perfect > >> > > > be the enemy of the good in getting updates out. I’ll complete > >> that > >> > > pass > >> > > > later this week. > >> > > > > >> > > > C
Attention to serious bug CASSANDRA-15081
Have had multiple customer hit this CASSANDRA-15081 issue now, where upgrading from older versions the sstables contain an unknown column (its not present in the dropped_columns in the schema) This bug is serious as reads return incorrect results and if you run scrub it will drop the row. So hoping to bring it some attention to have the issue resolved. Note I have included a patch that I think does not cause any regressions elsewhere. Regards, Cameron
Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?
One more call for any additional comments/ feedback on the release lifecycle document https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# Thanks, Sumanth On Sat, Jul 27, 2019 at 1:01 AM Sumanth Pasupuleti < sumanth.pasupuleti...@gmail.com> wrote: > Submitted patch to add release lifecycle information to the website > https://issues.apache.org/jira/browse/CASSANDRA-15249 > > On Tue, Jun 25, 2019 at 6:57 AM Oleksandr Petrov < > oleksandr.pet...@gmail.com> wrote: > >> Maybe a bit off-topic: >> >> Before we cut a release, we should make sure we take care of beta protocol >> [1], include released driver versions [2] and remove compact storage >> remainders [3]. Third one is optional, but I'd argue we should do it >> sooner >> rather than later. >> >> [1] https://issues.apache.org/jira/browse/CASSANDRA-14973 >> [2] https://issues.apache.org/jira/browse/CASSANDRA-13951 >> [3] https://issues.apache.org/jira/browse/CASSANDRA-13994 >> >> >> >> On Sat, Jun 22, 2019 at 1:25 AM Sumanth Pasupuleti < >> sumanth.pasupuleti...@gmail.com> wrote: >> >> > Thanks for the feedback Scott. I have incorporated all the incremental >> > feedback I have thus far. >> > >> > Looking for any additional feedback folks may have. >> > >> > >> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# >> > >> > On Tue, Jun 11, 2019 at 11:54 AM Scott Andreas >> > wrote: >> > >> > > Thanks for starting this discussion, Sumanth! Added a round of >> comments >> > as >> > > well. >> > > >> > > Summarizing my non-binding feedback: I feel that many of the items >> under >> > > "Alpha" and "Beta" should be achieved prior to the release of an >> alpha, >> > > especially those related to correctness/safety, scope lock, feature >> > > completeness, deprecation, and backwards compatibility. Establishing a >> > > higher standard for official project releases (even at the alpha and >> beta >> > > stage) will help us really polish the final build together. >> > > >> > > Ideally, I feel that contributors should have completed extensive >> > > testing/validation to ensure that no critical or severe bugs exist >> prior >> > to >> > > the release of an alpha (e.g., data loss, consistency violations, >> > incorrect >> > > responses to queries, etc). Perhaps we can add a line to this effect. >> > > >> > > Ensuring that we've met that bar prior to alpha will help us focus the >> > > final stages of the release on gathering feedback from users + >> developers >> > > to validate tooling and automation; compatibility with less >> commonly-used >> > > client libraries, testing new features, evaluating performance and >> > > stability under their workloads, etc. >> > > >> > > – Scott >> > > >> > > On 6/11/19, 6:45 AM, "Sumanth Pasupuleti" < >> > > sumanth.pasupuleti...@gmail.com> wrote: >> > > >> > > Thanks for the feedback on the product stages/ release life cycle >> > > document. >> > > I have incorporated the suggestions and looking for any additional >> > > feedback >> > > folks may have. >> > > >> > > >> > >> https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit# >> > > >> > > Thanks, >> > > Sumanth >> > > >> > > On Tue, May 28, 2019 at 10:43 PM Scott Andreas < >> sc...@paradoxica.net >> > > >> > > wrote: >> > > >> > > > Echoing Jon’s point here – >> > > > >> > > > JH: “My thinking is I'd like to be able to recommend 4.0.0 as a >> > > production >> > > > ready >> > > > database for business critical cases” >> > > > >> > > > I feel that this is a standard that is both appropriate and >> > > achievable, >> > > > and one I’m legitimately excited about. >> > > > >> > > > Re: the current state of the test plan wiki in Confluence, I owe >> > > another >> > > > pass through. There has been a lot of progress here, but I’ve >> let >> > > perfect >> > > > be the enemy of the good in getting updates out. I’ll complete >> that >> > > pass >> > > > later this week. >> > > > >> > > > Cheers, >> > > > >> > > > — Scott >> > > > >> > > > > On May 28, 2019, at 10:48 AM, Dinesh Joshi > > >> > > wrote: >> > > > > >> > > > > +1. Wiki could be useful to document what the overall plan. >> Jira >> > to >> > > > track progress. >> > > > > >> > > > > Dinesh >> > > > > >> > > > >>> On May 28, 2019, at 10:20 AM, Joshua McKenzie < >> > > jmcken...@apache.org> >> > > > wrote: >> > > > >>> >> > > > >>> >> > > > >>> The unofficial rule is to not upgrade to prod till .10 is >> cut. >> > > > >> >> > > > >> FWIW, I believe it's historically .6. Which is still not a >> great >> > > look >> > > > for >> > > > >> the project. >> > > > >> >> > > > >> There's a ton of work going into testing 4.0 already. >> > > > >> >> > > > >> While I intuitively and anecdotally (from the people I've >> > > backchanneled >> > > > >> with) believ
