Re: Additions to Cassandra ecosystem page?

[bened...@apache.org]

I disagree that disclaimers dissolve many duties, responsibilities or implied 
communicative acts.

Most people recognise disclaimers as a means of abdicating responsibility for 
the consequences of utilising an endorsement or other facility, not as a 
communicative act indicating a lack of actual endorsement.

Besides which, many here have communicated reasons they believe it is wrong to 
promote these other database offerings, which is a weaker criteria than 
endorsement.


From: Paulo Motta 
Date: Tuesday, 29 June 2021 at 19:14
To: Cassandra DEV 
Subject: Re: Additions to Cassandra ecosystem page?
> Listing a product on our website implicitly endorses that offering, and
we should absolutely be restrictive about what we endorse. I’m -1
unconditionally endorsing

I don't think listing a product on the website means implicitly endorsing
it if it's explicitly mentioned with a visible disclaimer that we're not
endorsing the listed products.

>From my experience, an ecosystem page is an open wiki editable by anyone
with the sole objective of allowing external users to easily find anything
related to the project, and not a list of "unconditionally endorsed"
offerings.

Why not take a community-driven laissez-faire approach and just let people
list whatever they want if they feel part of the community, with the
explicit disclaimer that being on the list is not a project endorsement of
the offering? For instance, Apache Kafka uses very simple wording to convey
this [1]: "Here is a list of tools *we have been* told about that integrate
with Kafka outside the main distribution. *We haven't tried them all, so
they may not work*!" [1]

I think it's fine to bikeshed how to categorize offerings, present the
list, word the disclaimer and even remove clear violations of good faith,
but I don't think we should be over presumptuous and prescribe what is
allowed and forbidden on a public wiki of an open source project.

Two objective suggestions I'd like to make are:
- Give more visibility/prominence to
auxiliary/complementary/supplementary/non-competing/open-source
projects/products by listing them at the top of the page, and list
closed-source / SaaS / API-compatible offerings under its own category at
the bottom of the page with maybe an additional disclaimer that not all
features may be available on these offerings.
- There are 3 sub-offerings from a single vendor in the "Professional
Services" category, but I think it's sufficient to list each service
provider once per category, since the sub-offerings can be easily found by
visiting the service provider website.

Paulo
-

[1] https://spark.apache.org/third-party-projects.html

Em ter., 29 de jun. de 2021 às 04:48, Benjamin Lerer 
escreveu:

> If I have to choose between the four choices that you proposed I would then
> choose (1) List no alternative offerings at all.
>
> Le mar. 29 juin 2021 à 09:34, bened...@apache.org  a
> écrit :
>
> > I don’t think it is intractable to come up with a definition that we use
> > for inclusion.
> >
> > 1. List no alternative offerings at all.
> > 2. List only those offerings that deploy precisely a released version of
> > Cassandra.
> > 3. List only those offerings that deploy precisely a released version of
> > Cassandra with modifications that extend a list of public APIs.
> > 4. List only those offerings that deploy precisely a released version of
> > Cassandra with modifications that extend a list of public APIs, or are
> > themselves published under ASL v2.
> >
> > Listing a product on our website implicitly endorses that offering, and
> we
> > should absolutely be restrictive about what we endorse. I’m -1
> > unconditionally endorsing competing products, and products that are not
> > themselves clearly some derivative work that is accessible to the
> community
> > under similar terms.
> >
> > If we cannot agree on a set of conditions, options (1) and (2) are
> simple,
> > easy to administer, adequately restrictive and not inconsistently
> > permissive.
> >
> > I don’t think this website is going to drive a lot of traffic to any of
> > these businesses, so I doubt any of them should be upset at any loss of
> > revenue. The question is simply one of principle for us as a project.
> >
> >
> >
> > From: Benjamin Lerer 
> > Date: Tuesday, 29 June 2021 at 08:10
> > To: dev@cassandra.apache.org 
> > Subject: Re: Additions to Cassandra ecosystem page?
> > I feel that we are going into a too restrictive direction. I believe that
> > we have more to win by being open and welcoming.
> > -1 for the strict approach and for the licences.
> >
> > Le mar. 29 juin 2021 à 00:40, Ben Bromhead  a
> écrit :
> >
> > > On Thu, Jun 24, 2021 at 2:38 AM Joshua McKenzie 
> > > wrote:
> > >
> > > >
> > > > The obvious core responsibility of the website should be to ASLv2
> > > > permissively licensed Apache Cassandra and secondarily to CQL as a
> > > protocol
> > > > IMO. I don't think we as a project should be tracking derivative
> works,
> > > > forks,

