Re: [VOTE] Release Apache Cassandra 4.0-beta1
-1 Sorry, I dropped the ball on https://issues.apache.org/jira/browse/CASSANDRA-15375 It's ready to commit, if somebody can give it a quick +1, and would be prohibited after first beta. On 16/07/2020, 21:16, "Sumanth Pasupuleti" wrote: +1 nb Ran following CircleCI tests j8_unit_tests (PASS) j8_jvm_dtests (PASS) j8_dtests (PASS) On Thu, Jul 16, 2020 at 10:18 AM Jordan West wrote: > +1 nb > > On Thu, Jul 16, 2020 at 9:38 AM Yifan Cai wrote: > > > +1 nb > > > > > > From: Robert Stupp > > Sent: Thursday, July 16, 2020 2:59:34 AM > > To: dev@cassandra.apache.org > > Subject: Re: [VOTE] Release Apache Cassandra 4.0-beta1 > > > > +1 (nb) > > > > — > > Robert Stupp > > @snazy > > > > > On 15. Jul 2020, at 20:07, Jasonstack Zhao Yang < > > zhaoyangsingap...@gmail.com> wrote: > > > > > > +1 (nb) > > > > > > On Thu, 16 Jul 2020 at 01:28, Brandon Williams > wrote: > > > > > >> +1 (binding) > > >> > > >> On Tue, Jul 14, 2020, 6:06 PM Mick Semb Wever wrote: > > >> > > >>> Proposing the test build of Cassandra 4.0-beta1 for release. > > >>> > > >>> sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 > > >>> Git: > > >>> > > >>> > > >> > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative > > >>> Maven Artifacts: > > >>> > > >>> > > >> > > > https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ > > >>> > > >>> The Source and Build Artifacts, and the Debian and RPM packages and > > >>> repositories, are available here: > > >>> https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta1/ > > >>> > > >>> The vote will be open for 72 hours (longer if needed). Everyone who > has > > >>> tested the build is invited to vote. Votes by PMC members are > > considered > > >>> binding. A vote passes if there are at least three binding +1s and no > > >> -1s. > > >>> > > >>> Eventual publishing and announcement of the 4.0-beta1 release will be > > >>> coordinated, as described in > > >>> > > >>> > > >> > > > https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E > > >>> > > >>> [1]: CHANGES.txt: > > >>> > > >>> > > >> > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative > > >>> [2]: NEWS.txt: > > >>> > > >>> > > >> > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative > > >>> > > >> > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [VOTE] Release Apache Cassandra 4.0-beta1
This -1 is due to removal of an unused, unadvertised, and likely never working feature being removed in the config and raising an exception upon use. Is that accurate? > > I bid that we allow this into the beta and you agree to rescind your -1 as we can reasonably conclude the likelihood of any users running into this is basically zero. We can document it in the release notes as a known issue to be addressed in a subsequent beta release. The cost to us delaying the beta over this ticket is risking our currently lined up coordination with journalists and other channels (social media, etc) with marketing material and the ASF blog post that's lined up for the project. On Fri, Jul 17, 2020 at 5:14 AM Benedict Elliott Smith wrote: > -1 > > Sorry, I dropped the ball on > https://issues.apache.org/jira/browse/CASSANDRA-15375 > > It's ready to commit, if somebody can give it a quick +1, and would be > prohibited after first beta. > > > On 16/07/2020, 21:16, "Sumanth Pasupuleti" < > sumanth.pasupuleti...@gmail.com> wrote: > > +1 nb > Ran following CircleCI tests > j8_unit_tests (PASS) > j8_jvm_dtests (PASS) > j8_dtests (PASS) > > On Thu, Jul 16, 2020 at 10:18 AM Jordan West > wrote: > > > +1 nb > > > > On Thu, Jul 16, 2020 at 9:38 AM Yifan Cai > wrote: > > > > > +1 nb > > > > > > > > > From: Robert Stupp > > > Sent: Thursday, July 16, 2020 2:59:34 AM > > > To: dev@cassandra.apache.org > > > Subject: Re: [VOTE] Release Apache Cassandra 4.0-beta1 > > > > > > +1 (nb) > > > > > > — > > > Robert Stupp > > > @snazy > > > > > > > On 15. Jul 2020, at 20:07, Jasonstack Zhao Yang < > > > zhaoyangsingap...@gmail.com> wrote: > > > > > > > > +1 (nb) > > > > > > > > On Thu, 16 Jul 2020 at 01:28, Brandon Williams > > > wrote: > > > > > > > >> +1 (binding) > > > >> > > > >> On Tue, Jul 14, 2020, 6:06 PM Mick Semb Wever > wrote: > > > >> > > > >>> Proposing the test build of Cassandra 4.0-beta1 for release. > > > >>> > > > >>> sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 > > > >>> Git: > > > >>> > > > >>> > > > >> > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative > > > >>> Maven Artifacts: > > > >>> > > > >>> > > > >> > > > > > > https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ > > > >>> > > > >>> The Source and Build Artifacts, and the Debian and RPM > packages and > > > >>> repositories, are available here: > > > >>> https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta1/ > > > >>> > > > >>> The vote will be open for 72 hours (longer if needed). > Everyone who > > has > > > >>> tested the build is invited to vote. Votes by PMC members are > > > considered > > > >>> binding. A vote passes if there are at least three binding +1s > and no > > > >> -1s. > > > >>> > > > >>> Eventual publishing and announcement of the 4.0-beta1 release > will be > > > >>> coordinated, as described in > > > >>> > > > >>> > > > >> > > > > > > https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E > > > >>> > > > >>> [1]: CHANGES.txt: > > > >>> > > > >>> > > > >> > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative > > > >>> [2]: NEWS.txt: > > > >>> > > > >>> > > > >> > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative > > > >>> > > > >> > > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [VOTE] Release Apache Cassandra 3.11.7
+1 On Tue, Jul 14, 2020, 5:47 PM Mick Semb Wever wrote: > Proposing the test build of Cassandra 3.11.7 for release. > > sha1: 9fe62b3e40147fda2cc081744bd375b04574aef7 > Git: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.7-tentative > Maven Artifacts: > > https://repository.apache.org/content/repositories/orgapachecassandra-1209/org/apache/cassandra/cassandra-all/3.11.7/ > > The Source and Build Artifacts, and the Debian and RPM packages and > repositories, are available here: > https://dist.apache.org/repos/dist/dev/cassandra/3.11.7/ > > The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s. > > [1]: CHANGES.txt: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.7-tentative > [2]: NEWS.txt: > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.7-tentative >
Re: [VOTE] Release Apache Cassandra 4.0-beta1
> The cost to us delaying the beta over this ticket is risking our currently > lined up coordination with journalists and other channels I'm not aware of any of this, except the blog post proposal? What channels is this being coordinated on, and with whom? If we agree to include this in beta-2, I'm OK with proceeding, but I think we'll need a separate super-majority vote on ignoring the agreed beta rules, which might be harder than just re-rolling the release? On 17/07/2020, 14:42, "Joshua McKenzie" wrote: This -1 is due to removal of an unused, unadvertised, and likely never working feature being removed in the config and raising an exception upon use. Is that accurate? > > I bid that we allow this into the beta and you agree to rescind your -1 as we can reasonably conclude the likelihood of any users running into this is basically zero. We can document it in the release notes as a known issue to be addressed in a subsequent beta release. The cost to us delaying the beta over this ticket is risking our currently lined up coordination with journalists and other channels (social media, etc) with marketing material and the ASF blog post that's lined up for the project. On Fri, Jul 17, 2020 at 5:14 AM Benedict Elliott Smith wrote: > -1 > > Sorry, I dropped the ball on > https://issues.apache.org/jira/browse/CASSANDRA-15375 > > It's ready to commit, if somebody can give it a quick +1, and would be > prohibited after first beta. > > > On 16/07/2020, 21:16, "Sumanth Pasupuleti" < > sumanth.pasupuleti...@gmail.com> wrote: > > +1 nb > Ran following CircleCI tests > j8_unit_tests (PASS) > j8_jvm_dtests (PASS) > j8_dtests (PASS) > > On Thu, Jul 16, 2020 at 10:18 AM Jordan West > wrote: > > > +1 nb > > > > On Thu, Jul 16, 2020 at 9:38 AM Yifan Cai > wrote: > > > > > +1 nb > > > > > > > > > From: Robert Stupp > > > Sent: Thursday, July 16, 2020 2:59:34 AM > > > To: dev@cassandra.apache.org > > > Subject: Re: [VOTE] Release Apache Cassandra 4.0-beta1 > > > > > > +1 (nb) > > > > > > — > > > Robert Stupp > > > @snazy > > > > > > > On 15. Jul 2020, at 20:07, Jasonstack Zhao Yang < > > > zhaoyangsingap...@gmail.com> wrote: > > > > > > > > +1 (nb) > > > > > > > > On Thu, 16 Jul 2020 at 01:28, Brandon Williams > > > wrote: > > > > > > > >> +1 (binding) > > > >> > > > >> On Tue, Jul 14, 2020, 6:06 PM Mick Semb Wever > wrote: > > > >> > > > >>> Proposing the test build of Cassandra 4.0-beta1 for release. > > > >>> > > > >>> sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 > > > >>> Git: > > > >>> > > > >>> > > > >> > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative > > > >>> Maven Artifacts: > > > >>> > > > >>> > > > >> > > > > > > https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ > > > >>> > > > >>> The Source and Build Artifacts, and the Debian and RPM > packages and > > > >>> repositories, are available here: > > > >>> https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta1/ > > > >>> > > > >>> The vote will be open for 72 hours (longer if needed). > Everyone who > > has > > > >>> tested the build is invited to vote. Votes by PMC members are > > > considered > > > >>> binding. A vote passes if there are at least three binding +1s > and no > > > >> -1s. > > > >>> > > > >>> Eventual publishing and announcement of the 4.0-beta1 release > will be > > > >>> coordinated, as described in > > > >>> > > > >>> > > > >> > > > > > > https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E > > > >>> > > > >>> [1]: CHANGES.txt: > > > >>> > > > >>> > > > >> > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative > > > >>> [2]: NEWS.txt: > > > >>> > > > >>> > > > >> > > > > > > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative > > > >>> > > > >> > > > > > > > > > > > >
Re: [VOTE] Release Apache Cassandra 4.0-beta1
> > I'm not aware of any of this, except the blog post proposal? What > channels is this being coordinated on, and with whom? Melissa Logan and Constantia are on this (she hit up the list a bit ago); I'm not deep in the weeds - more of a contributor on the list that's agreed to help out and collaborate as needed. There's tweets, the asf blog post (these two are easy to shift around), some q&a's, some interviews lined up I believe (these are far less easy to move around). I don't know if coordination on this is happening actively on dev ML or directly w/the people that volunteered to help out; I assume the latter. I'm working on how I frame things and I think I failed earlier ( oops :) ) - a more helpful set of questions from me would have been "Who is going to be negatively impacted if we let this ticket go into beta-2 instead of beta-1, and how badly? Is there a way for us to communicate this delta to them in favor of getting the beta out and, if so, is the value of getting it out worth that risk?" Or something along those lines. Seems like you managed to navigate my sleep deprived Friday morning "my personal UI is incompletely booted" scatter - sorry about that. we'll need a separate super-majority vote on ignoring the agreed beta > rules Hm. What happens if we all vote +1 on a release that doesn't 100% match the agreed upon release rules? I'd initially advocate for us taking the stance that each vote is what binds, giving us flexibility to navigate this nuance on a case by case basis in the future. I haven't spent a lot of time chewing on the implications of that statement though. The devil of codification of rules like this is that there's always cases that come up where the constraint of the rules inhibit progress without commensurate value. In a community with all good faith actors assuming positive intent, I think it's safe for us (and arguably more optimal) to use those rules as the default minimal alignment that guides behavior but we consider tickets and work on a case-by-case basis (much like with flaky tests from alpha to beta, for instance). For instance - if we approach this from a binary perspective, we have to go down the rat-hole of defining what qualifies as an API formally, voting on that, and codifying that to know what things the rules do and don't apply to. My intuition is that's past the point of diminishing returns and we're fine just being a bit more laissez-faire about things and applying our collective judgement through our votes on each instance. My own bias though, definitely receptive to other points of view on that. On Fri, Jul 17, 2020 at 11:21 AM Benedict Elliott Smith wrote: > > The cost to us delaying the beta over this ticket is risking our > currently lined up coordination with journalists and other channels > > I'm not aware of any of this, except the blog post proposal? What > channels is this being coordinated on, and with whom? > > If we agree to include this in beta-2, I'm OK with proceeding, but I think > we'll need a separate super-majority vote on ignoring the agreed beta > rules, which might be harder than just re-rolling the release? > > > On 17/07/2020, 14:42, "Joshua McKenzie" wrote: > > This -1 is due to removal of an unused, unadvertised, and likely never > working feature being removed in the config and raising an exception > upon > use. Is that accurate? > > > > > I bid that we allow this into the beta and you agree to rescind your > -1 as > we can reasonably conclude the likelihood of any users running into > this is > basically zero. We can document it in the release notes as a known > issue to > be addressed in a subsequent beta release. > > The cost to us delaying the beta over this ticket is risking our > currently > lined up coordination with journalists and other channels (social > media, > etc) with marketing material and the ASF blog post that's lined up for > the > project. > > On Fri, Jul 17, 2020 at 5:14 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > -1 > > > > Sorry, I dropped the ball on > > https://issues.apache.org/jira/browse/CASSANDRA-15375 > > > > It's ready to commit, if somebody can give it a quick +1, and would > be > > prohibited after first beta. > > > > > > On 16/07/2020, 21:16, "Sumanth Pasupuleti" < > > sumanth.pasupuleti...@gmail.com> wrote: > > > > +1 nb > > Ran following CircleCI tests > > j8_unit_tests (PASS) > > j8_jvm_dtests (PASS) > > j8_dtests (PASS) > > > > On Thu, Jul 16, 2020 at 10:18 AM Jordan West > > > wrote: > > > > > +1 nb > > > > > > On Thu, Jul 16, 2020 at 9:38 AM Yifan Cai > > wrote: > > > > > > > +1 nb > > > > > > > > > > > > From: Robert Stupp > > > > Sent: Thursday, July 16, 2020 2:59:34 AM >
Re: [VOTE] Release Apache Cassandra 4.0-beta1
-0 For the same reason as Benedict. I'd prefer we didn't deliberately violate our own agreed on release rules just for the sake of some marketing blitz that wasn't even publicly discussed but I won't stand in the way. On Fri, Jul 17, 2020 at 9:27 AM Joshua McKenzie wrote: > > > > I'm not aware of any of this, except the blog post proposal? What > > channels is this being coordinated on, and with whom? > > Melissa Logan and Constantia are on this (she hit up the list a bit ago); > I'm not deep in the weeds - more of a contributor on the list that's agreed > to help out and collaborate as needed. There's tweets, the asf blog post > (these two are easy to shift around), some q&a's, some interviews lined up > I believe (these are far less easy to move around). I don't know if > coordination on this is happening actively on dev ML or directly w/the > people that volunteered to help out; I assume the latter. > > I'm working on how I frame things and I think I failed earlier ( oops :) ) > - a more helpful set of questions from me would have been "Who is going to > be negatively impacted if we let this ticket go into beta-2 instead of > beta-1, and how badly? Is there a way for us to communicate this delta to > them in favor of getting the beta out and, if so, is the value of getting > it out worth that risk?" Or something along those lines. Seems like you > managed to navigate my sleep deprived Friday morning "my personal UI is > incompletely booted" scatter - sorry about that. > > we'll need a separate super-majority vote on ignoring the agreed beta > > rules > > Hm. What happens if we all vote +1 on a release that doesn't 100% match the > agreed upon release rules? I'd initially advocate for us taking the stance > that each vote is what binds, giving us flexibility to navigate this nuance > on a case by case basis in the future. I haven't spent a lot of time > chewing on the implications of that statement though. > > The devil of codification of rules like this is that there's always cases > that come up where the constraint of the rules inhibit progress without > commensurate value. In a community with all good faith actors assuming > positive intent, I think it's safe for us (and arguably more optimal) to > use those rules as the default minimal alignment that guides behavior but > we consider tickets and work on a case-by-case basis (much like with flaky > tests from alpha to beta, for instance). > > For instance - if we approach this from a binary perspective, we have to go > down the rat-hole of defining what qualifies as an API formally, voting on > that, and codifying that to know what things the rules do and don't apply > to. My intuition is that's past the point of diminishing returns and we're > fine just being a bit more laissez-faire about things and applying our > collective judgement through our votes on each instance. My own bias > though, definitely receptive to other points of view on that. > > > > On Fri, Jul 17, 2020 at 11:21 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > > The cost to us delaying the beta over this ticket is risking our > > currently lined up coordination with journalists and other channels > > > > I'm not aware of any of this, except the blog post proposal? What > > channels is this being coordinated on, and with whom? > > > > If we agree to include this in beta-2, I'm OK with proceeding, but I > think > > we'll need a separate super-majority vote on ignoring the agreed beta > > rules, which might be harder than just re-rolling the release? > > > > > > On 17/07/2020, 14:42, "Joshua McKenzie" wrote: > > > > This -1 is due to removal of an unused, unadvertised, and likely > never > > working feature being removed in the config and raising an exception > > upon > > use. Is that accurate? > > > > > > > > I bid that we allow this into the beta and you agree to rescind your > > -1 as > > we can reasonably conclude the likelihood of any users running into > > this is > > basically zero. We can document it in the release notes as a known > > issue to > > be addressed in a subsequent beta release. > > > > The cost to us delaying the beta over this ticket is risking our > > currently > > lined up coordination with journalists and other channels (social > > media, > > etc) with marketing material and the ASF blog post that's lined up > for > > the > > project. > > > > On Fri, Jul 17, 2020 at 5:14 AM Benedict Elliott Smith < > > bened...@apache.org> > > wrote: > > > > > -1 > > > > > > Sorry, I dropped the ball on > > > https://issues.apache.org/jira/browse/CASSANDRA-15375 > > > > > > It's ready to commit, if somebody can give it a quick +1, and would > > be > > > prohibited after first beta. > > > > > > > > > On 16/07/2020, 21:16, "Sumanth Pasupuleti" < > > > sumanth.pasupuleti...@gmail.com> wrote: > > > > > > +1 nb > > > Ran followi
Re: [VOTE] Release Apache Cassandra 4.0-beta1
So, I'll say few things in bullet point form just for my general sentiment 1) I recognise the value of these efforts, and do not want to undermine them 2) I'm anyway very disappointed when individuals act on behalf of the project without involving it in the decision-making or coordination 3) We're trying to strengthen project governance, and I find it worrisome to even countenance a disregard for the frameworks that have been agreed I'm not sure what the right approach is. I do not condone this situation, but also do not want the project to suffer for it. I'll mull it over. On 17/07/2020, 17:27, "Joshua McKenzie" wrote: > > I'm not aware of any of this, except the blog post proposal? What > channels is this being coordinated on, and with whom? Melissa Logan and Constantia are on this (she hit up the list a bit ago); I'm not deep in the weeds - more of a contributor on the list that's agreed to help out and collaborate as needed. There's tweets, the asf blog post (these two are easy to shift around), some q&a's, some interviews lined up I believe (these are far less easy to move around). I don't know if coordination on this is happening actively on dev ML or directly w/the people that volunteered to help out; I assume the latter. I'm working on how I frame things and I think I failed earlier ( oops :) ) - a more helpful set of questions from me would have been "Who is going to be negatively impacted if we let this ticket go into beta-2 instead of beta-1, and how badly? Is there a way for us to communicate this delta to them in favor of getting the beta out and, if so, is the value of getting it out worth that risk?" Or something along those lines. Seems like you managed to navigate my sleep deprived Friday morning "my personal UI is incompletely booted" scatter - sorry about that. we'll need a separate super-majority vote on ignoring the agreed beta > rules Hm. What happens if we all vote +1 on a release that doesn't 100% match the agreed upon release rules? I'd initially advocate for us taking the stance that each vote is what binds, giving us flexibility to navigate this nuance on a case by case basis in the future. I haven't spent a lot of time chewing on the implications of that statement though. The devil of codification of rules like this is that there's always cases that come up where the constraint of the rules inhibit progress without commensurate value. In a community with all good faith actors assuming positive intent, I think it's safe for us (and arguably more optimal) to use those rules as the default minimal alignment that guides behavior but we consider tickets and work on a case-by-case basis (much like with flaky tests from alpha to beta, for instance). For instance - if we approach this from a binary perspective, we have to go down the rat-hole of defining what qualifies as an API formally, voting on that, and codifying that to know what things the rules do and don't apply to. My intuition is that's past the point of diminishing returns and we're fine just being a bit more laissez-faire about things and applying our collective judgement through our votes on each instance. My own bias though, definitely receptive to other points of view on that. On Fri, Jul 17, 2020 at 11:21 AM Benedict Elliott Smith wrote: > > The cost to us delaying the beta over this ticket is risking our > currently lined up coordination with journalists and other channels > > I'm not aware of any of this, except the blog post proposal? What > channels is this being coordinated on, and with whom? > > If we agree to include this in beta-2, I'm OK with proceeding, but I think > we'll need a separate super-majority vote on ignoring the agreed beta > rules, which might be harder than just re-rolling the release? > > > On 17/07/2020, 14:42, "Joshua McKenzie" wrote: > > This -1 is due to removal of an unused, unadvertised, and likely never > working feature being removed in the config and raising an exception > upon > use. Is that accurate? > > > > > I bid that we allow this into the beta and you agree to rescind your > -1 as > we can reasonably conclude the likelihood of any users running into > this is > basically zero. We can document it in the release notes as a known > issue to > be addressed in a subsequent beta release. > > The cost to us delaying the beta over this ticket is risking our > currently > lined up coordination with journalists and other channels (social > media, > etc) with marketing material and the ASF blog post that's lined up for > the > project. > > On Fri, Jul 17, 2020 at 5:14 AM Benedict Elliott Smith < > ben
Re: [VOTE] Release Apache Cassandra 4.0-beta1
> If we agree to include this in beta-2, I'm OK with proceeding, but I think we'll need a separate super-majority vote on ignoring the agreed beta rules, which might be harder than just re-rolling the release? This position, on a release vote, by precedence sounds more like a -0. A valid concern has been raised, needs to be heard, but can and should be resolved within this thread and vote. It has my vote to be added to 4.0- beta2. I think it's worth pointing out that this ticket was never marked with a fix-version "4.0-alpha", so it was never visible as a blocker to the first beta release. Being strict here IMHO would mean reverting the commit and posting it to 4.1/5.0, rather blocking beta1. And… isn't the only thing that breaks API compatibility (and our beta rules) here is this one line: https://github.com/apache/cassandra/commit/d8993934e976d8edb94cbfe2974688dac63c5db5#diff-4805e34bd9553ede03778be66ddc06c7R268 I can cut a new 4.0-beta1, no problems there. The bar to re-cutting a proposed release should be low enough that it's an easy enough call to request. I will wait a few hours before doing so, to see what eventuates here…
Re: [VOTE] Release Apache Cassandra 4.0-beta1
> > some marketing blitz that wasn't even publicly discussed but I won't stand > in the way. > 2) I'm anyway very disappointed when individuals act on behalf of the > project without involving it in the decision-making or coordination This topic was opened on the public ML and volunteers asked for and replied, and the pmc was engaged to review and revise the marketing blog. We currently don't do all dev on the public ML so it's pretty consistent with that precedent. If we want this behavior to be changed or revised (for instance, any and all discussion or coordination for any and all individual project contributors engaging with journalists or providing quotes about the release), that's something we should discuss separately on another thread. Let's not derail this discussion further and I'd ask we be mindful about how we characterize new contributor contributions as our community evolves. On Fri, Jul 17, 2020 at 2:24 PM Mick Semb Wever wrote: > > If we agree to include this in beta-2, I'm OK with proceeding, but I > think we'll need a separate super-majority vote on ignoring the agreed beta > rules, which might be harder than just re-rolling the release? > > > This position, on a release vote, by precedence sounds more like a -0. A > valid concern has been raised, needs to be heard, but can and should be > resolved within this thread and vote. It has my vote to be added to 4.0- > beta2. > > > I think it's worth pointing out that this ticket was never marked with a > fix-version "4.0-alpha", so it was never visible as a blocker to the first > beta release. Being strict here IMHO would mean reverting the commit and > posting it to 4.1/5.0, rather blocking beta1. > > And… isn't the only thing that breaks API compatibility (and our beta > rules) > here is this one line: > > https://github.com/apache/cassandra/commit/d8993934e976d8edb94cbfe2974688dac63c5db5#diff-4805e34bd9553ede03778be66ddc06c7R268 > > > I can cut a new 4.0-beta1, no problems there. The bar to re-cutting a > proposed > release should be low enough that it's an easy enough call to request. I > will wait a few hours before doing so, to see what eventuates here… >
Re: [VOTE] Release Apache Cassandra 4.0-beta1
Hi all, Melissa of Constantia here (just back from PTO). Our plan is to share the community-approved blog with reporters who have expressed interest in Cassandra, which may result in coverage. We also developed a 4.0 beta graphic that anyone is welcome to use. FWIW our timeline revolves around yours. We're ready to reach out just as soon as the beta is cut; no need to adjust anything on our behalf. If you're available for emailed or live interviews, please shoot me a note. We're here to help C*. I've spoken with a handful of folks already about how to best achieve that, and the door is open - reach out anytime! Melissa On Fri, Jul 17, 2020 at 11:23 AM Mick Semb Wever wrote: > > If we agree to include this in beta-2, I'm OK with proceeding, but I > think we'll need a separate super-majority vote on ignoring the agreed beta > rules, which might be harder than just re-rolling the release? > > > This position, on a release vote, by precedence sounds more like a -0. A > valid concern has been raised, needs to be heard, but can and should be > resolved within this thread and vote. It has my vote to be added to 4.0- > beta2. > > > I think it's worth pointing out that this ticket was never marked with a > fix-version "4.0-alpha", so it was never visible as a blocker to the first > beta release. Being strict here IMHO would mean reverting the commit and > posting it to 4.1/5.0, rather blocking beta1. > > And… isn't the only thing that breaks API compatibility (and our beta > rules) > here is this one line: > > https://github.com/apache/cassandra/commit/d8993934e976d8edb94cbfe2974688dac63c5db5#diff-4805e34bd9553ede03778be66ddc06c7R268 > > > I can cut a new 4.0-beta1, no problems there. The bar to re-cutting a > proposed > release should be low enough that it's an easy enough call to request. I > will wait a few hours before doing so, to see what eventuates here… >
Re: [VOTE] Release Apache Cassandra 4.0-beta1
> > The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s and no -1s. > Vote closed/cancelled, am re-cutting it…
Re: [VOTE] Release Apache Cassandra 4.0-beta1
Thanks for the clarification Melissa. It’s interesting to see how open source marketing and timing differs from “traditional”. Looks like I was mistaken about coordination implications of delay. Sorry for instigating needless conflict. > On Jul 17, 2020, at 5:11 PM, Mick Semb Wever wrote: > > >> >> >> The vote will be open for 72 hours (longer if needed). Everyone who has >> tested the build is invited to vote. Votes by PMC members are considered >> binding. A vote passes if there are at least three binding +1s and no -1s. >> > > > Vote closed/cancelled, am re-cutting it… - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
[VOTE] Release Apache Cassandra 4.0-beta1 (take2)
Proposing the test build of Cassandra 4.0-beta1 for release. sha1: 972da6fcffa87b3a1684362a2bab97db853372d8 Git: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1211/org/apache/cassandra/cassandra-all/4.0-beta1/ The Source and Build Artifacts, and the Debian and RPM packages and repositories, are available here: https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta1/ The vote will be open for 60 hours (longer if needed). I've taken 12 hours off the normal 72 hours and this follows closely after the initial 4.0-beta1 vote. Everyone who has tested the build is invited to vote. Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and no -1s. Eventual publishing and announcement of the 4.0-beta1 release will be coordinated, as described in https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E [1]: CHANGES.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative [2]: NEWS.txt: https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative
