Ideas for Cassandra 2020 - Remote Meetups / Mastermind
Folks, (Initially meant for User , but realized after I wrote it , it’s more sausage making talk which en users probably don’t care about) I took on a bunch of work and finally starting to get my head out of the sand and realized I failed to deliver on some promises last year I made to myself and others to contribute to this community. I wanted to resurface a few thoughts on which I would like to contribute. We had a conversation on here a while ago to try doing a virtual conference.. which I think is a bit too ambitious. I also spoke to Dinesh last year briefly about doing periodic development meetings which focused on the development planning and execution. I’d like to help this project but I don’t know where to start. I tried getting some Jr. members internally at Anant who had time to make fixes on content and docs but it didn’t get looked at or reviewed so they lost interest. There’s only so much they would want to do based on my requests. The failure to deliver on better documentation organization was mainly mine because I didn’t commit enough time into it. I don’t think our community does a good enough job communicating the Cassandra value proposition to the enterprise community whether they are developers, architects, or directors. I’ve been meeting with many folks that haven’t touched their clusters since installing 2.1 (because it’s pretty damn good for most people!). When I ask them why, it’s a combination of team member churn but also because the knowledge is not as accessible. This year as January closes I am recommitting myself to some ideas and would LOVE your feedback. If somethings like this are in progress, I will help. 1. Cassandra Lunch - I’ve been seeing a colleague getting together with his fellow practitioners for a weekly “Sitecore Lunch” and I found it a very easy way to get people talking that normally wouldn’t be interacting with each other in realtime. 2. Coordinated Remote Meetup - I think this would be way easier to organize and get cross promoted as a quarterly event with the help of local organizers. I’m currently organizing DC / Chicago and have been cross promoting virtual talks to both and have gotten a good show with people curious about Cassandra. 3. Documentation - I know I said I’d help last year. I underestimated my free time and over estimated my capacity to focus. That being said , this is one of my passions and I help a lot of orgs get their [blank] together on how to manage their people, process, info and systems and the first thing is always knowledge management. If there’s someone I can shadow and apprentice under to help with Cassandra.Apache.org I really want to help revitalize our site. These may still be overestimating my capacity but I’m willing to fail and try again. :) rahul.xavier.si...@gmail.com http://cassandra.link The Apache Cassandra Knowledge Base.
Re: [CI] What are the troubles projects face with CI and Infra
Hey Rahul, I can double check on how to make use of the credits. Amazon MCS has already donated EC2 instances to be used for testing, and we are working with Mick to get them online. This effort doesn’t make use of credits, these instances are owned by my team and donated to the project. If there is another need I’m missing here, let me know. Cheers, Almero Sent from my iPhone > On Feb 8, 2020, at 19:34, Rahul Singh wrote: > > Related to instances, can we get those credits put to use that Amazon > promised to give back to the community as part of their Amazon Managed > Cassandra Service announcement? > > Alternatively if there is an appetite to set something in patreon or GitHub’s > donation platform , it may be a good way to get the things we need funded > based on what the community wants —- business driven demand. > > Thoughts? > > rahul.xavier.si...@gmail.com > > http://cassandra.link > The Apache Cassandra Knowledge Base. >> On Feb 3, 2020, 9:06 PM -0500, David Capwell , wrote: >> Following Mick's format =) >> >> ** Lack of trust (aka reliability) >> >> Mick said it best, but should also add that we have slow tests and tests >> which don't do anything. Effort is needed to improve our current tests and >> to make sure future tests are stable (cleaning up works, isolation, etc.); >> this is not a neglectable amount of work, nor work which can be done by a >> single person. >> >> ** Lack of resources (throughput and response) >> >> Our slowest unit tests are around 2 minutes (materialized views), our >> slowest dtests (not high resource) are around 30 minutes; given enough >> resources we could run unit in < 10 minutes and dtest in 30-60 minutes. >> >> There is also another thing to point out, testing is also a combinatorics >> problem; we support java 8/11 (more to come), vnode and no-vnode, security >> and no security, and the list goes on. Bugs are more likely to happen when >> two features interact, so it is important to test against many combinations. >> >> There is work going on in the community to add new kinds of tests (harry, >> diff, etc.); these tests require even more resources than normal tests. >> >> ** Difficulty in use >> >> Many people rely on CircleCI as the core CI for the project, but this has a >> few issues called out in other forms: the low resource version (free) is >> even more flaky than high (paid), and people get locked out (i have lost >> access twice so far, others have said the same). >> >> The thing which worries me the most is that new members to the project >> won't have the high resource CircleCI plan, nor do they really have access >> to Jenkins. This puts a burden on new authors where they wait 24+ hours to >> run the tests... or just not run them. >> >> ** Lack of visibility into quality >> >> This is two things for me: commit and pre-commit. >> >> For commit, this is more what Mick was referring to as "post-commit CI". >> There are a few questions I would like to know about our current tests >> (report most flaky tests, which sections of code cause the most failures, >> etc.); these are hard to answer at the moment . >> >> We don't have a good pre-commit story since it mostly relies on CircleCI. >> I find that some JIRAs link CircleCI and some don't. I find that if I >> follow the CircleCI link months later (to see if the build was stable >> pre-commit) that Circle fails to show the workflow. >> >> On Mon, Feb 3, 2020 at 3:42 PM Michael Shuler >> wrote: >> >>> Only have a moment to respond, but Mick hit the higlights with >>> containerization, parallelization, these help solve cleanup, speed, and >>> cascading failures. Dynamic disposable slaves would be icing on that >>> cake, which may require a dedicated master. >>> >>> One more note on jobs, or more correctly unnecessary jobs - pipelines >>> have a `changeset` build condition we should tinker with. There is zero >>> reason to run a job with no actual code diff. For instance, I committed >>> to 2.1 this morning and merged `-s ours` nothing to the newer branches - >>> there's really no reason to run and take up valuable resources with no >>> actual diff changes. >>> https://jenkins.io/doc/book/pipeline/syntax/#built-in-conditions >>> >>> Michael >>> >>> On 2/3/20 3:45 PM, Nate McCall wrote: Mick, this is fantastic! I'll wait another day to see if anyone else chimes in. (Would also love >>> to hear from CassCI folks, anyone else really who has wrestled with this >>> even for internal forks). On Tue, Feb 4, 2020 at 10:37 AM Mick Semb Wever wrote: > Nate, I leave it to you to forward what-you-chose to the board@'s >>> thread. > > >> Are there still troubles and what are they? > > > TL;DR > the ASF could provide the Cassandra community with an isolated >>> jenkins > installation: so that we can manage and control the Jenkins master, as > well as ensure all donated hardware for Jenkins agents
Re: Fwd: [CI] What are the troubles projects face with CI and Infra
Related to instances, can we get those credits put to use that Amazon promised to give back to the community as part of their Amazon Managed Cassandra Service announcement? Alternatively if there is an appetite to set something in patreon or GitHub’s donation platform , it may be a good way to get the things we need funded based on what the community wants —- business driven demand. Thoughts? rahul.xavier.si...@gmail.com http://cassandra.link The Apache Cassandra Knowledge Base. On Feb 3, 2020, 9:06 PM -0500, David Capwell , wrote: > Following Mick's format =) > > ** Lack of trust (aka reliability) > > Mick said it best, but should also add that we have slow tests and tests > which don't do anything. Effort is needed to improve our current tests and > to make sure future tests are stable (cleaning up works, isolation, etc.); > this is not a neglectable amount of work, nor work which can be done by a > single person. > > ** Lack of resources (throughput and response) > > Our slowest unit tests are around 2 minutes (materialized views), our > slowest dtests (not high resource) are around 30 minutes; given enough > resources we could run unit in < 10 minutes and dtest in 30-60 minutes. > > There is also another thing to point out, testing is also a combinatorics > problem; we support java 8/11 (more to come), vnode and no-vnode, security > and no security, and the list goes on. Bugs are more likely to happen when > two features interact, so it is important to test against many combinations. > > There is work going on in the community to add new kinds of tests (harry, > diff, etc.); these tests require even more resources than normal tests. > > ** Difficulty in use > > Many people rely on CircleCI as the core CI for the project, but this has a > few issues called out in other forms: the low resource version (free) is > even more flaky than high (paid), and people get locked out (i have lost > access twice so far, others have said the same). > > The thing which worries me the most is that new members to the project > won't have the high resource CircleCI plan, nor do they really have access > to Jenkins. This puts a burden on new authors where they wait 24+ hours to > run the tests... or just not run them. > > ** Lack of visibility into quality > > This is two things for me: commit and pre-commit. > > For commit, this is more what Mick was referring to as "post-commit CI". > There are a few questions I would like to know about our current tests > (report most flaky tests, which sections of code cause the most failures, > etc.); these are hard to answer at the moment . > > We don't have a good pre-commit story since it mostly relies on CircleCI. > I find that some JIRAs link CircleCI and some don't. I find that if I > follow the CircleCI link months later (to see if the build was stable > pre-commit) that Circle fails to show the workflow. > > On Mon, Feb 3, 2020 at 3:42 PM Michael Shuler > wrote: > > > Only have a moment to respond, but Mick hit the higlights with > > containerization, parallelization, these help solve cleanup, speed, and > > cascading failures. Dynamic disposable slaves would be icing on that > > cake, which may require a dedicated master. > > > > One more note on jobs, or more correctly unnecessary jobs - pipelines > > have a `changeset` build condition we should tinker with. There is zero > > reason to run a job with no actual code diff. For instance, I committed > > to 2.1 this morning and merged `-s ours` nothing to the newer branches - > > there's really no reason to run and take up valuable resources with no > > actual diff changes. > > https://jenkins.io/doc/book/pipeline/syntax/#built-in-conditions > > > > Michael > > > > On 2/3/20 3:45 PM, Nate McCall wrote: > > > Mick, this is fantastic! > > > > > > I'll wait another day to see if anyone else chimes in. (Would also love > > to > > > hear from CassCI folks, anyone else really who has wrestled with this > > even > > > for internal forks). > > > > > > On Tue, Feb 4, 2020 at 10:37 AM Mick Semb Wever wrote: > > > > > > > Nate, I leave it to you to forward what-you-chose to the board@'s > > thread. > > > > > > > > > > > > > Are there still troubles and what are they? > > > > > > > > > > > > TL;DR > > > > the ASF could provide the Cassandra community with an isolated > > jenkins > > > > installation: so that we can manage and control the Jenkins master, as > > > > well as ensure all donated hardware for Jenkins agents are dedicated and > > > > isolated to us. > > > > > > > > > > > > The long writeup… > > > > > > > > For Cassandra's use of ASF's Jenkins I see the following problems. > > > > > > > > ** Lack of trust (aka reliability) > > > > > > > > The Jenkins agents re-use their workspaces, as opposed to using new > > > > containers per test run, leading to broken agents, disks, git clones, > > etc. > > > > One broken test run, or a broken agent, too easily affects subsequent > > test > > > > executions. > > > > > > > > The
Re: Do we need Javadoc in binary distribution? Was: [RELEASE] Apache Cassandra 4.0-alpha3 released
+1
> On Feb 8, 2020, at 12:31 PM, Jon Haddad wrote:
>
> +1 as well
>
> On Sat, Feb 8, 2020, 12:25 PM Joshua McKenzie wrote:
>
>> +1 to removing javadoc from the distro from me.
>>
>> On Sat, Feb 8, 2020 at 9:24 AM Michael Shuler
>> wrote:
>>
>>> I like this idea for keeping binary deployment size down. I'm not sure
>>> how to handle it for the tarballs, but we could certainly split the docs
>>> out of the debian and rpm packages to add
>>> cassandra-docs_.{deb,rpm} packages, so they are installable
>>> separately, if the user wants them. This is common when docs get large.
>>> I suppose the same could be done for
>>> apache-cassandra-docs-,tar.gz, but I'm not sure about the
>>> release policy part of things here. Needs research.
>>>
>>> Please, open a JIRA on this as a packaging improvement.
>>>
>>> Kind regards,
>>> Michael
>>>
>>> On 2/8/20 3:06 AM, Alex Ott wrote:
Hi
I've unpacked binary distribution & noticed that we ship many files in
>>> the
javadoc directory - more than 5 thousand files, that occupy 99Mb on
>> disk
out of 149Mb for whole unpacked Cassandra.
If we look from practical standpoint - do we expect that people who run
Cassandra will use javadoc for any purpose? I know that it often
>>> contains
useful details about implementation, but if we talk about day-to-day
>>> work,
imho, these files aren't required, at least not on every machine that
>> has
Cassandra on it.
Maybe we can generate a separate artifact for Javadoc files?
Mick Semb Wever at "Fri, 07 Feb 2020 21:02:09 +0100" wrote:
MSW> The Cassandra team is pleased to announce the release of Apache
>>> Cassandra version 4.0-alpha3.
MSW> Apache Cassandra is a fully distributed database. It is the
>> right
>>> choice when you need scalability and high availability without
>> compromising
>>> performance.
MSW> http://cassandra.apache.org/
MSW> Downloads of source and binary distributions are listed in our
>>> download section:
MSW> http://cassandra.apache.org/download/
MSW> Downloads of source and binary distributions:
MSW>
>>>
>> http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-bin.tar.gz
MSW>
>>>
>> http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-src.tar.gz
MSW> Debian and Redhat configurations.
MSW> sources.list:
MSW> deb http://www.apache.org/dist/cassandra/debian 40x main
MSW> yum config:
MSW> baseurl=https://www.apache.org/dist/cassandra/redhat/40x/
MSW> See http://cassandra.apache.org/download/ for full install
>>> instructions.
MSW> This is an ALPHA version! It is not intended for production use,
>>> however
MSW> the project would appreciate your testing and feedback to make
>>> the final
MSW> release better. As always, please pay attention to the release
>>> notes[2]
MSW> and let us know[3] if you encounter any problems.
MSW> Enjoy!
MSW> [1]: CHANGES.txt
>>>
>> ?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-alpha3
MSW> [2]: NEWS.txt
>>>
>> ?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-alpha3
MSW> [3]: https://issues.apache.org/jira/browse/CASSANDRA
MSW>
>>> -
MSW> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
MSW> For additional commands, e-mail: user-h...@cassandra.apache.org
>>>
>>> -
>>> 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: Do we need Javadoc in binary distribution? Was: [RELEASE] Apache Cassandra 4.0-alpha3 released
+1 as well
On Sat, Feb 8, 2020, 12:25 PM Joshua McKenzie wrote:
> +1 to removing javadoc from the distro from me.
>
> On Sat, Feb 8, 2020 at 9:24 AM Michael Shuler
> wrote:
>
> > I like this idea for keeping binary deployment size down. I'm not sure
> > how to handle it for the tarballs, but we could certainly split the docs
> > out of the debian and rpm packages to add
> > cassandra-docs_.{deb,rpm} packages, so they are installable
> > separately, if the user wants them. This is common when docs get large.
> > I suppose the same could be done for
> > apache-cassandra-docs-,tar.gz, but I'm not sure about the
> > release policy part of things here. Needs research.
> >
> > Please, open a JIRA on this as a packaging improvement.
> >
> > Kind regards,
> > Michael
> >
> > On 2/8/20 3:06 AM, Alex Ott wrote:
> > > Hi
> > >
> > > I've unpacked binary distribution & noticed that we ship many files in
> > the
> > > javadoc directory - more than 5 thousand files, that occupy 99Mb on
> disk
> > > out of 149Mb for whole unpacked Cassandra.
> > >
> > > If we look from practical standpoint - do we expect that people who run
> > > Cassandra will use javadoc for any purpose? I know that it often
> > contains
> > > useful details about implementation, but if we talk about day-to-day
> > work,
> > > imho, these files aren't required, at least not on every machine that
> has
> > > Cassandra on it.
> > >
> > > Maybe we can generate a separate artifact for Javadoc files?
> > >
> > > Mick Semb Wever at "Fri, 07 Feb 2020 21:02:09 +0100" wrote:
> > > MSW> The Cassandra team is pleased to announce the release of Apache
> > Cassandra version 4.0-alpha3.
> > >
> > > MSW> Apache Cassandra is a fully distributed database. It is the
> right
> > choice when you need scalability and high availability without
> compromising
> > performance.
> > >
> > > MSW> http://cassandra.apache.org/
> > >
> > > MSW> Downloads of source and binary distributions are listed in our
> > download section:
> > > MSW> http://cassandra.apache.org/download/
> > >
> > >
> > > MSW> Downloads of source and binary distributions:
> > > MSW>
> >
> http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-bin.tar.gz
> > > MSW>
> >
> http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-src.tar.gz
> > >
> > > MSW> Debian and Redhat configurations.
> > >
> > > MSW> sources.list:
> > > MSW> deb http://www.apache.org/dist/cassandra/debian 40x main
> > >
> > > MSW> yum config:
> > > MSW> baseurl=https://www.apache.org/dist/cassandra/redhat/40x/
> > >
> > > MSW> See http://cassandra.apache.org/download/ for full install
> > instructions.
> > >
> > > MSW> This is an ALPHA version! It is not intended for production use,
> > however
> > > MSW> the project would appreciate your testing and feedback to make
> > the final
> > > MSW> release better. As always, please pay attention to the release
> > notes[2]
> > > MSW> and let us know[3] if you encounter any problems.
> > >
> > > MSW> Enjoy!
> > >
> > > MSW> [1]: CHANGES.txt
> >
> ?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-alpha3
> > > MSW> [2]: NEWS.txt
> >
> ?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-alpha3
> > > MSW> [3]: https://issues.apache.org/jira/browse/CASSANDRA
> > >
> > > MSW>
> > -
> > > MSW> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> > > MSW> For additional commands, e-mail: user-h...@cassandra.apache.org
> > >
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
Re: Do we need Javadoc in binary distribution? Was: [RELEASE] Apache Cassandra 4.0-alpha3 released
+1 to removing javadoc from the distro from me.
On Sat, Feb 8, 2020 at 9:24 AM Michael Shuler
wrote:
> I like this idea for keeping binary deployment size down. I'm not sure
> how to handle it for the tarballs, but we could certainly split the docs
> out of the debian and rpm packages to add
> cassandra-docs_.{deb,rpm} packages, so they are installable
> separately, if the user wants them. This is common when docs get large.
> I suppose the same could be done for
> apache-cassandra-docs-,tar.gz, but I'm not sure about the
> release policy part of things here. Needs research.
>
> Please, open a JIRA on this as a packaging improvement.
>
> Kind regards,
> Michael
>
> On 2/8/20 3:06 AM, Alex Ott wrote:
> > Hi
> >
> > I've unpacked binary distribution & noticed that we ship many files in
> the
> > javadoc directory - more than 5 thousand files, that occupy 99Mb on disk
> > out of 149Mb for whole unpacked Cassandra.
> >
> > If we look from practical standpoint - do we expect that people who run
> > Cassandra will use javadoc for any purpose? I know that it often
> contains
> > useful details about implementation, but if we talk about day-to-day
> work,
> > imho, these files aren't required, at least not on every machine that has
> > Cassandra on it.
> >
> > Maybe we can generate a separate artifact for Javadoc files?
> >
> > Mick Semb Wever at "Fri, 07 Feb 2020 21:02:09 +0100" wrote:
> > MSW> The Cassandra team is pleased to announce the release of Apache
> Cassandra version 4.0-alpha3.
> >
> > MSW> Apache Cassandra is a fully distributed database. It is the right
> choice when you need scalability and high availability without compromising
> performance.
> >
> > MSW> http://cassandra.apache.org/
> >
> > MSW> Downloads of source and binary distributions are listed in our
> download section:
> > MSW> http://cassandra.apache.org/download/
> >
> >
> > MSW> Downloads of source and binary distributions:
> > MSW>
> http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-bin.tar.gz
> > MSW>
> http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-src.tar.gz
> >
> > MSW> Debian and Redhat configurations.
> >
> > MSW> sources.list:
> > MSW> deb http://www.apache.org/dist/cassandra/debian 40x main
> >
> > MSW> yum config:
> > MSW> baseurl=https://www.apache.org/dist/cassandra/redhat/40x/
> >
> > MSW> See http://cassandra.apache.org/download/ for full install
> instructions.
> >
> > MSW> This is an ALPHA version! It is not intended for production use,
> however
> > MSW> the project would appreciate your testing and feedback to make
> the final
> > MSW> release better. As always, please pay attention to the release
> notes[2]
> > MSW> and let us know[3] if you encounter any problems.
> >
> > MSW> Enjoy!
> >
> > MSW> [1]: CHANGES.txt
> ?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-alpha3
> > MSW> [2]: NEWS.txt
> ?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-alpha3
> > MSW> [3]: https://issues.apache.org/jira/browse/CASSANDRA
> >
> > MSW>
> -
> > MSW> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> > MSW> For additional commands, e-mail: user-h...@cassandra.apache.org
> >
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
Re: Do we need Javadoc in binary distribution? Was: [RELEASE] Apache Cassandra 4.0-alpha3 released
I like this idea for keeping binary deployment size down. I'm not sure
how to handle it for the tarballs, but we could certainly split the docs
out of the debian and rpm packages to add
cassandra-docs_.{deb,rpm} packages, so they are installable
separately, if the user wants them. This is common when docs get large.
I suppose the same could be done for
apache-cassandra-docs-,tar.gz, but I'm not sure about the
release policy part of things here. Needs research.
Please, open a JIRA on this as a packaging improvement.
Kind regards,
Michael
On 2/8/20 3:06 AM, Alex Ott wrote:
Hi
I've unpacked binary distribution & noticed that we ship many files in the
javadoc directory - more than 5 thousand files, that occupy 99Mb on disk
out of 149Mb for whole unpacked Cassandra.
If we look from practical standpoint - do we expect that people who run
Cassandra will use javadoc for any purpose? I know that it often contains
useful details about implementation, but if we talk about day-to-day work,
imho, these files aren't required, at least not on every machine that has
Cassandra on it.
Maybe we can generate a separate artifact for Javadoc files?
Mick Semb Wever at "Fri, 07 Feb 2020 21:02:09 +0100" wrote:
MSW> The Cassandra team is pleased to announce the release of Apache
Cassandra version 4.0-alpha3.
MSW> Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising performance.
MSW> http://cassandra.apache.org/
MSW> Downloads of source and binary distributions are listed in our download
section:
MSW> http://cassandra.apache.org/download/
MSW> Downloads of source and binary distributions:
MSW>
http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-bin.tar.gz
MSW>
http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-src.tar.gz
MSW> Debian and Redhat configurations.
MSW> sources.list:
MSW> deb http://www.apache.org/dist/cassandra/debian 40x main
MSW> yum config:
MSW> baseurl=https://www.apache.org/dist/cassandra/redhat/40x/
MSW> See http://cassandra.apache.org/download/ for full install instructions.
MSW> This is an ALPHA version! It is not intended for production use, however
MSW> the project would appreciate your testing and feedback to make the final
MSW> release better. As always, please pay attention to the release notes[2]
MSW> and let us know[3] if you encounter any problems.
MSW> Enjoy!
MSW> [1]: CHANGES.txt
?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-alpha3
MSW> [2]: NEWS.txt
?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-alpha3
MSW> [3]: https://issues.apache.org/jira/browse/CASSANDRA
MSW> -
MSW> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
MSW> For additional commands, e-mail: user-h...@cassandra.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
Do we need Javadoc in binary distribution? Was: [RELEASE] Apache Cassandra 4.0-alpha3 released
Hi I've unpacked binary distribution & noticed that we ship many files in the javadoc directory - more than 5 thousand files, that occupy 99Mb on disk out of 149Mb for whole unpacked Cassandra. If we look from practical standpoint - do we expect that people who run Cassandra will use javadoc for any purpose? I know that it often contains useful details about implementation, but if we talk about day-to-day work, imho, these files aren't required, at least not on every machine that has Cassandra on it. Maybe we can generate a separate artifact for Javadoc files? Mick Semb Wever at "Fri, 07 Feb 2020 21:02:09 +0100" wrote: MSW> The Cassandra team is pleased to announce the release of Apache Cassandra version 4.0-alpha3. MSW> Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. MSW> http://cassandra.apache.org/ MSW> Downloads of source and binary distributions are listed in our download section: MSW> http://cassandra.apache.org/download/ MSW> Downloads of source and binary distributions: MSW> http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-bin.tar.gz MSW> http://www.apache.org/dyn/closer.lua/cassandra/4.0-alpha3/apache-cassandra-4.0-alpha3-src.tar.gz MSW> Debian and Redhat configurations. MSW> sources.list: MSW> deb http://www.apache.org/dist/cassandra/debian 40x main MSW> yum config: MSW> baseurl=https://www.apache.org/dist/cassandra/redhat/40x/ MSW> See http://cassandra.apache.org/download/ for full install instructions. MSW> This is an ALPHA version! It is not intended for production use, however MSW> the project would appreciate your testing and feedback to make the final MSW> release better. As always, please pay attention to the release notes[2] MSW> and let us know[3] if you encounter any problems. MSW> Enjoy! MSW> [1]: CHANGES.txt ?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-alpha3 MSW> [2]: NEWS.txt ?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-alpha3 MSW> [3]: https://issues.apache.org/jira/browse/CASSANDRA MSW> - MSW> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org MSW> For additional commands, e-mail: user-h...@cassandra.apache.org -- With best wishes,Alex Ott Principal Architect, DataStax http://datastax.com/ - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
