Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
> 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! Thanks Melissa! If all goes well there should be a 4.0 beta release ready for public this week. Coordinating media releases around open source releases is not something I've seen much of, or have much experience with. I can imagine that it is always going to be clumsy around an organic group of individuals around the world, individuals doing their best to be independent from the companies that employ them, companies that each have own stake in the project. We just have to do our best! If people know of other OSS projects doing this well it would be great to know and learn from them. To all non DataStax folk, I've only seen Melissa's work in this community (dev and private ML). There has been nothing about this internally at DS. The only thing I've heard about the media coordination is from Josh's post here, and I made mention of it when raising the vote: https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E DS of course benefits from a successful OSS project, but so do we all, so do please help Melissa (and all new contributors) out, there's really no reason not to assume best intentions here. regards, Mick - 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 (take2)
+1 (nb) On Sun, 19 Jul 2020 at 07:01, Ekaterina Dimitrova wrote: > +1(nb) > > On Sat, 18 Jul 2020 at 18:13, Jeff Jirsa wrote: > > > > > > > +1 > > > > > On Jul 17, 2020, at 4:28 PM, Mick Semb Wever wrote: > > > > > > 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 > > > > - > > 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 (take2)
+1 (nb) The drivers smoke test suite looks good: https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34194004 Mick Semb Wever escreveu no dia sábado, 18/07/2020 à(s) 00:27: > 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 >
Re: [VOTE] Release Apache Cassandra 4.0-beta1 (take2)
+1 (nb) On Mon, 20 Jul 2020 at 12:58, João Reis wrote: > +1 (nb) > > The drivers smoke test suite looks good: > > > https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34194004 > > Mick Semb Wever escreveu no dia sábado, 18/07/2020 à(s) > 00:27: > > > 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 > > >
Re: [VOTE] Release Apache Cassandra 4.0-beta1 (take2)
+1 On Mon, Jul 20, 2020 at 8:08 AM Andrés de la Peña wrote: > +1 (nb) > > On Mon, 20 Jul 2020 at 12:58, João Reis wrote: > > > +1 (nb) > > > > The drivers smoke test suite looks good: > > > > > > > https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34194004 > > > > Mick Semb Wever escreveu no dia sábado, 18/07/2020 à(s) > > 00:27: > > > > > 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 > > > > > > -- http://twitter.com/tjake
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
Hello everyone --Mick pinged me about this; I wanted to respond on-list for efficacy. We've had dozens of companies successfully help Apache Projects and their communities help spread the word on their projects with their PR and marketing teams. Here are some best practices: 1) Timing. Ensure that the Project has announced the project milestone first to their lists as well as announce@ before any media coverage takes place. If you're planning to time the announcements to take place in tandem, be careful with embargoes, as not everyone is able to honor them. We've been burned in the past with this. 2) Messaging. Keep your announcement plans and draft press releases, etc., private: limit discussions to the PMC. Drafting announcements on public lists, such as user@, whilst inclusive, may inadvertently expose your news prematurely to the press, bloggers, and others before its ready. This can be detrimental to having your news scooped before you actually announce it, or conversely, having the news come out and nobody is interested in covering it as it's been leaking for a while. We've also been burned in the past with this. Synching messaging is also helpful to ensure that the PMC speaks with a unified voice: the worst thing that can happen is having someone say one thing in the media and another member of the PMC saying something else, even if it's their personal opinion. Fragmentation helps no-one. This recently happened with a Project on a rather controversial topic, so the press was excited to see dissent within the community as it gave them more to report about. Keep things co ol: don't be the feature cover of a gossip tabloid. 3) Positioning. It's critical that whomever is speaking on behalf of the Project identify themselves as such. This means that the PMC needs to have a few spokespeople lined up in case of any media queries, and that the spokespeople supporting the project are from different organizations so you can . I cannot stress enough the need to exhibit diversity, even if everyone working on the media/marketing side is from a single organization --the ASF comes down hard on companies that "own" projects: we take vendor-neutrality very seriously. What's worked well with organizations that have pitched the press on behalf of a project is to pitch the project news, have spokespeople from other organizations speak on behalf of the PMC and follow up with different spokespeople/companies that have supporting products or activities. The ability to showcase breadth of deployment demonstrates Project relevance. There have been instances of companies pre-announcing Project news and milestones before the Project has done so themselves, in the form of press releases, blog posts, articles on Medium/DZone/elsewhere, or on social media. Whilst we appreciate their enthusiasm, it has caused significant erosion of goodwill within the community, and issues with the press. Apache Projects that have been successful with outside (corporate) support to help with marketing and media relations have shared their press announcements, articles, posts, and pitches prior to going live to ensure that they are balanced and have proper attribution and form. I'm happy to help with this if needed. Briefing analysts is a bit of a different situation, and I'm happy to help with that as well. Best of luck, Sally + forwarding to press@ as well to keep everyone in the loop - - - Vice President Marketing & Publicity Vice President Sponsor Relations The Apache Software Foundation Tel +1 617 921 8656 | s...@apache.org On 2020/07/20 09:44:31, "Mick Semb Wever" wrote: > > > 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! > > > Thanks Melissa! If all goes well there should be a 4.0 beta release ready for > public this week. > > Coordinating media releases around open source releases is not something I've > seen much of, or have much experience with. I can imagine that it is always > going to be clumsy around an organic group of individuals around the world, > individuals doing their best to be independent from the companies that employ > them, companies that each have own stake in the project. We just have to do > our best! If people know of other OSS projects doing this well it would be > great to know and learn from them. > > To all non DataStax folk, I've only seen Melissa's work in this community > (dev and private ML). There
Re: [VOTE] Release Apache Cassandra 4.0-beta1 (take2)
+1 On Mon, Jul 20, 2020 at 8:51 AM Jake Luciani wrote: > +1 > > On Mon, Jul 20, 2020 at 8:08 AM Andrés de la Peña < > a.penya.gar...@gmail.com> > wrote: > > > +1 (nb) > > > > On Mon, 20 Jul 2020 at 12:58, João Reis wrote: > > > > > +1 (nb) > > > > > > The drivers smoke test suite looks good: > > > > > > > > > > > > https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34194004 > > > > > > Mick Semb Wever escreveu no dia sábado, 18/07/2020 > à(s) > > > 00:27: > > > > > > > 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 > > > > > > > > > > > > -- > http://twitter.com/tjake >
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
Thanks Sally, really appreciate your insight. To respond to the community discourse around this: > Keep your announcement plans ... private: limit discussions to the PMC This is all that I was asking and expecting: if somebody is making commitments on behalf of the community (such as that a release can be expected on day X), this should be coordinated with the PMC. While it seems to transpire that no such commitments were made, had they been made without the knowledge of the PMC this would in my view be problematic. This is not at all like development work, as has been alleged, since that only takes effect after public agreement by the community. IMO, in general, public engagements should be run past the PMC as a final pre-flight check regardless of any commitment being made, as the PMC should have visibility into these activities and have the opportunity to influence them. > There has been nothing about this internally at DS I would ask that you refrain from making such claims, unless you can be certain that you would have been privy to all such internal discussions. > there's really no reason not to assume best intentions here This is a recurring taking point, that I wish we would retire except where a clear assumption of bad faith has been made. If you are criticised, it is often because of the action you took; any intention you had may be irrelevant to the criticism. In this case, when you act on behalf of the community, your intentions are insufficient: you must have the community's authority to act. On 20/07/2020, 14:00, "Sally Khudairi" wrote: Hello everyone --Mick pinged me about this; I wanted to respond on-list for efficacy. We've had dozens of companies successfully help Apache Projects and their communities help spread the word on their projects with their PR and marketing teams. Here are some best practices: 1) Timing. Ensure that the Project has announced the project milestone first to their lists as well as announce@ before any media coverage takes place. If you're planning to time the announcements to take place in tandem, be careful with embargoes, as not everyone is able to honor them. We've been burned in the past with this. 2) Messaging. Keep your announcement plans and draft press releases, etc., private: limit discussions to the PMC. Drafting announcements on public lists, such as user@, whilst inclusive, may inadvertently expose your news prematurely to the press, bloggers, and others before its ready. This can be detrimental to having your news scooped before you actually announce it, or conversely, having the news come out and nobody is interested in covering it as it's been leaking for a while. We've also been burned in the past with this. Synching messaging is also helpful to ensure that the PMC speaks with a unified voice: the worst thing that can happen is having someone say one thing in the media and another member of the PMC saying something else, even if it's their personal opinion. Fragmentation helps no-one. This recently happened with a Project on a rather controversial topic, so the press was excited to see dissent within the community as it gave them more to report about. Keep things co ol: don't be the feature cover of a gossip tabloid. 3) Positioning. It's critical that whomever is speaking on behalf of the Project identify themselves as such. This means that the PMC needs to have a few spokespeople lined up in case of any media queries, and that the spokespeople supporting the project are from different organizations so you can . I cannot stress enough the need to exhibit diversity, even if everyone working on the media/marketing side is from a single organization --the ASF comes down hard on companies that "own" projects: we take vendor-neutrality very seriously. What's worked well with organizations that have pitched the press on behalf of a project is to pitch the project news, have spokespeople from other organizations speak on behalf of the PMC and follow up with different spokespeople/companies that have supporting products or activities. The ability to showcase breadth of deployment demonstrates Project relevance. There have been instances of companies pre-announcing Project news and milestones before the Project has done so themselves, in the form of press releases, blog posts, articles on Medium/DZone/elsewhere, or on social media. Whilst we appreciate their enthusiasm, it has caused significant erosion of goodwill within the community, and issues with the press. Apache Projects that have been successful with outside (corporate) support to help with marketing and media relations have shared their press announcements, articles, posts, and pitches prior to going live to ensure that they are balanced and have proper attribution and form. I'm happy to help with this if needed. Briefing analysts is a bit of a different situation, and I'm happy to help
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
> > If you are criticised, it is often because of the action you took; Actually, in this case and many others it's because of people's unfounded assumptions about motives, incentives, and actions taken and has little to do with reality. Which is the definition of not assuming positive intent. On Mon, Jul 20, 2020 at 10:41 AM Benedict Elliott Smith wrote: > Thanks Sally, really appreciate your insight. > > To respond to the community discourse around this: > > > Keep your announcement plans ... private: limit discussions to the PMC > > This is all that I was asking and expecting: if somebody is making > commitments on behalf of the community (such as that a release can be > expected on day X), this should be coordinated with the PMC. While it > seems to transpire that no such commitments were made, had they been made > without the knowledge of the PMC this would in my view be problematic. > This is not at all like development work, as has been alleged, since that > only takes effect after public agreement by the community. > > IMO, in general, public engagements should be run past the PMC as a final > pre-flight check regardless of any commitment being made, as the PMC should > have visibility into these activities and have the opportunity to influence > them. > > > There has been nothing about this internally at DS > > I would ask that you refrain from making such claims, unless you can be > certain that you would have been privy to all such internal discussions. > > > there's really no reason not to assume best intentions here > > This is a recurring taking point, that I wish we would retire except where > a clear assumption of bad faith has been made. If you are criticised, it > is often because of the action you took; any intention you had may be > irrelevant to the criticism. In this case, when you act on behalf of the > community, your intentions are insufficient: you must have the community's > authority to act. > > > On 20/07/2020, 14:00, "Sally Khudairi" wrote: > > Hello everyone --Mick pinged me about this; I wanted to respond > on-list for efficacy. > > We've had dozens of companies successfully help Apache Projects and > their communities help spread the word on their projects with their PR and > marketing teams. Here are some best practices: > > 1) Timing. Ensure that the Project has announced the project milestone > first to their lists as well as announce@ before any media coverage takes > place. If you're planning to time the announcements to take place in > tandem, be careful with embargoes, as not everyone is able to honor them. > We've been burned in the past with this. > > 2) Messaging. Keep your announcement plans and draft press releases, > etc., private: limit discussions to the PMC. Drafting announcements on > public lists, such as user@, whilst inclusive, may inadvertently expose > your news prematurely to the press, bloggers, and others before its ready. > This can be detrimental to having your news scooped before you actually > announce it, or conversely, having the news come out and nobody is > interested in covering it as it's been leaking for a while. We've also been > burned in the past with this. Synching messaging is also helpful to ensure > that the PMC speaks with a unified voice: the worst thing that can happen > is having someone say one thing in the media and another member of the PMC > saying something else, even if it's their personal opinion. Fragmentation > helps no-one. This recently happened with a Project on a rather > controversial topic, so the press was excited to see dissent within the > community as it gave them more to report about. Keep things co > ol: don't be the feature cover of a gossip tabloid. > > 3) Positioning. It's critical that whomever is speaking on behalf of > the Project identify themselves as such. This means that the PMC needs to > have a few spokespeople lined up in case of any media queries, and that the > spokespeople supporting the project are from different organizations so you > can . I cannot stress enough the need to exhibit diversity, even if > everyone working on the media/marketing side is from a single organization > --the ASF comes down hard on companies that "own" projects: we take > vendor-neutrality very seriously. What's worked well with organizations > that have pitched the press on behalf of a project is to pitch the project > news, have spokespeople from other organizations speak on behalf of the PMC > and follow up with different spokespeople/companies that have supporting > products or activities. The ability to showcase breadth of deployment > demonstrates Project relevance. > > There have been instances of companies pre-announcing Project news and > milestones before the Project has done so themselves, in the form of press > releases, blog posts, articles on Medium/DZone/elsewhere, or on social > media. Whilst we appreciate their enthusiasm, it has caused significant > erosion of
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
> > There has been nothing about this internally at DS > > I would ask that you refrain from making such claims, unless you can be > certain that you would have been privy to all such internal discussions. Benedict, re-reading it I realised that sentence lost some important words during my drafts. *I had not seen or heard* of anything internally as DS. I do hope everyone read and reads it as such. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
> Hello everyone --Mick pinged me about this; I wanted to respond on-list for > efficacy. Thank you very much Sally! - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
Firstly, that is a very strong claim that in this particular case is disputed by the facts. You made a very specific claim that the delay was "risking our currently lined up coordination with journalists and other channels". I am not the only person to interpret this as implying coordination with journalists, contingent on a release schedule not agreed by the PMC. This was based on semantics only; as far as I can tell, no intentions or assumptions have entered into this debate, except on your part. > Which is the definition of not assuming positive intent. Secondly, this is not the definition of positive intent. Positive intent only indicates that you "mean well" Thirdly, in many recent disputes about governance, you have made a negative claim about my behaviour, or ascribed negative connotations to statements I have made; this is a very thinly veiled example, as I am clearly the object of this criticism. I think it has reached a point where I can perhaps legitimately claim that you are not assuming positive intent? > motives, incentives ... little to do with reality It feels like we should return to this earlier discussion, since you appear to feel it is incomplete? At the very least you seem to have taken the wrong message from my statements, and it is perhaps negatively colouring our present interactions. On 20/07/2020, 15:59, "Joshua McKenzie" wrote: > > If you are criticised, it is often because of the action you took; Actually, in this case and many others it's because of people's unfounded assumptions about motives, incentives, and actions taken and has little to do with reality. Which is the definition of not assuming positive intent. On Mon, Jul 20, 2020 at 10:41 AM Benedict Elliott Smith wrote: > Thanks Sally, really appreciate your insight. > > To respond to the community discourse around this: > > > Keep your announcement plans ... private: limit discussions to the PMC > > This is all that I was asking and expecting: if somebody is making > commitments on behalf of the community (such as that a release can be > expected on day X), this should be coordinated with the PMC. While it > seems to transpire that no such commitments were made, had they been made > without the knowledge of the PMC this would in my view be problematic. > This is not at all like development work, as has been alleged, since that > only takes effect after public agreement by the community. > > IMO, in general, public engagements should be run past the PMC as a final > pre-flight check regardless of any commitment being made, as the PMC should > have visibility into these activities and have the opportunity to influence > them. > > > There has been nothing about this internally at DS > > I would ask that you refrain from making such claims, unless you can be > certain that you would have been privy to all such internal discussions. > > > there's really no reason not to assume best intentions here > > This is a recurring taking point, that I wish we would retire except where > a clear assumption of bad faith has been made. If you are criticised, it > is often because of the action you took; any intention you had may be > irrelevant to the criticism. In this case, when you act on behalf of the > community, your intentions are insufficient: you must have the community's > authority to act. > > > On 20/07/2020, 14:00, "Sally Khudairi" wrote: > > Hello everyone --Mick pinged me about this; I wanted to respond > on-list for efficacy. > > We've had dozens of companies successfully help Apache Projects and > their communities help spread the word on their projects with their PR and > marketing teams. Here are some best practices: > > 1) Timing. Ensure that the Project has announced the project milestone > first to their lists as well as announce@ before any media coverage takes > place. If you're planning to time the announcements to take place in > tandem, be careful with embargoes, as not everyone is able to honor them. > We've been burned in the past with this. > > 2) Messaging. Keep your announcement plans and draft press releases, > etc., private: limit discussions to the PMC. Drafting announcements on > public lists, such as user@, whilst inclusive, may inadvertently expose > your news prematurely to the press, bloggers, and others before its ready. > This can be detrimental to having your news scooped before you actually > announce it, or conversely, having the news come out and nobody is > interested in covering it as it's been leaking for a while. We've also been > burned in the past with this. Synching messaging is also helpful to ensure > that the PMC speaks with a unified voice: the worst thing that can happe
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
Thank you, Mick, Sally et al. Appreciate this discussion. Coordinating media releases around open source releases is not something I've seen much of, or have much experience with. I can imagine that it is always going to be clumsy around an organic group of individuals around the world, individuals doing their best to be independent from the companies that employ them, companies that each have own stake in the project. We just have to do our best! If people know of other OSS projects doing this well it would be great to know and learn from them. > This is a new approach for C* and our aim as a contributor is to be transparent and follow community governance and norms. We're happy to share what's worked marketing OSS in our experience, perhaps as an ad hoc presentation or on an existing call -- just let me know. I've spoken to several people in the community (from a range of companies) and everyone shares an enthusiasm for seeing C* succeed and especially 4.0 -- from publishing content (discussed here: https://lists.apache.org/thread.html/r45e124f34a05dc2871cf8b094e3f57476d651933b8a69837fda0d935%40%3Cdev.cassandra.apache.org%3E) to hosting meetups and webinars, and more. Sally, thank you for reiterating the guidelines and will take you up on a review of the 4.0 messaging. Will be in touch! On Mon, Jul 20, 2020 at 8:07 AM Joshua McKenzie wrote: > > > > If you are criticised, it is often because of the action you took; > > Actually, in this case and many others it's because of people's unfounded > assumptions about motives, incentives, and actions taken and has little to > do with reality. Which is the definition of not assuming positive intent. > > On Mon, Jul 20, 2020 at 10:41 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > Thanks Sally, really appreciate your insight. > > > > To respond to the community discourse around this: > > > > > Keep your announcement plans ... private: limit discussions to the PMC > > > > This is all that I was asking and expecting: if somebody is making > > commitments on behalf of the community (such as that a release can be > > expected on day X), this should be coordinated with the PMC. While it > > seems to transpire that no such commitments were made, had they been made > > without the knowledge of the PMC this would in my view be problematic. > > This is not at all like development work, as has been alleged, since that > > only takes effect after public agreement by the community. > > > > IMO, in general, public engagements should be run past the PMC as a final > > pre-flight check regardless of any commitment being made, as the PMC > should > > have visibility into these activities and have the opportunity to > influence > > them. > > > > > There has been nothing about this internally at DS > > > > I would ask that you refrain from making such claims, unless you can be > > certain that you would have been privy to all such internal discussions. > > > > > there's really no reason not to assume best intentions here > > > > This is a recurring taking point, that I wish we would retire except > where > > a clear assumption of bad faith has been made. If you are criticised, it > > is often because of the action you took; any intention you had may be > > irrelevant to the criticism. In this case, when you act on behalf of the > > community, your intentions are insufficient: you must have the > community's > > authority to act. > > > > > > On 20/07/2020, 14:00, "Sally Khudairi" wrote: > > > > Hello everyone --Mick pinged me about this; I wanted to respond > > on-list for efficacy. > > > > We've had dozens of companies successfully help Apache Projects and > > their communities help spread the word on their projects with their PR > and > > marketing teams. Here are some best practices: > > > > 1) Timing. Ensure that the Project has announced the project > milestone > > first to their lists as well as announce@ before any media coverage > takes > > place. If you're planning to time the announcements to take place in > > tandem, be careful with embargoes, as not everyone is able to honor them. > > We've been burned in the past with this. > > > > 2) Messaging. Keep your announcement plans and draft press releases, > > etc., private: limit discussions to the PMC. Drafting announcements on > > public lists, such as user@, whilst inclusive, may inadvertently expose > > your news prematurely to the press, bloggers, and others before its > ready. > > This can be detrimental to having your news scooped before you actually > > announce it, or conversely, having the news come out and nobody is > > interested in covering it as it's been leaking for a while. We've also > been > > burned in the past with this. Synching messaging is also helpful to > ensure > > that the PMC speaks with a unified voice: the worst thing that can happen > > is having someone say one thing in the media and another member of the > PMC > > saying something else, even if it's
Re: [NOTICE] ApacheCon talk submission voting
Hi Nate, In case this got open to contributors and not only committers, I would be happy to assist with the activities, too. Best regards, Ekaterina On Sun, 19 Jul 2020 at 17:06, Nate McCall wrote: > > > > Count me in. Happy to assist. > > > > I mean, I basically did already since you were my right hand with this > last year :) >
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
I don't think Benedict mentioned anything about people's motives or intentions, he simply had a concern about how marketing timelines became a factor in a release vote without the approval of the PMC. I think this is a reasonable concern, and doesn't mean that he's assuming bad intentions. That's my reading at least, although maybe I missed something? > On Jul 20, 2020, at 7:58 AM, Joshua McKenzie wrote: > >> >> If you are criticised, it is often because of the action you took; > > Actually, in this case and many others it's because of people's unfounded > assumptions about motives, incentives, and actions taken and has little to > do with reality. Which is the definition of not assuming positive intent. > > On Mon, Jul 20, 2020 at 10:41 AM Benedict Elliott Smith > wrote: > >> Thanks Sally, really appreciate your insight. >> >> To respond to the community discourse around this: >> >>> Keep your announcement plans ... private: limit discussions to the PMC >> >> This is all that I was asking and expecting: if somebody is making >> commitments on behalf of the community (such as that a release can be >> expected on day X), this should be coordinated with the PMC. While it >> seems to transpire that no such commitments were made, had they been made >> without the knowledge of the PMC this would in my view be problematic. >> This is not at all like development work, as has been alleged, since that >> only takes effect after public agreement by the community. >> >> IMO, in general, public engagements should be run past the PMC as a final >> pre-flight check regardless of any commitment being made, as the PMC should >> have visibility into these activities and have the opportunity to influence >> them. >> >>> There has been nothing about this internally at DS >> >> I would ask that you refrain from making such claims, unless you can be >> certain that you would have been privy to all such internal discussions. >> >>> there's really no reason not to assume best intentions here >> >> This is a recurring taking point, that I wish we would retire except where >> a clear assumption of bad faith has been made. If you are criticised, it >> is often because of the action you took; any intention you had may be >> irrelevant to the criticism. In this case, when you act on behalf of the >> community, your intentions are insufficient: you must have the community's >> authority to act. >> >> >> On 20/07/2020, 14:00, "Sally Khudairi" wrote: >> >>Hello everyone --Mick pinged me about this; I wanted to respond >> on-list for efficacy. >> >>We've had dozens of companies successfully help Apache Projects and >> their communities help spread the word on their projects with their PR and >> marketing teams. Here are some best practices: >> >>1) Timing. Ensure that the Project has announced the project milestone >> first to their lists as well as announce@ before any media coverage takes >> place. If you're planning to time the announcements to take place in >> tandem, be careful with embargoes, as not everyone is able to honor them. >> We've been burned in the past with this. >> >>2) Messaging. Keep your announcement plans and draft press releases, >> etc., private: limit discussions to the PMC. Drafting announcements on >> public lists, such as user@, whilst inclusive, may inadvertently expose >> your news prematurely to the press, bloggers, and others before its ready. >> This can be detrimental to having your news scooped before you actually >> announce it, or conversely, having the news come out and nobody is >> interested in covering it as it's been leaking for a while. We've also been >> burned in the past with this. Synching messaging is also helpful to ensure >> that the PMC speaks with a unified voice: the worst thing that can happen >> is having someone say one thing in the media and another member of the PMC >> saying something else, even if it's their personal opinion. Fragmentation >> helps no-one. This recently happened with a Project on a rather >> controversial topic, so the press was excited to see dissent within the >> community as it gave them more to report about. Keep things co >> ol: don't be the feature cover of a gossip tabloid. >> >>3) Positioning. It's critical that whomever is speaking on behalf of >> the Project identify themselves as such. This means that the PMC needs to >> have a few spokespeople lined up in case of any media queries, and that the >> spokespeople supporting the project are from different organizations so you >> can . I cannot stress enough the need to exhibit diversity, even if >> everyone working on the media/marketing side is from a single organization >> --the ASF comes down hard on companies that "own" projects: we take >> vendor-neutrality very seriously. What's worked well with organizations >> that have pitched the press on behalf of a project is to pitch the project >> news, have spokespeople from other organizations speak
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
This kind of back and forth isn't productive for the project so I'm not taking this discussion further. Just want to call it out here so you or others aren't left waiting for a reply. We can agree to disagree. On Mon, Jul 20, 2020 at 11:59 AM Benedict Elliott Smith wrote: > Firstly, that is a very strong claim that in this particular case is > disputed by the facts. You made a very specific claim that the delay was > "risking our currently lined up coordination with journalists and other > channels". I am not the only person to interpret this as implying > coordination with journalists, contingent on a release schedule not agreed > by the PMC. This was based on semantics only; as far as I can tell, no > intentions or assumptions have entered into this debate, except on your > part. > > > Which is the definition of not assuming positive intent. > > Secondly, this is not the definition of positive intent. Positive intent > only indicates that you "mean well" > > Thirdly, in many recent disputes about governance, you have made a > negative claim about my behaviour, or ascribed negative connotations to > statements I have made; this is a very thinly veiled example, as I am > clearly the object of this criticism. I think it has reached a point where > I can perhaps legitimately claim that you are not assuming positive intent? > > > motives, incentives ... little to do with reality > > It feels like we should return to this earlier discussion, since you > appear to feel it is incomplete? At the very least you seem to have taken > the wrong message from my statements, and it is perhaps negatively > colouring our present interactions. > > > On 20/07/2020, 15:59, "Joshua McKenzie" wrote: > > > > > If you are criticised, it is often because of the action you took; > > Actually, in this case and many others it's because of people's > unfounded > assumptions about motives, incentives, and actions taken and has > little to > do with reality. Which is the definition of not assuming positive > intent. > > On Mon, Jul 20, 2020 at 10:41 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > Thanks Sally, really appreciate your insight. > > > > To respond to the community discourse around this: > > > > > Keep your announcement plans ... private: limit discussions to the > PMC > > > > This is all that I was asking and expecting: if somebody is making > > commitments on behalf of the community (such as that a release can be > > expected on day X), this should be coordinated with the PMC. While > it > > seems to transpire that no such commitments were made, had they been > made > > without the knowledge of the PMC this would in my view be > problematic. > > This is not at all like development work, as has been alleged, since > that > > only takes effect after public agreement by the community. > > > > IMO, in general, public engagements should be run past the PMC as a > final > > pre-flight check regardless of any commitment being made, as the PMC > should > > have visibility into these activities and have the opportunity to > influence > > them. > > > > > There has been nothing about this internally at DS > > > > I would ask that you refrain from making such claims, unless you can > be > > certain that you would have been privy to all such internal > discussions. > > > > > there's really no reason not to assume best intentions here > > > > This is a recurring taking point, that I wish we would retire except > where > > a clear assumption of bad faith has been made. If you are > criticised, it > > is often because of the action you took; any intention you had may be > > irrelevant to the criticism. In this case, when you act on behalf > of the > > community, your intentions are insufficient: you must have the > community's > > authority to act. > > > > > > On 20/07/2020, 14:00, "Sally Khudairi" wrote: > > > > Hello everyone --Mick pinged me about this; I wanted to respond > > on-list for efficacy. > > > > We've had dozens of companies successfully help Apache Projects > and > > their communities help spread the word on their projects with their > PR and > > marketing teams. Here are some best practices: > > > > 1) Timing. Ensure that the Project has announced the project > milestone > > first to their lists as well as announce@ before any media coverage > takes > > place. If you're planning to time the announcements to take place in > > tandem, be careful with embargoes, as not everyone is able to honor > them. > > We've been burned in the past with this. > > > > 2) Messaging. Keep your announcement plans and draft press > releases, > > etc., private: limit discussions to the PMC. Drafting announcements > on > > public lists, such as user@, whilst inclu
Re: [VOTE] Release Apache Cassandra 4.0-beta1
I'll add in here as someone who was acting as PM on a lot of cross-team projects at my last few gigs, this is a good example of coordination improving the process. If people are unwilling to change their opinions or even express them, that is an issue. Timing of release/progress is important and pushing back on whether changes are necessary is valid too. Being aware that Marketing contributions are valid/valuable community contributions is a key to the success of a project. Seems like there were some white spaces in what was known but this was a good resolution for all. Is there some update to public documentation that can be put out there to explain the coordination and timing w/ the Marketing team? Want to make sure this isn't only included in a single email chain but is posted up for all to review and see because it's important info. On Fri, Jul 17, 2020 at 2:38 PM wrote: > 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 > > -- Scott Hirleman scott.hirle...@gmail.com
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
I will refer you to this the next time you publicly impugn my behaviour. If you are to make personal attacks, either defend them or stop making them. On 20/07/2020, 17:15, "Joshua McKenzie" wrote: This kind of back and forth isn't productive for the project so I'm not taking this discussion further. Just want to call it out here so you or others aren't left waiting for a reply. We can agree to disagree. On Mon, Jul 20, 2020 at 11:59 AM Benedict Elliott Smith wrote: > Firstly, that is a very strong claim that in this particular case is > disputed by the facts. You made a very specific claim that the delay was > "risking our currently lined up coordination with journalists and other > channels". I am not the only person to interpret this as implying > coordination with journalists, contingent on a release schedule not agreed > by the PMC. This was based on semantics only; as far as I can tell, no > intentions or assumptions have entered into this debate, except on your > part. > > > Which is the definition of not assuming positive intent. > > Secondly, this is not the definition of positive intent. Positive intent > only indicates that you "mean well" > > Thirdly, in many recent disputes about governance, you have made a > negative claim about my behaviour, or ascribed negative connotations to > statements I have made; this is a very thinly veiled example, as I am > clearly the object of this criticism. I think it has reached a point where > I can perhaps legitimately claim that you are not assuming positive intent? > > > motives, incentives ... little to do with reality > > It feels like we should return to this earlier discussion, since you > appear to feel it is incomplete? At the very least you seem to have taken > the wrong message from my statements, and it is perhaps negatively > colouring our present interactions. > > > On 20/07/2020, 15:59, "Joshua McKenzie" wrote: > > > > > If you are criticised, it is often because of the action you took; > > Actually, in this case and many others it's because of people's > unfounded > assumptions about motives, incentives, and actions taken and has > little to > do with reality. Which is the definition of not assuming positive > intent. > > On Mon, Jul 20, 2020 at 10:41 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > Thanks Sally, really appreciate your insight. > > > > To respond to the community discourse around this: > > > > > Keep your announcement plans ... private: limit discussions to the > PMC > > > > This is all that I was asking and expecting: if somebody is making > > commitments on behalf of the community (such as that a release can be > > expected on day X), this should be coordinated with the PMC. While > it > > seems to transpire that no such commitments were made, had they been > made > > without the knowledge of the PMC this would in my view be > problematic. > > This is not at all like development work, as has been alleged, since > that > > only takes effect after public agreement by the community. > > > > IMO, in general, public engagements should be run past the PMC as a > final > > pre-flight check regardless of any commitment being made, as the PMC > should > > have visibility into these activities and have the opportunity to > influence > > them. > > > > > There has been nothing about this internally at DS > > > > I would ask that you refrain from making such claims, unless you can > be > > certain that you would have been privy to all such internal > discussions. > > > > > there's really no reason not to assume best intentions here > > > > This is a recurring taking point, that I wish we would retire except > where > > a clear assumption of bad faith has been made. If you are > criticised, it > > is often because of the action you took; any intention you had may be > > irrelevant to the criticism. In this case, when you act on behalf > of the > > community, your intentions are insufficient: you must have the > community's > > authority to act. > > > > > > On 20/07/2020, 14:00, "Sally Khudairi" wrote: > > > > Hello everyone --Mick pinged me about this; I wanted to respond > > on-list for efficacy. > > > > We've had dozens of companies successfully help Apache Projects > and > > their communities help spread the word on their projects with their > PR and > > marketing teams
Re: [VOTE] Release Apache Cassandra 4.0-beta1 (take2)
+1, thanks Mick for rerolling. On Mon, Jul 20, 2020 at 6:42 AM Joshua McKenzie wrote: > +1 > > On Mon, Jul 20, 2020 at 8:51 AM Jake Luciani wrote: > > > +1 > > > > On Mon, Jul 20, 2020 at 8:08 AM Andrés de la Peña < > > a.penya.gar...@gmail.com> > > wrote: > > > > > +1 (nb) > > > > > > On Mon, 20 Jul 2020 at 12:58, João Reis > wrote: > > > > > > > +1 (nb) > > > > > > > > The drivers smoke test suite looks good: > > > > > > > > > > > > > > > > > > https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34194004 > > > > > > > > Mick Semb Wever escreveu no dia sábado, 18/07/2020 > > à(s) > > > > 00:27: > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > -- > > http://twitter.com/tjake > > >
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
For the 4.0 beta blog/infographic -- the PMC has approved and Sally has also reviewed. I'm happy to publish on site (per dev guidelines on GitHub) unless someone else would like to volunteer and has the dev environment already set up on their machine. If the latter, would you let me know today so we can coordinate? On Mon, Jul 20, 2020 at 9:40 AM Benedict Elliott Smith wrote: > I will refer you to this the next time you publicly impugn my behaviour. > If you are to make personal attacks, either defend them or stop making them. > > On 20/07/2020, 17:15, "Joshua McKenzie" wrote: > > This kind of back and forth isn't productive for the project so I'm not > taking this discussion further. Just want to call it out here so you or > others aren't left waiting for a reply. > > We can agree to disagree. > > On Mon, Jul 20, 2020 at 11:59 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > Firstly, that is a very strong claim that in this particular case is > > disputed by the facts. You made a very specific claim that the > delay was > > "risking our currently lined up coordination with journalists and > other > > channels". I am not the only person to interpret this as implying > > coordination with journalists, contingent on a release schedule not > agreed > > by the PMC. This was based on semantics only; as far as I can tell, > no > > intentions or assumptions have entered into this debate, except on > your > > part. > > > > > Which is the definition of not assuming positive intent. > > > > Secondly, this is not the definition of positive intent. Positive > intent > > only indicates that you "mean well" > > > > Thirdly, in many recent disputes about governance, you have made a > > negative claim about my behaviour, or ascribed negative connotations > to > > statements I have made; this is a very thinly veiled example, as I am > > clearly the object of this criticism. I think it has reached a > point where > > I can perhaps legitimately claim that you are not assuming positive > intent? > > > > > motives, incentives ... little to do with reality > > > > It feels like we should return to this earlier discussion, since you > > appear to feel it is incomplete? At the very least you seem to have > taken > > the wrong message from my statements, and it is perhaps negatively > > colouring our present interactions. > > > > > > On 20/07/2020, 15:59, "Joshua McKenzie" > wrote: > > > > > > > > If you are criticised, it is often because of the action you > took; > > > > Actually, in this case and many others it's because of people's > > unfounded > > assumptions about motives, incentives, and actions taken and has > > little to > > do with reality. Which is the definition of not assuming positive > > intent. > > > > On Mon, Jul 20, 2020 at 10:41 AM Benedict Elliott Smith < > > bened...@apache.org> > > wrote: > > > > > Thanks Sally, really appreciate your insight. > > > > > > To respond to the community discourse around this: > > > > > > > Keep your announcement plans ... private: limit discussions > to the > > PMC > > > > > > This is all that I was asking and expecting: if somebody is > making > > > commitments on behalf of the community (such as that a release > can be > > > expected on day X), this should be coordinated with the PMC. > While > > it > > > seems to transpire that no such commitments were made, had > they been > > made > > > without the knowledge of the PMC this would in my view be > > problematic. > > > This is not at all like development work, as has been alleged, > since > > that > > > only takes effect after public agreement by the community. > > > > > > IMO, in general, public engagements should be run past the PMC > as a > > final > > > pre-flight check regardless of any commitment being made, as > the PMC > > should > > > have visibility into these activities and have the opportunity > to > > influence > > > them. > > > > > > > There has been nothing about this internally at DS > > > > > > I would ask that you refrain from making such claims, unless > you can > > be > > > certain that you would have been privy to all such internal > > discussions. > > > > > > > there's really no reason not to assume best intentions here > > > > > > This is a recurring taking point, that I wish we would retire > except > > where > > > a clear assumption of bad faith has been made. If you are > > criticised, it > > > is often because of the action you took; any intention you had > may be >
Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)
Characterizing alternate or conflicting points of view as assuming bad intentions without justification is both unproductive and unhealthy for the project. > On Jul 20, 2020, at 9:14 AM, Joshua McKenzie wrote: > > This kind of back and forth isn't productive for the project so I'm not > taking this discussion further. Just want to call it out here so you or > others aren't left waiting for a reply. > > We can agree to disagree. > > On Mon, Jul 20, 2020 at 11:59 AM Benedict Elliott Smith > wrote: > >> Firstly, that is a very strong claim that in this particular case is >> disputed by the facts. You made a very specific claim that the delay was >> "risking our currently lined up coordination with journalists and other >> channels". I am not the only person to interpret this as implying >> coordination with journalists, contingent on a release schedule not agreed >> by the PMC. This was based on semantics only; as far as I can tell, no >> intentions or assumptions have entered into this debate, except on your >> part. >> >>> Which is the definition of not assuming positive intent. >> >> Secondly, this is not the definition of positive intent. Positive intent >> only indicates that you "mean well" >> >> Thirdly, in many recent disputes about governance, you have made a >> negative claim about my behaviour, or ascribed negative connotations to >> statements I have made; this is a very thinly veiled example, as I am >> clearly the object of this criticism. I think it has reached a point where >> I can perhaps legitimately claim that you are not assuming positive intent? >> >>> motives, incentives ... little to do with reality >> >> It feels like we should return to this earlier discussion, since you >> appear to feel it is incomplete? At the very least you seem to have taken >> the wrong message from my statements, and it is perhaps negatively >> colouring our present interactions. >> >> >> On 20/07/2020, 15:59, "Joshua McKenzie" wrote: >> >>> >>> If you are criticised, it is often because of the action you took; >> >>Actually, in this case and many others it's because of people's >> unfounded >>assumptions about motives, incentives, and actions taken and has >> little to >>do with reality. Which is the definition of not assuming positive >> intent. >> >>On Mon, Jul 20, 2020 at 10:41 AM Benedict Elliott Smith < >> bened...@apache.org> >>wrote: >> >>> Thanks Sally, really appreciate your insight. >>> >>> To respond to the community discourse around this: >>> Keep your announcement plans ... private: limit discussions to the >> PMC >>> >>> This is all that I was asking and expecting: if somebody is making >>> commitments on behalf of the community (such as that a release can be >>> expected on day X), this should be coordinated with the PMC. While >> it >>> seems to transpire that no such commitments were made, had they been >> made >>> without the knowledge of the PMC this would in my view be >> problematic. >>> This is not at all like development work, as has been alleged, since >> that >>> only takes effect after public agreement by the community. >>> >>> IMO, in general, public engagements should be run past the PMC as a >> final >>> pre-flight check regardless of any commitment being made, as the PMC >> should >>> have visibility into these activities and have the opportunity to >> influence >>> them. >>> There has been nothing about this internally at DS >>> >>> I would ask that you refrain from making such claims, unless you can >> be >>> certain that you would have been privy to all such internal >> discussions. >>> there's really no reason not to assume best intentions here >>> >>> This is a recurring taking point, that I wish we would retire except >> where >>> a clear assumption of bad faith has been made. If you are >> criticised, it >>> is often because of the action you took; any intention you had may be >>> irrelevant to the criticism. In this case, when you act on behalf >> of the >>> community, your intentions are insufficient: you must have the >> community's >>> authority to act. >>> >>> >>> On 20/07/2020, 14:00, "Sally Khudairi" wrote: >>> >>>Hello everyone --Mick pinged me about this; I wanted to respond >>> on-list for efficacy. >>> >>>We've had dozens of companies successfully help Apache Projects >> and >>> their communities help spread the word on their projects with their >> PR and >>> marketing teams. Here are some best practices: >>> >>>1) Timing. Ensure that the Project has announced the project >> milestone >>> first to their lists as well as announce@ before any media coverage >> takes >>> place. If you're planning to time the announcements to take place in >>> tandem, be careful with embargoes, as not everyone is able to honor >> them. >>> We've been burned in the past with this. >>> >>>2) Messaging. Keep your announcement plans and draft press >> releases, >>> etc., private: limit disc
Re: [VOTE] Release Apache Cassandra 4.0-beta1 (take2)
+1 > On Jul 20, 2020, at 9:56 AM, Jon Haddad wrote: > > +1, thanks Mick for rerolling. > > On Mon, Jul 20, 2020 at 6:42 AM Joshua McKenzie > wrote: > >> +1 >> >> On Mon, Jul 20, 2020 at 8:51 AM Jake Luciani wrote: >> >>> +1 >>> >>> On Mon, Jul 20, 2020 at 8:08 AM Andrés de la Peña < >>> a.penya.gar...@gmail.com> >>> wrote: >>> +1 (nb) On Mon, 20 Jul 2020 at 12:58, João Reis >> wrote: > +1 (nb) > > The drivers smoke test suite looks good: > > > >>> >> https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34194004 > > Mick Semb Wever escreveu no dia sábado, 18/07/2020 >>> à(s) > 00:27: > >> 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 >> > >>> >>> >>> -- >>> http://twitter.com/tjake >>> >> - 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 (take2)
+1 On Mon, Jul 20, 2020 at 10:58 AM Blake Eggleston wrote: > +1 > > > On Jul 20, 2020, at 9:56 AM, Jon Haddad wrote: > > > > +1, thanks Mick for rerolling. > > > > On Mon, Jul 20, 2020 at 6:42 AM Joshua McKenzie > > wrote: > > > >> +1 > >> > >> On Mon, Jul 20, 2020 at 8:51 AM Jake Luciani wrote: > >> > >>> +1 > >>> > >>> On Mon, Jul 20, 2020 at 8:08 AM Andrés de la Peña < > >>> a.penya.gar...@gmail.com> > >>> wrote: > >>> > +1 (nb) > > On Mon, 20 Jul 2020 at 12:58, João Reis > >> wrote: > > > +1 (nb) > > > > The drivers smoke test suite looks good: > > > > > > > > >>> > >> > https://ci.appveyor.com/project/DataStax/cassandra-drivers-smoke-test/builds/34194004 > > > > Mick Semb Wever escreveu no dia sábado, 18/07/2020 > >>> à(s) > > 00:27: > > > >> 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 > >> > > > > >>> > >>> > >>> -- > >>> http://twitter.com/tjake > >>> > >> > > > - > 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 (take2)
> Proposing the test build of Cassandra 4.0-beta1 for release. > > sha1: 972da6fcffa87b3a1684362a2bab97db853372d8 > … > 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 The vote has passed with 4 non-binding +1 vote, 7 binding +1 votes, and no -1 votes.
Re: [DISCUSS] Revisiting Java 11's experimental status
Follow-up on the informal poll I did on twitter: https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21 Offered up as data to be used as you will. 161 votes <= JDK8: 59% JDK9 or 10: 7% JDK11 or 12: 27% JDK13 or 14: 7% On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp wrote: > Yea, ZGC is kinda tricky in 11. > > — > Robert Stupp > @snazy > > > On 14. Jul 2020, at 15:02, Jeff Jirsa wrote: > > > > Zgc > > > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote: > >> > >> > >>> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote: > >>> > >>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even > prod ready in jdk11 , so what’s the motivation and what does the project > gain from revisiting the experimental designation on jdk11? > >> > >> Can you elaborate on what’s not even prod ready in Java 11? > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > >
[RELEASE] Apache Cassandra 4.0-beta1 released
The Cassandra team is pleased to announce the release of Apache Cassandra version 4.0-beta1. Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. http://cassandra.apache.org/ Downloads of source and binary distributions are listed in our download section: http://cassandra.apache.org/download/ This version is a beta release[1] on the 4.0 series. As always, please pay attention to the release notes[2] and let us know[3] if you were to encounter any problem. Enjoy! And check out our blog post on Cassandra 4.0 beta1 https://cassandra.apache.org/blog/2020/07/20/apache-cassandra-4-0-beta1.html [1]: CHANGES.txt https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-beta1 [2]: NEWS.txt https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-beta1 [3]: https://issues.apache.org/jira/browse/CASSANDRA - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Revisiting Java 11's experimental status
I still dont get it, because you can't use any released version of cassandra with anything other than jdk8. On Mon, Jul 20, 2020 at 2:50 PM Patrick McFadin wrote: > Follow-up on the informal poll I did on twitter: > https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21 > > Offered up as data to be used as you will. > > 161 votes > <= JDK8: 59% > JDK9 or 10: 7% > JDK11 or 12: 27% > JDK13 or 14: 7% > > > > On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp wrote: > > > Yea, ZGC is kinda tricky in 11. > > > > — > > Robert Stupp > > @snazy > > > > > On 14. Jul 2020, at 15:02, Jeff Jirsa wrote: > > > > > > Zgc > > > > > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote: > > >> > > >> > > >>> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote: > > >>> > > >>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even > > prod ready in jdk11 , so what’s the motivation and what does the project > > gain from revisiting the experimental designation on jdk11? > > >> > > >> Can you elaborate on what’s not even prod ready in Java 11? > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > >
Re: [DISCUSS] Revisiting Java 11's experimental status
I believe you can run them on 11, but you can't build them on it. On Mon, Jul 20, 2020 at 6:11 PM Jeff Jirsa wrote: > > I still dont get it, because you can't use any released version of > cassandra with anything other than jdk8. > > > > On Mon, Jul 20, 2020 at 2:50 PM Patrick McFadin wrote: > > > Follow-up on the informal poll I did on twitter: > > https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21 > > > > Offered up as data to be used as you will. > > > > 161 votes > > <= JDK8: 59% > > JDK9 or 10: 7% > > JDK11 or 12: 27% > > JDK13 or 14: 7% > > > > > > > > On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp wrote: > > > > > Yea, ZGC is kinda tricky in 11. > > > > > > — > > > Robert Stupp > > > @snazy > > > > > > > On 14. Jul 2020, at 15:02, Jeff Jirsa wrote: > > > > > > > > Zgc > > > > > > > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote: > > > >> > > > >> > > > >>> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote: > > > >>> > > > >>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even > > > prod ready in jdk11 , so what’s the motivation and what does the project > > > gain from revisiting the experimental designation on jdk11? > > > >> > > > >> Can you elaborate on what’s not even prod ready in Java 11? > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Revisiting Java 11's experimental status
Got it, thanks for the correction. On Mon, Jul 20, 2020 at 4:28 PM Brandon Williams wrote: > I believe you can run them on 11, but you can't build them on it. > > On Mon, Jul 20, 2020 at 6:11 PM Jeff Jirsa wrote: > > > > I still dont get it, because you can't use any released version of > > cassandra with anything other than jdk8. > > > > > > > > On Mon, Jul 20, 2020 at 2:50 PM Patrick McFadin > wrote: > > > > > Follow-up on the informal poll I did on twitter: > > > https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21 > > > > > > Offered up as data to be used as you will. > > > > > > 161 votes > > > <= JDK8: 59% > > > JDK9 or 10: 7% > > > JDK11 or 12: 27% > > > JDK13 or 14: 7% > > > > > > > > > > > > On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp wrote: > > > > > > > Yea, ZGC is kinda tricky in 11. > > > > > > > > — > > > > Robert Stupp > > > > @snazy > > > > > > > > > On 14. Jul 2020, at 15:02, Jeff Jirsa wrote: > > > > > > > > > > Zgc > > > > > > > > > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote: > > > > >> > > > > >> > > > > >>> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote: > > > > >>> > > > > >>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t > even > > > > prod ready in jdk11 , so what’s the motivation and what does the > project > > > > gain from revisiting the experimental designation on jdk11? > > > > >> > > > > >> Can you elaborate on what’s not even prod ready in Java 11? > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] Revisiting Java 11's experimental status
That's remarkably close to the jrebel results for 2020: https://www.jrebel.com/blog/2020-java-technology-report#java-version Came across this this past weekend doing unrelated research; can't vouch for the accuracy / methods / etc. On Mon, Jul 20, 2020 at 7:32 PM Jeff Jirsa wrote: > Got it, thanks for the correction. > > > On Mon, Jul 20, 2020 at 4:28 PM Brandon Williams wrote: > > > I believe you can run them on 11, but you can't build them on it. > > > > On Mon, Jul 20, 2020 at 6:11 PM Jeff Jirsa wrote: > > > > > > I still dont get it, because you can't use any released version of > > > cassandra with anything other than jdk8. > > > > > > > > > > > > On Mon, Jul 20, 2020 at 2:50 PM Patrick McFadin > > wrote: > > > > > > > Follow-up on the informal poll I did on twitter: > > > > https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21 > > > > > > > > Offered up as data to be used as you will. > > > > > > > > 161 votes > > > > <= JDK8: 59% > > > > JDK9 or 10: 7% > > > > JDK11 or 12: 27% > > > > JDK13 or 14: 7% > > > > > > > > > > > > > > > > On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp wrote: > > > > > > > > > Yea, ZGC is kinda tricky in 11. > > > > > > > > > > — > > > > > Robert Stupp > > > > > @snazy > > > > > > > > > > > On 14. Jul 2020, at 15:02, Jeff Jirsa wrote: > > > > > > > > > > > > Zgc > > > > > > > > > > > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp > wrote: > > > > > >> > > > > > >> > > > > > >>> On 14. Jul 2020, at 07:33, Jeff Jirsa > wrote: > > > > > >>> > > > > > >>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t > > even > > > > > prod ready in jdk11 , so what’s the motivation and what does the > > project > > > > > gain from revisiting the experimental designation on jdk11? > > > > > >> > > > > > >> Can you elaborate on what’s not even prod ready in Java 11? > > > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: [DISCUSS] Revisiting Java 11's experimental status
The same link was posted earlier also. For Java 8 and 11 the poll result is very similar. Java 8 =58.4%Java 11 =22.56% On Monday, July 20, 2020, 04:38:03 p.m. PDT, Joshua McKenzie wrote: That's remarkably close to the jrebel results for 2020: https://www.jrebel.com/blog/2020-java-technology-report#java-version Came across this this past weekend doing unrelated research; can't vouch for the accuracy / methods / etc. On Mon, Jul 20, 2020 at 7:32 PM Jeff Jirsa wrote: > Got it, thanks for the correction. > > > On Mon, Jul 20, 2020 at 4:28 PM Brandon Williams wrote: > > > I believe you can run them on 11, but you can't build them on it. > > > > On Mon, Jul 20, 2020 at 6:11 PM Jeff Jirsa wrote: > > > > > > I still dont get it, because you can't use any released version of > > > cassandra with anything other than jdk8. > > > > > > > > > > > > On Mon, Jul 20, 2020 at 2:50 PM Patrick McFadin > > wrote: > > > > > > > Follow-up on the informal poll I did on twitter: > > > > https://twitter.com/patrickmcfadin/status/1282791302065557504?s=21 > > > > > > > > Offered up as data to be used as you will. > > > > > > > > 161 votes > > > > <= JDK8: 59% > > > > JDK9 or 10: 7% > > > > JDK11 or 12: 27% > > > > JDK13 or 14: 7% > > > > > > > > > > > > > > > > On Wed, Jul 15, 2020 at 3:19 AM Robert Stupp wrote: > > > > > > > > > Yea, ZGC is kinda tricky in 11. > > > > > > > > > > — > > > > > Robert Stupp > > > > > @snazy > > > > > > > > > > > On 14. Jul 2020, at 15:02, Jeff Jirsa wrote: > > > > > > > > > > > > Zgc > > > > > > > > > > > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp > wrote: > > > > > >> > > > > > >> > > > > > >>> On 14. Jul 2020, at 07:33, Jeff Jirsa > wrote: > > > > > >>> > > > > > >>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t > > even > > > > > prod ready in jdk11 , so what’s the motivation and what does the > > project > > > > > gain from revisiting the experimental designation on jdk11? > > > > > >> > > > > > >> Can you elaborate on what’s not even prod ready in Java 11? > > > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