Re: Additions to Cassandra ecosystem page?

[Patrick McFadin]

This is a very interesting thread and has had me thinking quite a bit.
Having to reason through who belongs on a list or not just seems very
polarizing to me and given the length of this thread, I think that's
playing out. This kind of energy is just not good for the larger community.
And I'm thinking of anyone that has to update this list and reason through
all of the complex rulesets of why or why not, It's really not fair to
them.

My proposal is that we completely drop the Cassandra Cloud Offereing
section.

Some reasoning.

If somebody wants to run a cloud version of Cassandra, that's the least
hard thing to find. Google "Apache Cassandra" and see what pops to the top
of Google Ads. DataStax, Instaclustr, Aiven, Amazon and Microsoft all have
marketing budgets. They will be just fine.

I would love for our ecosystem page to be a place where we celebrate and
encourage the supportive tooling and products that add to Apache Cassandra
and make it better for everyone to use. That should be the guiding
principle on addition to the ecosystem page. Celebrate not arbitrate. Given
that criteria, Professional Support and Education might be on the chopping
block as well.

Patrick

On Wed, Jun 30, 2021 at 1:48 AM bened...@apache.org 
wrote:

> I disagree that disclaimers dissolve many duties, responsibilities or
> implied communicative acts.
>
> Most people recognise disclaimers as a means of abdicating responsibility
> for the consequences of utilising an endorsement or other facility, not as
> a communicative act indicating a lack of actual endorsement.
>
> Besides which, many here have communicated reasons they believe it is
> wrong to promote these other database offerings, which is a weaker criteria
> than endorsement.
>
>
> From: Paulo Motta 
> Date: Tuesday, 29 June 2021 at 19:14
> To: Cassandra DEV 
> Subject: Re: Additions to Cassandra ecosystem page?
> > Listing a product on our website implicitly endorses that offering, and
> we should absolutely be restrictive about what we endorse. I’m -1
> unconditionally endorsing
>
> I don't think listing a product on the website means implicitly endorsing
> it if it's explicitly mentioned with a visible disclaimer that we're not
> endorsing the listed products.
>
> From my experience, an ecosystem page is an open wiki editable by anyone
> with the sole objective of allowing external users to easily find anything
> related to the project, and not a list of "unconditionally endorsed"
> offerings.
>
> Why not take a community-driven laissez-faire approach and just let people
> list whatever they want if they feel part of the community, with the
> explicit disclaimer that being on the list is not a project endorsement of
> the offering? For instance, Apache Kafka uses very simple wording to convey
> this [1]: "Here is a list of tools *we have been* told about that integrate
> with Kafka outside the main distribution. *We haven't tried them all, so
> they may not work*!" [1]
>
> I think it's fine to bikeshed how to categorize offerings, present the
> list, word the disclaimer and even remove clear violations of good faith,
> but I don't think we should be over presumptuous and prescribe what is
> allowed and forbidden on a public wiki of an open source project.
>
> Two objective suggestions I'd like to make are:
> - Give more visibility/prominence to
> auxiliary/complementary/supplementary/non-competing/open-source
> projects/products by listing them at the top of the page, and list
> closed-source / SaaS / API-compatible offerings under its own category at
> the bottom of the page with maybe an additional disclaimer that not all
> features may be available on these offerings.
> - There are 3 sub-offerings from a single vendor in the "Professional
> Services" category, but I think it's sufficient to list each service
> provider once per category, since the sub-offerings can be easily found by
> visiting the service provider website.
>
> Paulo
> -
>
> [1] https://spark.apache.org/third-party-projects.html
>
> Em ter., 29 de jun. de 2021 às 04:48, Benjamin Lerer 
> escreveu:
>
> > If I have to choose between the four choices that you proposed I would
> then
> > choose (1) List no alternative offerings at all.
> >
> > Le mar. 29 juin 2021 à 09:34, bened...@apache.org 
> a
> > écrit :
> >
> > > I don’t think it is intractable to come up with a definition that we
> use
> > > for inclusion.
> > >
> > > 1. List no alternative offerings at all.
> > > 2. List only those offerings that deploy precisely a released version
> of
> > > Cassandra.
> > > 3. List only those offerings that deploy precisely a released version
> of
> > > Cassandra with modifications that extend a list of public APIs.
> > > 4. List only those offerings that deploy precisely a released version
> of
> > > Cassandra with modifications that extend a list of public APIs, or are
> > > themselves published under ASL v2.
> > >
> > > Listing a product on our website implicitly endorses that offering, and
> > we
> > 

