Re: Drivers support for Cassandra 4.0
Do people think it would be a good idea to upgrade to the latest Cassandra Java Driver that is being used internally before 4.0 gets out? I created https://issues.apache.org/jira/browse/CASSANDRA-15750 for that just in case. On Fri, Apr 10, 2020 at 7:48 PM Jon Haddad wrote: > Love it - thanks for the update Alex! I agree with Jordan this will be a > big help with 4.0 adoption. > > Jon > > > > On Fri, Apr 10, 2020 at 10:40 AM Jordan West wrote: > > > On Thu, Apr 9, 2020 at 7:30 AM Alexandre Dutra < > > alexandre.du...@datastax.com> > > wrote: > > > > > * Java drivers 3.9.0 and 4.6.0 will be released in the next few weeks. > > > They will include > > > support for missing features (transient replication and > > > now-in-seconds), effectively > > > providing complete support for protocol v5 in its current state. To > > > make it as easy as > > > possible for users to adopt C* 4.0, we decided to release both major > > > branches of the Java > > > driver, including 3.x, even if this branch is now in maintenance mode. > > > > > > > > This is great to hear and I think will be a big benefit to 4.0 adoption. > > > > Thanks for the update! > > Jordan > > >
Re: Meeting notes and recording from today's meeting
As a quick follow up to the DockerHub portion of that discussion, this morning I checked in with one of the TinkerPop PMC members who also happens to be on Apache infra and he confirmed that the Distribution Guidelines draft: https://cwiki.apache.org/confluence/display/incubator/DistributionGuidelines remains the most recent thinking on this topic though discussion is ongoing on the infra mailing list apparently (and perhaps elsewhere...) as to how to refine this all into something official. That said, given that this topic is ages old already (ages old generally speaking, and at least a year old with DockerHub specifically), waiting for something official would probably take a while. On Tue, Apr 21, 2020 at 8:46 PM Patrick McFadin wrote: > Hi everyone, > > Here are the notes and video recording from today's meeting: > > https://cwiki.apache.org/confluence/display/CASSANDRA/2020-04-21+Apache+Cassandra+Contributor+Meeting > > I updated the meeting details with an ICS to import into your own calendar > to make it easy to schedule. > > https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting > > Thanks! > > Patrick >
Re: Simplify voting rules for in-jvm-dtest-api releases
+1 to jitpack On Fri, Apr 17, 2020 at 8:50 AM Oleksandr Petrov wrote: > Thank you for suggestions, Jeremiah! > > I first really liked the idea of jitpack since I thought it clones > repository and builds stuff locally. However, it seems like they build on > their machines in docker container. While this is something that could be > useful in many cases, I think just using snapshots with hash would yield a > similar result. > > Another suggestion from Jeremiah was to use submodules, which could be > helpful for IDE. We can explore this in future, I just do not have capacity > at the moment to figure out how to make sure it all builds with ant to make > it work nicely for developers. > > @Nate McCall I've added some information about > deployment to readme file [1], and have also posted how to build a snapshot > [2]. I'll add information about the length of vote with a reference to this > mailing list discussion for history. > > -- Alex > > > [1] > https://github.com/apache/cassandra-in-jvm-dtest-api/blob/master/README.md > [2] > > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/29d055b7cffc66a852505660930c980c185138a1 > > > On Fri, Apr 17, 2020 at 1:34 AM J. D. Jordan > wrote: > > > I was taking with Alex on slack earlier today brainstorming ideas and two > > that might work are using a git submodule to reference the code by git > > hash, so no release needed, or using jitpack.io to be able to pull the > > jar down by git hash without doing a release. > > > > Does anyone find either of those options more appealing than 1/2/3? > > > > -Jeremiah > > > > > On Apr 16, 2020, at 6:14 PM, David Capwell wrote: > > > > > > Not a fan of 2 or 3. For #2 there is also talk about getting rid of > the > > > jars in /lib so that would complicate things. > > > > > > I think frequent releases with snapshots per commit is good. Agree > with > > > Nate we should document this so we have something we can always point > to. > > > > > >> On Thu, Apr 16, 2020 at 2:54 PM Nate McCall > wrote: > > >> > > >> (1) sounds reasonable to me. I'd like us to document the vote cycle > and > > >> release train specifics on cassandra.a.o somewhere (developer and > > releases > > >> pages maybe?). Nothing exhaustive, just 'we do X with Y'. > > >> > > >> > > >> On Thu, Apr 16, 2020 at 11:03 PM Oleksandr Petrov < > > >> oleksandr.pet...@gmail.com> wrote: > > >> > > >>> I've posted the question on the legal-discussion mailing list, and > got > > >> some > > >>> helpful responses. > > >>> > > >>> We can't work around the vote, best we can do is make it shorter (3 > +1 > > >>> votes / 24 hours). We have several options now: > > >>> > > >>> 1. Release SNAPSHOT builds prefixed with in-jvm dtest commit SHAs and > > cut > > >>> release every week or so (release-train if you wish) > > >>> 2. Avoid using Apache repository for releases altogether, and just > push > > >>> jars to Cassandra repository > > >>> 3. Make this code "unofficial" (publish and manage outside Apache) > > >>> > > >>> I'm not a big fan of (2), since we already tried that with Python and > > >> Java > > >>> drivers, also I'm not sure about binaries in git. As regards (3), I'm > > not > > >>> sure if this makes it harder for the folks who rely on Apache legal > > >>> framework for contributions. > > >>> > > >>> Unless there are strong opinions against (1), which seems to be a > > >>> reasonable middle ground, we can do it. Please let me know if you > also > > >> have > > >>> other ideas. > > >>> > > >>> Thank you, > > >>> -- Alex > > >>> > > >>> On Wed, Apr 15, 2020 at 10:33 PM Jeremiah D Jordan < > > >> jerem...@datastax.com> > > >>> wrote: > > >>> > > I think as long as we don’t publish the artifacts to maven central > or > > >>> some > > other location that is for “anyone” we do not need a formal release. > > >> Even > > then since the artifact is only meant for use by people developing > C* > > >>> that > > might be fine. > > > > If artifacts are only for use by individuals actively participating > in > > >>> the > > development process, then no formal release is needed. See the > > >>> definition > > of “release” and “publication” found here: > > > > http://www.apache.org/legal/release-policy.html#release-definition > > > DEFINITION OF "RELEASE" < > > http://www.apache.org/legal/release-policy.html#release-definition> > > > Generically, a release is anything that is published beyond the > group > > that owns it. For an Apache project, that means any publication > > outside > > >>> the > > development community, defined as individuals actively participating > > in > > development or following the dev list. > > > > > > More narrowly, an official Apache release is one which has been > > >>> endorsed > > as an "act of the Foundation" by a PMC. > > > > > > > > > > > PUBLICATION < > > >>> http://www.apache.org/legal/release-policy.html#publication > > > >
Discussion: addition to CEP guide
Link to CEP guide: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 Currently the CEP guide reads: --- *A CEP should contain the following sections: * - *Scope,* - *Goals (and non-goals),* - *Description of Approach,* - *Timeline,* - *Mailing list / Slack channels,* - *Related JIRA tickets.* -- What does everyone think about adding another bullet item as follows: - A test plan covering performance, correctness, failure, and boundary conditions (as applicable) -- Or some variation thereof. I personally think it's worth calling out "We should think about and discuss how we're going to test something from a high level collectively before we dive into it", since we've had some pain in the past in that area. Thoughts?
Re: Discussion: addition to CEP guide
+1. This might also serve to produce specific points of discussion around the topic as the CEP progresses. Maybe put it high up the list, e.g. after Description of Approach? On 22/04/2020, 17:40, "Joshua McKenzie" wrote: Link to CEP guide: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 Currently the CEP guide reads: --- *A CEP should contain the following sections: * - *Scope,* - *Goals (and non-goals),* - *Description of Approach,* - *Timeline,* - *Mailing list / Slack channels,* - *Related JIRA tickets.* -- What does everyone think about adding another bullet item as follows: - A test plan covering performance, correctness, failure, and boundary conditions (as applicable) -- Or some variation thereof. I personally think it's worth calling out "We should think about and discuss how we're going to test something from a high level collectively before we dive into it", since we've had some pain in the past in that area. Thoughts? - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Discussion: addition to CEP guide
Great idea Josh, +1 On Wed, Apr 22, 2020 at 9:47 AM Benedict Elliott Smith wrote: > +1. This might also serve to produce specific points of discussion around > the topic as the CEP progresses. > > Maybe put it high up the list, e.g. after Description of Approach? > > > > On 22/04/2020, 17:40, "Joshua McKenzie" wrote: > > Link to CEP guide: > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 > > Currently the CEP guide reads: > --- > > *A CEP should contain the following sections: * > >- > >*Scope,* >- > >*Goals (and non-goals),* >- > >*Description of Approach,* >- > >*Timeline,* >- > >*Mailing list / Slack channels,* >- > >*Related JIRA tickets.* > > -- > What does everyone think about adding another bullet item as follows: > >- A test plan covering performance, correctness, failure, and > boundary >conditions (as applicable) > > -- > Or some variation thereof. I personally think it's worth calling out > "We > should think about and discuss how we're going to test something from a > high level collectively before we dive into it", since we've had some > pain > in the past in that area. > > Thoughts? > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
DataStax Driver Donation to Apache Cassandra Project
The developers who maintain the DataStax drivers would like to start a conversation about donating these drivers to the Apache Cassandra project. Since we're actively working on the C* 4.0 support and integration in the drivers right now, we don't plan on executing on this until after C* 4.0 releases in order to avoid delaying the release. In the meantime we wanted to open the discussion so that we can all determine what we think best suits the project going forward. There are a number of details we would like to discuss as a project community. Naming a few to get the discussion going: - Is there interest from the project community to take ownership of the (currently) DataStax drivers? - Which drivers should be taken into project stewardship? -- The project currently bundles Java and Python; there are five others: C#, Node.js, C++, PHP and Ruby - Which major branch of the Java driver should be chosen for development? -- Server currently uses Java driver 3.x but the latest is 4.x - Who will be the committers that maintain these drivers? Should we nominate new committers (contributors on the current drivers code-bases) so they can keep maintaining them with minimal disruption to the project as a whole? - What should the new artifacts be named in package indices (coordinates and artifact names)? - How will we run CI for these contributions? - Do we do in-tree? Sub-projects? There will surely be even more to figure out as we go. We look forward to discussing this with everyone. Kind regards, The DS Drivers Team
Re: DataStax Driver Donation to Apache Cassandra Project
Hi Adam, Great to hear from you! I personally welcome the driver donation. My views are inline below. Thanks, Dinesh > On Apr 22, 2020, at 10:00 AM, Adam Holmberg > wrote: > - Which drivers should be taken into project stewardship? > -- The project currently bundles Java and Python; there are five others: > C#, Node.js, C++, PHP and Ruby Java and Python at least. > - Which major branch of the Java driver should be chosen for development? > -- Server currently uses Java driver 3.x but the latest is 4.x No opinions here. What are the major differences here? Could you please elaborate. > - Who will be the committers that maintain these drivers? Should we > nominate new committers (contributors on the current drivers code-bases) so > they can keep maintaining them with minimal disruption to the project as a > whole? I generally think people who have built the code base should become committers to avoid disruption and allow continuity. > - What should the new artifacts be named in package indices (coordinates > and artifact names)? I am not completely sure but we may need to rename some packages but it would be really great if we could avoid breakages due to naming changes. > - How will we run CI for these contributions? ASF Jenkins/CircleCI works? Do the drivers have specific needs beyond this? > - Do we do in-tree? Sub-projects? sub-projects like cassandra-diff, sidecar, etc. This way drivers continue to evolve separately. > > There will surely be even more to figure out as we go. We look forward to > discussing this with everyone. > > Kind regards, > The DS Drivers Team - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: DataStax Driver Donation to Apache Cassandra Project
I welcome the donation, and hope we are able to accept all of the drivers. This is really great news IMO. I do however wonder if the project may be accumulating too many sub-projects? I wonder if it's time to think about splitting, and perhaps incubating a project for the drivers? On 22/04/2020, 18:20, "Dinesh Joshi" wrote: Hi Adam, Great to hear from you! I personally welcome the driver donation. My views are inline below. Thanks, Dinesh > On Apr 22, 2020, at 10:00 AM, Adam Holmberg wrote: > - Which drivers should be taken into project stewardship? > -- The project currently bundles Java and Python; there are five others: > C#, Node.js, C++, PHP and Ruby Java and Python at least. > - Which major branch of the Java driver should be chosen for development? > -- Server currently uses Java driver 3.x but the latest is 4.x No opinions here. What are the major differences here? Could you please elaborate. > - Who will be the committers that maintain these drivers? Should we > nominate new committers (contributors on the current drivers code-bases) so > they can keep maintaining them with minimal disruption to the project as a > whole? I generally think people who have built the code base should become committers to avoid disruption and allow continuity. > - What should the new artifacts be named in package indices (coordinates > and artifact names)? I am not completely sure but we may need to rename some packages but it would be really great if we could avoid breakages due to naming changes. > - How will we run CI for these contributions? ASF Jenkins/CircleCI works? Do the drivers have specific needs beyond this? > - Do we do in-tree? Sub-projects? sub-projects like cassandra-diff, sidecar, etc. This way drivers continue to evolve separately. > > There will surely be even more to figure out as we go. We look forward to > discussing this with everyone. > > Kind regards, > The DS Drivers Team - 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: Discussion: addition to CEP guide
Sounds good to me as well, thanks for suggesting. From: Jon Haddad Sent: Wednesday, April 22, 2020 9:54 AM To: dev@cassandra.apache.org Subject: Re: Discussion: addition to CEP guide Great idea Josh, +1 On Wed, Apr 22, 2020 at 9:47 AM Benedict Elliott Smith wrote: > +1. This might also serve to produce specific points of discussion around > the topic as the CEP progresses. > > Maybe put it high up the list, e.g. after Description of Approach? > > > > On 22/04/2020, 17:40, "Joshua McKenzie" wrote: > > Link to CEP guide: > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 > > Currently the CEP guide reads: > --- > > *A CEP should contain the following sections: * > >- > >*Scope,* >- > >*Goals (and non-goals),* >- > >*Description of Approach,* >- > >*Timeline,* >- > >*Mailing list / Slack channels,* >- > >*Related JIRA tickets.* > > -- > What does everyone think about adding another bullet item as follows: > >- A test plan covering performance, correctness, failure, and > boundary >conditions (as applicable) > > -- > Or some variation thereof. I personally think it's worth calling out > "We > should think about and discuss how we're going to test something from a > high level collectively before we dive into it", since we've had some > pain > in the past in that area. > > Thoughts? > > > > > - > 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: Discussion: addition to CEP guide
> > Maybe put it high up the list, e.g. after Description of Approach? Really great point. Definitely not the lowest priority item. I'll leave this thread open for another 24 or 48 for feedback; if noncontroversial I'll edit then. On Wed, Apr 22, 2020 at 1:45 PM Scott Andreas wrote: > Sounds good to me as well, thanks for suggesting. > > > From: Jon Haddad > Sent: Wednesday, April 22, 2020 9:54 AM > To: dev@cassandra.apache.org > Subject: Re: Discussion: addition to CEP guide > > Great idea Josh, +1 > > On Wed, Apr 22, 2020 at 9:47 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > +1. This might also serve to produce specific points of discussion > around > > the topic as the CEP progresses. > > > > Maybe put it high up the list, e.g. after Description of Approach? > > > > > > > > On 22/04/2020, 17:40, "Joshua McKenzie" wrote: > > > > Link to CEP guide: > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 > > > > Currently the CEP guide reads: > > --- > > > > *A CEP should contain the following sections: * > > > >- > > > >*Scope,* > >- > > > >*Goals (and non-goals),* > >- > > > >*Description of Approach,* > >- > > > >*Timeline,* > >- > > > >*Mailing list / Slack channels,* > >- > > > >*Related JIRA tickets.* > > > > -- > > What does everyone think about adding another bullet item as follows: > > > >- A test plan covering performance, correctness, failure, and > > boundary > >conditions (as applicable) > > > > -- > > Or some variation thereof. I personally think it's worth calling out > > "We > > should think about and discuss how we're going to test something > from a > > high level collectively before we dive into it", since we've had some > > pain > > in the past in that area. > > > > Thoughts? > > > > > > > > > > - > > 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: DataStax Driver Donation to Apache Cassandra Project
On Thu, Apr 23, 2020 at 5:37 AM Benedict Elliott Smith wrote: > I welcome the donation, and hope we are able to accept all of the > drivers. This is really great news IMO. > > I do however wonder if the project may be accumulating too many > sub-projects? I wonder if it's time to think about splitting, and perhaps > incubating a project for the drivers? > This is a legit concern and good question, but I think this is more a natural evolution of growing a project. There is precedent for this in Spark, Beam, Hadoop and others who have a number of different repositories under the general project umbrella. What I would like to avoid is a situation like with Apache Curator and Apache Zookeeper. The former being a zookeeper client donation from Netflix that came in as a top level project. From the peanut gallery, it seems like that has been less than ideal a couple of times in the past coordinating releases, trademarks and such with separate project management.
Re: DataStax Driver Donation to Apache Cassandra Project
It would probably be a good idea to get some outside guidance on what other projects have seen because like what Nate said, this isn't the first time. https://felix.apache.org/documentation/subprojects.html https://cocoon.apache.org/subprojects/ Commons has components: http://commons.apache.org/components.html Hadoop, as mentioned, has modules. Patrick On Wed, Apr 22, 2020 at 1:25 PM Nate McCall wrote: > On Thu, Apr 23, 2020 at 5:37 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > I welcome the donation, and hope we are able to accept all of the > > drivers. This is really great news IMO. > > > > I do however wonder if the project may be accumulating too many > > sub-projects? I wonder if it's time to think about splitting, and > perhaps > > incubating a project for the drivers? > > > > This is a legit concern and good question, but I think this is more a > natural evolution of growing a project. There is precedent for this in > Spark, Beam, Hadoop and others who have a number of different repositories > under the general project umbrella. > > What I would like to avoid is a situation like with Apache Curator and > Apache Zookeeper. The former being a zookeeper client donation from Netflix > that came in as a top level project. From the peanut gallery, it seems like > that has been less than ideal a couple of times in the past coordinating > releases, trademarks and such with separate project management. >
Re: Kubernetes Operator SIG Zoom
Just a reminder for everyone. We have two Kubernetes meeting over the next 12 hours. Same format as before. Zoom link and calendar invites with times can be found here: https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Kubernetes+Operator+SIG Franck has brought up an excellent point about combining meetings. That will be a discussion item for these meetings and if we can combine them and still be inclusive for many timezones. Ben and I will discuss the CEP draft we have been working on and let everyone jump in and start working this out together. Patrick On Mon, Apr 20, 2020 at 2:48 AM wrote: > Hi everyone, > > Thanks Patrick for a difficult job at animating these meetings. > I have watched the first meeting and I now am quite sure we should have > only one meeting instead of 2. I was pleased to hear things about CassKop > and we could have replied on the spot. > > Personally I had no trouble watching good old apple keynotes when they > were help at 10 am SF time, may be we could have our C* operator “keynote" > at the same time or close? > > There didn’t seem to be that many people from Asia in the first call but I > may be mistaken > > Just my 2 cents :) > > Franck > > PS: I have not found the CEP where I would like to express our position. > Spoiler: casskop code is available for anyone who wants it (support > included) and it has nothing Orange specific :) > > > franck.de...@orange.com > Casskop Product Owner > https://github.com/Orange-OpenSource/casskop > > > > > On 15 Apr 2020, at 02:17, Patrick McFadin wrote: > > > > Hi everyone, > > > > A little late, but wanted to update post meeting. Here are the notes and > > videos from our meetings last week: > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=148646938 > > > > The first action item from this meeting is creating the CEP to gather > > feedback. Ben Bromhead and myself will start that process which will live > > in the Cassandra cwiki for everyone to contribute. There was also > consensus > > on having bi-weekly meetings at the same times which I will schedule. > > > > Thanks to everyone who participated! > > > > Patrick > > > > On Mon, Apr 6, 2020 at 2:25 PM Patrick McFadin > wrote: > > > >> Hi, > >> > >> I have sorted out the time zones and got the initial Kubernetes Operator > >> zoom call on the calendar. All of it is documented here: > >> > https://cwiki.apache.org/confluence/display/CASSANDRA/Kubernetes+Operator+SIG+Meeting > >> > >> Meeting 1(APAC/Western US Friendly) > >> > >> San Francisco: April 8, 5:00PM > >> > >> Singapore: April 9, 8:00AM > >> > >> Tokyo: April 9, 9:00AM > >> > >> Sydney: April 9, 10:00AM > >> > >> New Zealand: April 9, 12:00PM > >> > >> iCAL link > >> < > https://calendar.google.com/event?action=TEMPLATE&tmeid=N2M2Z2xnZ3Nha3ZyMHIwbWxrazRqcG1jcXYga2w5cHVoZ2s3cXRkdXFhdHRlOHRmZDVtcHNAZw&tmsrc=kl9puhgk7qtduqatte8tfd5mps%40group.calendar.google.com > > > >> Meeting 2(CEST/Eastern US Friendly) > >> > >> San Francisco: April 9, 7:00 AM > >> > >> New York: April 9, 10:00AM > >> > >> London: April 9, 3:00PM > >> > >> Paris: April 9, 4:00PM > >> > >> Berlin: April 9, 4:00PM > >> > >> iCal Link > >> < > https://calendar.google.com/event?action=TEMPLATE&tmeid=NjdhampnbGc4ZHFocnRtZ2diaGEyanZhNGsga2w5cHVoZ2s3cXRkdXFhdHRlOHRmZDVtcHNAZw&tmsrc=kl9puhgk7qtduqatte8tfd5mps%40group.calendar.google.com > > > >> I will also be sharing this link on social media to help get the word > out > >> to the larger community. I feel like we have a great opportunity to > invite > >> a lot of new people. > >> > >> Any discussion topics can be sent directly to me, I'll gather and > document > >> before each meeting. > >> > >> Thanks! > >> > >> Patrick > >> > > > > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > >
Re: Discussion: addition to CEP guide
+1 (nb) on both counts. Thanks for bringing this up! Jordan On Wed, Apr 22, 2020 at 11:53 AM Joshua McKenzie wrote: > > > > Maybe put it high up the list, e.g. after Description of Approach? > > Really great point. Definitely not the lowest priority item. > > I'll leave this thread open for another 24 or 48 for feedback; if > noncontroversial I'll edit then. > > On Wed, Apr 22, 2020 at 1:45 PM Scott Andreas > wrote: > > > Sounds good to me as well, thanks for suggesting. > > > > > > From: Jon Haddad > > Sent: Wednesday, April 22, 2020 9:54 AM > > To: dev@cassandra.apache.org > > Subject: Re: Discussion: addition to CEP guide > > > > Great idea Josh, +1 > > > > On Wed, Apr 22, 2020 at 9:47 AM Benedict Elliott Smith < > > bened...@apache.org> > > wrote: > > > > > +1. This might also serve to produce specific points of discussion > > around > > > the topic as the CEP progresses. > > > > > > Maybe put it high up the list, e.g. after Description of Approach? > > > > > > > > > > > > On 22/04/2020, 17:40, "Joshua McKenzie" wrote: > > > > > > Link to CEP guide: > > > > > > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201 > > > > > > Currently the CEP guide reads: > > > --- > > > > > > *A CEP should contain the following sections: * > > > > > >- > > > > > >*Scope,* > > >- > > > > > >*Goals (and non-goals),* > > >- > > > > > >*Description of Approach,* > > >- > > > > > >*Timeline,* > > >- > > > > > >*Mailing list / Slack channels,* > > >- > > > > > >*Related JIRA tickets.* > > > > > > -- > > > What does everyone think about adding another bullet item as > follows: > > > > > >- A test plan covering performance, correctness, failure, and > > > boundary > > >conditions (as applicable) > > > > > > -- > > > Or some variation thereof. I personally think it's worth calling > out > > > "We > > > should think about and discuss how we're going to test something > > from a > > > high level collectively before we dive into it", since we've had > some > > > pain > > > in the past in that area. > > > > > > Thoughts? > > > > > > > > > > > > > > > - > > > 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: Staging website at cassandra.staged.apache.org
Thanks Mick, if there documentation somewhere on how we update the website ? A - Aaron Morton New Zealand @aaronmorton CEO Apache Cassandra Consulting http://www.thelastpickle.com On Tue, 21 Apr 2020 at 18:40, Mick Semb Wever wrote: > For our cassandra-website repository, any changes to our website can now > first be staged at https://cassandra.staged.apache.org/ > > The staged website comes from the content/ directory on the `asf-staging` > branch. > > regards, > Mick >
Re: Staging website at cassandra.staged.apache.org
There's instructions on https://github.com/apache/cassandra-website which I found out from Mick earlier this week. Cheers!