[VOTE][RESULT] Release Apache Cassandra 4.0-rc2

[Mick Semb Wever]

>
>  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
> >> -1's.
> 



Vote passes with 15 +1s (7 binding), and no -1s.

Re: [DISCUSS] CASSANDRA-16760 - JMXTimer exposes attributes in inconsistent time units

[Yifan Cai]

Looks like we all agree on option 1. I have submitted a patch to the trunk
branch. It unifies the duration unit and defaults to micros. As a result,
all timers will start to record time values in micros instead of nanos.

Please let me know if there is any concern with the change.

- Yifan

On Fri, Jun 25, 2021 at 1:57 PM Yifan Cai  wrote:

> how much memory the Timers can currently use
>
>
> Timer is currently backed by a DecayingEstimatedHistogramReservoir. [1]
>
> Each DecayingEstimatedHistogramReservoir defaults to allocate [2]
> 1. *bucketOffsets*: a long array with the length of 164
> 2. *decayingBuckets*: a long array with the length of 165 * 2
> 3. *buckets*: a long array with the length of 165 * 2
>
> Each timer instance consumes 6592 bytes roughly. (Only counting the long
> arrays, which are the main contributors)
> There are a bunch of timers, per verb, per keyspace, per table, etc.
> Although adding them up might still not be a concern.
> As mentioned, recording in the micros can halve the memory usage. Not a
> significant saving compared with other components, but still good to have
> if nanos is not necessary.
>
> The major benefit is making the duration unit consistent.
>
> [1]
> https://github.com/apache/cassandra/blob/aac6f7db8c8f493b8e28842903e6e2cb6838ac75/src/java/org/apache/cassandra/metrics/CassandraMetricsRegistry.java#L101
> [2]
> https://github.com/apache/cassandra/blob/aac6f7db8c8f493b8e28842903e6e2cb6838ac75/src/java/org/apache/cassandra/metrics/DecayingEstimatedHistogramReservoir.java#L79
>
> On Fri, Jun 25, 2021 at 7:26 AM Joshua McKenzie 
> wrote:
>
>> +1 to unifying on the same unit for API consistency; micros should be
>> quite
>> fine for most if not all of our use-cases.
>>
>>
>> On Fri, Jun 25, 2021 at 8:58 AM Brandon Williams 
>> wrote:
>>
>> > On Fri, Jun 25, 2021 at 6:17 AM Mick Semb Wever  wrote:
>> > >
>> > > I'm for (1) if this is for 4.1 only. Changes like this over our annual
>> > releases should be fine if they are clearly documented, it's what
>> NEWS.txt
>> > is for.
>> >
>> > +1, we have the process in place to handle this.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> > For additional commands, e-mail: dev-h...@cassandra.apache.org
>> >
>> >
>>
>

[RELEASE] Apache Cassandra 4.0-rc2 released

[Mick Semb Wever]

The Cassandra team is pleased to announce the release of Apache Cassandra
version 4.0-rc2.

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 release candidate[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.

Please note, the bintray location is now replaced with the ASF's JFrog
Artifactory location: https://apache.jfrog.io/artifactory/cassandra/

Enjoy!

[1]: CHANGES.txt
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-rc2
[2]: NEWS.txt
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-rc2
[3]: https://issues.apache.org/jira/browse/CASSANDRA

Re: [RELEASE] Apache Cassandra 4.0-rc2 released

[Patrick McFadin]

Congrats to everyone that worked on this iteration. If you haven't looked
at the CHANGES.txt there were some great catches in RC1. Just like it
should happen!

On Wed, Jun 30, 2021 at 12:29 PM Mick Semb Wever  wrote:

>
> The Cassandra team is pleased to announce the release of Apache Cassandra
> version 4.0-rc2.
>
> 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 release candidate[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.
>
> Please note, the bintray location is now replaced with the ASF's JFrog
> Artifactory location: https://apache.jfrog.io/artifactory/cassandra/
>
> Enjoy!
>
> [1]: CHANGES.txt
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0-rc2
> [2]: NEWS.txt
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0-rc2
> [3]: https://issues.apache.org/jira/browse/CASSANDRA
>

Re: Additions to Cassandra ecosystem page?

[Joshua McKenzie]

>
> My proposal is that we completely drop the Cassandra Cloud Offereing
> section.

+1



On Wed, Jun 30, 2021 at 12:34 PM Patrick McFadin  wrote:

> This is a very interesting thread and has had me thinking quite a bit.
> Having to reason through who belongs on a list or not just seems very
> polarizing to me and given the length of this thread, I think that's
> playing out. This kind of energy is just not good for the larger community.
> And I'm thinking of anyone that has to update this list and reason through
> all of the complex rulesets of why or why not, It's really not fair to
> them.
>
> My proposal is that we completely drop the Cassandra Cloud Offereing
> section.
>
> Some reasoning.
>
> If somebody wants to run a cloud version of Cassandra, that's the least
> hard thing to find. Google "Apache Cassandra" and see what pops to the top
> of Google Ads. DataStax, Instaclustr, Aiven, Amazon and Microsoft all have
> marketing budgets. They will be just fine.
>
> I would love for our ecosystem page to be a place where we celebrate and
> encourage the supportive tooling and products that add to Apache Cassandra
> and make it better for everyone to use. That should be the guiding
> principle on addition to the ecosystem page. Celebrate not arbitrate. Given
> that criteria, Professional Support and Education might be on the chopping
> block as well.
>
> Patrick
>
> On Wed, Jun 30, 2021 at 1:48 AM bened...@apache.org 
> wrote:
>
> > I disagree that disclaimers dissolve many duties, responsibilities or
> > implied communicative acts.
> >
> > Most people recognise disclaimers as a means of abdicating responsibility
> > for the consequences of utilising an endorsement or other facility, not
> as
> > a communicative act indicating a lack of actual endorsement.
> >
> > Besides which, many here have communicated reasons they believe it is
> > wrong to promote these other database offerings, which is a weaker
> criteria
> > than endorsement.
> >
> >
> > From: Paulo Motta 
> > Date: Tuesday, 29 June 2021 at 19:14
> > To: Cassandra DEV 
> > Subject: Re: Additions to Cassandra ecosystem page?
> > > Listing a product on our website implicitly endorses that offering, and
> > we should absolutely be restrictive about what we endorse. I’m -1
> > unconditionally endorsing
> >
> > I don't think listing a product on the website means implicitly endorsing
> > it if it's explicitly mentioned with a visible disclaimer that we're not
> > endorsing the listed products.
> >
> > From my experience, an ecosystem page is an open wiki editable by anyone
> > with the sole objective of allowing external users to easily find
> anything
> > related to the project, and not a list of "unconditionally endorsed"
> > offerings.
> >
> > Why not take a community-driven laissez-faire approach and just let
> people
> > list whatever they want if they feel part of the community, with the
> > explicit disclaimer that being on the list is not a project endorsement
> of
> > the offering? For instance, Apache Kafka uses very simple wording to
> convey
> > this [1]: "Here is a list of tools *we have been* told about that
> integrate
> > with Kafka outside the main distribution. *We haven't tried them all, so
> > they may not work*!" [1]
> >
> > I think it's fine to bikeshed how to categorize offerings, present the
> > list, word the disclaimer and even remove clear violations of good faith,
> > but I don't think we should be over presumptuous and prescribe what is
> > allowed and forbidden on a public wiki of an open source project.
> >
> > Two objective suggestions I'd like to make are:
> > - Give more visibility/prominence to
> > auxiliary/complementary/supplementary/non-competing/open-source
> > projects/products by listing them at the top of the page, and list
> > closed-source / SaaS / API-compatible offerings under its own category at
> > the bottom of the page with maybe an additional disclaimer that not all
> > features may be available on these offerings.
> > - There are 3 sub-offerings from a single vendor in the "Professional
> > Services" category, but I think it's sufficient to list each service
> > provider once per category, since the sub-offerings can be easily found
> by
> > visiting the service provider website.
> >
> > Paulo
> > -
> >
> > [1] https://spark.apache.org/third-party-projects.html
> >
> > Em ter., 29 de jun. de 2021 às 04:48, Benjamin Lerer 
> > escreveu:
> >
> > > If I have to choose between the four choices that you proposed I would
> > then
> > > choose (1) List no alternative offerings at all.
> > >
> > > Le mar. 29 juin 2021 à 09:34, bened...@apache.org  >
> > a
> > > écrit :
> > >
> > > > I don’t think it is intractable to come up with a definition that we
> > use
> > > > for inclusion.
> > > >
> > > > 1. List no alternative offerings at all.
> > > > 2. List only those offerings that deploy precisely a released version
> > of
> > > > Cassandra.
> > > > 3. List only those offerings that deploy precisely a released

[DISCUSS] Jira state for second reviewer

[Brandon Williams]

Hello,

Since our project governance requires two committers, which in some
circumstances may mean two committers need to review, I'd like to add
another state to our jira such that finding tickets that need a second
reviewer is possible, since it is not currently.

On slack, Paulo Motta suggested this:

Patch Available -> Review in Progress <-> Needs Reviewer* -> Ready To Commit

Where "needs reviewer" is an optional state that can then move back to
"Review in Progress" and carry on.  This would affect all tickets in
the project, so I'm curious if there are any thoughts or objections?

Kind Regards,
Brandon

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Additions to Cassandra ecosystem page?

[Melissa Logan]

Appreciate the discussion, all.

As the person who has primarily been aggregating info for this page, my
approach has been to consider what would be most useful to an end user who
wants to use / extend Cassandra -- and to be permissive about what would be
included to keep things simple (as we don't have the capability to vet and
verify each one).

That said, based on the debate here I would +1 the comment about cloud
offerings and allow others to remain -- including Professional Support and
Education, simply because those do help people use and extend open source
Cassandra.


On Wed, Jun 30, 2021 at 1:23 PM Joshua McKenzie 
wrote:

> >
> > My proposal is that we completely drop the Cassandra Cloud Offereing
> > section.
>
> +1
>
>
>
> On Wed, Jun 30, 2021 at 12:34 PM Patrick McFadin 
> wrote:
>
> > This is a very interesting thread and has had me thinking quite a bit.
> > Having to reason through who belongs on a list or not just seems very
> > polarizing to me and given the length of this thread, I think that's
> > playing out. This kind of energy is just not good for the larger
> community.
> > And I'm thinking of anyone that has to update this list and reason
> through
> > all of the complex rulesets of why or why not, It's really not fair to
> > them.
> >
> > My proposal is that we completely drop the Cassandra Cloud Offereing
> > section.
> >
> > Some reasoning.
> >
> > If somebody wants to run a cloud version of Cassandra, that's the least
> > hard thing to find. Google "Apache Cassandra" and see what pops to the
> top
> > of Google Ads. DataStax, Instaclustr, Aiven, Amazon and Microsoft all
> have
> > marketing budgets. They will be just fine.
> >
> > I would love for our ecosystem page to be a place where we celebrate and
> > encourage the supportive tooling and products that add to Apache
> Cassandra
> > and make it better for everyone to use. That should be the guiding
> > principle on addition to the ecosystem page. Celebrate not arbitrate.
> Given
> > that criteria, Professional Support and Education might be on the
> chopping
> > block as well.
> >
> > Patrick
> >
> > On Wed, Jun 30, 2021 at 1:48 AM bened...@apache.org  >
> > wrote:
> >
> > > I disagree that disclaimers dissolve many duties, responsibilities or
> > > implied communicative acts.
> > >
> > > Most people recognise disclaimers as a means of abdicating
> responsibility
> > > for the consequences of utilising an endorsement or other facility, not
> > as
> > > a communicative act indicating a lack of actual endorsement.
> > >
> > > Besides which, many here have communicated reasons they believe it is
> > > wrong to promote these other database offerings, which is a weaker
> > criteria
> > > than endorsement.
> > >
> > >
> > > From: Paulo Motta 
> > > Date: Tuesday, 29 June 2021 at 19:14
> > > To: Cassandra DEV 
> > > Subject: Re: Additions to Cassandra ecosystem page?
> > > > Listing a product on our website implicitly endorses that offering,
> and
> > > we should absolutely be restrictive about what we endorse. I’m -1
> > > unconditionally endorsing
> > >
> > > I don't think listing a product on the website means implicitly
> endorsing
> > > it if it's explicitly mentioned with a visible disclaimer that we're
> not
> > > endorsing the listed products.
> > >
> > > From my experience, an ecosystem page is an open wiki editable by
> anyone
> > > with the sole objective of allowing external users to easily find
> > anything
> > > related to the project, and not a list of "unconditionally endorsed"
> > > offerings.
> > >
> > > Why not take a community-driven laissez-faire approach and just let
> > people
> > > list whatever they want if they feel part of the community, with the
> > > explicit disclaimer that being on the list is not a project endorsement
> > of
> > > the offering? For instance, Apache Kafka uses very simple wording to
> > convey
> > > this [1]: "Here is a list of tools *we have been* told about that
> > integrate
> > > with Kafka outside the main distribution. *We haven't tried them all,
> so
> > > they may not work*!" [1]
> > >
> > > I think it's fine to bikeshed how to categorize offerings, present the
> > > list, word the disclaimer and even remove clear violations of good
> faith,
> > > but I don't think we should be over presumptuous and prescribe what is
> > > allowed and forbidden on a public wiki of an open source project.
> > >
> > > Two objective suggestions I'd like to make are:
> > > - Give more visibility/prominence to
> > > auxiliary/complementary/supplementary/non-competing/open-source
> > > projects/products by listing them at the top of the page, and list
> > > closed-source / SaaS / API-compatible offerings under its own category
> at
> > > the bottom of the page with maybe an additional disclaimer that not all
> > > features may be available on these offerings.
> > > - There are 3 sub-offerings from a single vendor in the "Professional
> > > Services" category, but I think it's sufficient to list each 

Re: [DISCUSS] Jira state for second reviewer

[Erick Ramirez]

+1 sounds good. I recall seeing the conversation in #cassandra-dev --
weren't you also going to add a tag so it's easy to pick the tickets that
need a second reviewer? Cheers!

Re: Additions to Cassandra ecosystem page?

[Erick Ramirez]

>
> And I'm thinking of anyone that has to update this list and reason through
> all of the complex rulesets of why or why not, It's really not fair to
> them.

My proposal is that we completely drop the Cassandra Cloud Offereing
> section.
> Given that criteria, Professional Support and Education might be on the
> chopping
> block as well.
>

+1 would definitely make my life easier when I'm reviewing/pushing updates
to the site. 🍻

Re: [DISCUSS] Jira state for second reviewer

[Caleb Rackliffe]

+1

> On Jun 30, 2021, at 4:38 PM, Brandon Williams  wrote:
> 
> Hello,
> 
> Since our project governance requires two committers, which in some
> circumstances may mean two committers need to review, I'd like to add
> another state to our jira such that finding tickets that need a second
> reviewer is possible, since it is not currently.
> 
> On slack, Paulo Motta suggested this:
> 
> Patch Available -> Review in Progress <-> Needs Reviewer* -> Ready To Commit
> 
> Where "needs reviewer" is an optional state that can then move back to
> "Review in Progress" and carry on.  This would affect all tickets in
> the project, so I'm curious if there are any thoughts or objections?
> 
> Kind Regards,
> Brandon
> 
> -
> 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: Additions to Cassandra ecosystem page?

[Ben Bromhead]

I would be sad to see us drop this just because it's a hard discussion with
a few different opinions. My apologies if this discussion is making folks
feel excluded.

Whilst I don't have a problem with a strict approach and it does improve
user clarity. I can understand how it might feel exclusionary. Having
classifications can make the tent bigger and allow for things that are API
compatible to be celebrated (the owners of some of the API compatible
offerings make significant contributions to the community and I would love
for them to be on the list).

Having some classification would better allow us to celebrate the different
offerings in the community and be more inclusive without misrepresenting
things to our users and making it easy to meet our obligations around how
we talk about Apache trademarks.

Part of demonstrating the health of the project is to talk about the
broader ecosystem around it.  Most other communities can seem to maintain
an ecosystem list that is fairly broad.

E.g.
Apache Kafka -> https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem
- Maintains a set of groupings and listings. Also listed projects could be
considered quite competitive.
Apache Spark -> A simple list of folk who use or do something with spark
https://spark.apache.org/powered-by.html
Apache Samza -> Again a simple list
http://samza.incubator.apache.org/powered-by/

Outside of the Apache landscape. The Postgres folk also simply have a list
of derived or adjacent PG databases which is kinda cool
https://wiki.postgresql.org/wiki/PostgreSQL_derived_databases.

Personally I think including the "API compatible offerings" is fine and
further demonstrates the power and reach of our community. For the
commercial vendors out there we have our marketing budgets and will do fine
(as Patrick said), but I would hate to see an opportunity to demonstrate
the breadth and depth of our community be missed.

As demonstrated with some of the above links, there should be a good
inclusive solution out there.


On Thu, Jul 1, 2021 at 2:33 PM Erick Ramirez 
wrote:

> >
> > And I'm thinking of anyone that has to update this list and reason
> through
> > all of the complex rulesets of why or why not, It's really not fair to
> > them.
>
> My proposal is that we completely drop the Cassandra Cloud Offereing
> > section.
> > Given that criteria, Professional Support and Education might be on the
> > chopping
> > block as well.
> >
>
> +1 would definitely make my life easier when I'm reviewing/pushing updates
> to the site. 🍻
>


-- 

Ben Bromhead

Instaclustr | www.instaclustr.com | @instaclustr
 | +64 27 383 8975