Contributing research on C* usage for blog

[Melissa Logan]

Hi everyone,

Several open source projects conduct regular user surveys to understand
current usage and adoption trends, e.g. OpenStack, Kubernetes, Cloud
Foundry, etc. They can be informative to the community and other end users.
It looks like the C* community may have conducted these in the past per
https://twitter.com/cassandra/status/649287871577219072.

Recently, an independent research company called Clearpath Strategies was
funded by DataStax to conduct research on C* usage and adoption, and they
would like to contribute the findings to the community.

901 practitioners were interviewed. I analyzed the data and summarized in a
document here:
https://docs.google.com/document/d/1aM8muvbldPhSJdgrsM0OiLGvb5wfjwc5uutSCNfGup8/edit?usp=sharing

If this seems broadly useful, I’m proposing that we publish to the C* blog.
New graphics will be created in the same styling as the 4.0 graphic as
noted in the doc.

If you have questions about the data, please share here or in the doc.

Appreciate your thoughts and consideration.

Melissa

Re: Contributing research on C* usage for blog

[Jeff Jirsa]

I don't have any questions, but datastax folks: thanks for funding stuff
like this.

(I'd love to see it as a blog post, I'd also love to see people internalize
the negative feedback and assumed features and determine whether or not
people are working on the right things)

On Thu, Aug 27, 2020 at 10:25 AM Melissa Logan 
wrote:

> Hi everyone,
>
> Several open source projects conduct regular user surveys to understand
> current usage and adoption trends, e.g. OpenStack, Kubernetes, Cloud
> Foundry, etc. They can be informative to the community and other end users.
> It looks like the C* community may have conducted these in the past per
> https://twitter.com/cassandra/status/649287871577219072.
>
> Recently, an independent research company called Clearpath Strategies was
> funded by DataStax to conduct research on C* usage and adoption, and they
> would like to contribute the findings to the community.
>
> 901 practitioners were interviewed. I analyzed the data and summarized in a
> document here:
>
> https://docs.google.com/document/d/1aM8muvbldPhSJdgrsM0OiLGvb5wfjwc5uutSCNfGup8/edit?usp=sharing
>
> If this seems broadly useful, I’m proposing that we publish to the C* blog.
> New graphics will be created in the same styling as the 4.0 graphic as
> noted in the doc.
>
> If you have questions about the data, please share here or in the doc.
>
> Appreciate your thoughts and consideration.
>
> Melissa
>

Re: [DISCUSS] CEP-7 Storage Attached Index

[Jasonstack Zhao Yang]

+1

On Thu, 27 Aug 2020 at 04:52, Ekaterina Dimitrova 
wrote:

> +1
>
> On Wed, 26 Aug 2020 at 16:48, Caleb Rackliffe 
> wrote:
>
> > +1
> >
> >
> >
> > On Wed, Aug 26, 2020, 3:45 PM Patrick McFadin 
> wrote:
> >
> >
> >
> > > This is related to the discussion Jordan and I had about the
> contributor
> >
> > > Zoom call. Instead of open mic for any issue, call it based on a
> > discussion
> >
> > > thread or threads for higher bandwidth discussion.
> >
> > >
> >
> > > I would be happy to schedule on for next week to specifically discuss
> >
> > > CEP-7. I can attach the recorded call to the CEP after.
> >
> > >
> >
> > > +1 or -1?
> >
> > >
> >
> > > Patrick
> >
> > >
> >
> > > On Tue, Aug 25, 2020 at 7:03 AM Joshua McKenzie 
> >
> > > wrote:
> >
> > >
> >
> > > > >
> >
> > > > > Does community plan to open another discussion or CEP on
> >
> > > modularization?
> >
> > > >
> >
> > > > We probably should have a discussion on the ML or monthly contrib
> call
> >
> > > > about it first to see how aligned the interested contributors are.
> > Could
> >
> > > do
> >
> > > > that through CEP as well but CEP's (at least thus far sans k8s
> > operator)
> >
> > > > tend to start with a strong, deeply thought out point of view being
> >
> > > > expressed.
> >
> > > >
> >
> > > > On Tue, Aug 25, 2020 at 3:26 AM Jasonstack Zhao Yang <
> >
> > > > jasonstack.z...@gmail.com> wrote:
> >
> > > >
> >
> > > > > >>> SASI's performance, specifically the search in the B+ tree
> >
> > > component,
> >
> > > > > >>> depends a lot on the component file's header being available in
> > the
> >
> > > > > >>> pagecache. SASI benefits from (needs) nodes with lots of RAM.
> Is
> >
> > > SAI
> >
> > > > > bound
> >
> > > > > >>> to this same or similar limitation?
> >
> > > > >
> >
> > > > > SAI also benefits from larger memory because SAI puts block info on
> >
> > > heap
> >
> > > > > for searching on-disk components and having cross-index files on
> page
> >
> > > > cache
> >
> > > > > improves read performance of different indexes on the same table.
> >
> > > > >
> >
> > > > >
> >
> > > > > >>> Flushing of SASI can be CPU+IO intensive, to the point of
> >
> > > saturation,
> >
> > > > > >>> pauses, and crashes on the node. SSDs are a must, along with a
> > bit
> >
> > > of
> >
> > > > > >>> tuning, just to avoid bringing down your cluster. Beyond
> reducing
> >
> > > > space
> >
> > > > > >>> requirements, does SAI improve on these things? Like SASI how
> > does
> >
> > > > SAI,
> >
> > > > > in
> >
> > > > > >>> its own way, change/narrow the recommendations on node hardware
> >
> > > > specs?
> >
> > > > >
> >
> > > > > SAI won't crash the node during compaction and requires less
> CPU/IO.
> >
> > > > >
> >
> > > > > * SAI defines global memory limit for compaction instead of
> per-index
> >
> > > > > memory limit used by SASI.
> >
> > > > >   For example, compactions are running on 10 tables and each has 10
> >
> > > > > indexes. SAI will cap the
> >
> > > > >   memory usage with global limit while SASI may use up to 100 *
> >
> > > per-index
> >
> > > > > limit.
> >
> > > > >
> >
> > > > > * After flushing in-memory segments to disk, SAI won't merge
> on-disk
> >
> > > > > segments while SASI
> >
> > > > >   attempts to merge them at the end.
> >
> > > > >
> >
> > > > >   There are pros and cons of not merging segments:
> >
> > > > > ** Pros: compaction runs faster and requires fewer resources.
> >
> > > > > ** Cons: small segments reduce compression ratio.
> >
> > > > >
> >
> > > > > * SAI on-disk format with row ids compresses better.
> >
> > > > >
> >
> > > > >
> >
> > > > > >>> I understand the desire in keeping out of scope the longer term
> >
> > > > > deprecation
> >
> > > > > >>> and migration plan, but… if SASI provides functionality that
> SAI
> >
> > > > > doesn't,
> >
> > > > > >>> like tokenisation and DelimiterAnalyzer, yet introduces a body
> of
> >
> > > > code
> >
> > > > > >>> ~somewhat similar, shouldn't we be roughly sketching out how to
> >
> > > > reduce
> >
> > > > > the
> >
> > > > > >>> maintenance surface area?
> >
> > > > >
> >
> > > > > Agreed that we should reduce maintenance area if possible, but only
> >
> > > very
> >
> > > > > limited
> >
> > > > > code base (eg. RangeIterator, QueryPlan) can be shared. The rest of
> > the
> >
> > > > > code base
> >
> > > > > is quite different because of on-disk format and cross-index files.
> >
> > > > >
> >
> > > > > The goal of this CEP is to get community buy-in on SAI's design.
> >
> > > > > Tokenization,
> >
> > > > > DelimiterAnalyzer should be straightforward to implement on top of
> > SAI.
> >
> > > > >
> >
> > > > > >>> Can we list what configurations of SASI will become deprecated
> > once
> >
> > > > SAI
> >
> > > > > >>> becomes non-experimental?
> >
> > > > >
> >
> > > > > Except for "Like", "Tokenisation", "DelimiterAnalyzer", the rest of
> >
> > > SASI
> >
> > > > > can
> >
> > > > > be replaced by SAI.
> >
> > > > >
> >
> > > > > >>> Giv

Re: Committing `CASSANDRA-13701 Lower default num_tokens` and the dtest slowdown…

[Adam Holmberg]

After discussing with a few stakeholders it sounds like folks agree that
optimizing dtest speed is a worthy endeavor. What is less clear are
concrete things that should be done. Since a brainstorming session failed
to materialize on CASSANDRA-13701, we thought it would make sense to start
with an open analysis.

A ticket[1] has been created for analysis and further follow-up. We welcome
any concrete ideas people already have in mind.

Kind regards,
Adam Holmberg

[1] https://issues.apache.org/jira/browse/CASSANDRA-16079

On Mon, Aug 24, 2020 at 12:17 PM Mick Semb Wever  wrote:

>  I believe the speed of our CI runs
> > is of common interest. What do you think? Does this sound feasible? Who
> is
> > in?*
> >
>
>
> I agree. I'm in. I have some ideas to add to the mix. Thanks Ekaterina.
>


-- 
Adam Holmberg
e. adam.holmb...@datastax.com
w. www.datastax.com

Check in on CASSANDRA-15393

[Blake Eggleston]

Hi dev@,

Mick asked that I check in w/ the dev list about CASSANDRA-15393. There's some 
concern regarding the patch and it's suitability for inclusion in 4.0-beta.

CASSANDRA-15393 reduces garbage created by compaction and the read paths by 
about 25%. It's part of CASSANDRA-15387, which, including this patch, reduces 
garbage from the read and compaction paths by about 50%. CASSANDRA-15393 does 
this by supporting byte array backed cell and clustering types, which is 
acheived by abstracting the backing type (ByteBuffer/byte[]) from the 
serialization logic. 

To avoid paying the allocation cost of adding a container object, singleton 
"accessor" objects are used to operate on the actual data. See here for an 
example: https://gist.github.com/bdeggleston/52910225b817a8d54353125ca03f521d

Mick and Robert Stupp have raised a few concerns, summarized below:

1. The patch is large (208 files / ~3.5k LOC)
2. Concerns about impact on stability
3. Parameterizing cell/clustering value types in this way makes 
ClassCastExceptions possible.
4. implications of feature freeze

The patch is large, but the vast majority of it is adding type parameters to 
things. The changes here are wide, but not deep. The most complex parts are the 
collection serializers and other places where we're now having to do offset 
bookkeeping. These should be carefully reviewed, but they shouldn't be too 
difficult to verify and I've added some randomized tests to check them against 
a wide range of schemas. I'll also run some diff tests against clusters 
internally.

Parameterizing cell and clustering values does make ClassCastExceptions 
possible, but java's type system guards against this for the most part. 
Regarding the feature freeze, I don't think it applies to performance 
improvements.

Back to the point about stability though: in pracice, compaction gc is a major 
contributor to cluster instability. In my experience, about 30% of availability 
issues are gc related. Also, compaction gc tends to be the limiting factor for 
repair, host replacements, and other topology changes, which limits how quickly 
you can recover from other issues. So the patch does add some risk, but I think 
it's a net win for stability.

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

Re: Contributing research on C* usage for blog

[sankalp kohli]

+1 to the blog post

On Thu, Aug 27, 2020 at 10:53 AM Jeff Jirsa  wrote:

> I don't have any questions, but datastax folks: thanks for funding stuff
> like this.
>
> (I'd love to see it as a blog post, I'd also love to see people internalize
> the negative feedback and assumed features and determine whether or not
> people are working on the right things)
>
> On Thu, Aug 27, 2020 at 10:25 AM Melissa Logan 
> wrote:
>
> > Hi everyone,
> >
> > Several open source projects conduct regular user surveys to understand
> > current usage and adoption trends, e.g. OpenStack, Kubernetes, Cloud
> > Foundry, etc. They can be informative to the community and other end
> users.
> > It looks like the C* community may have conducted these in the past per
> > https://twitter.com/cassandra/status/649287871577219072.
> >
> > Recently, an independent research company called Clearpath Strategies was
> > funded by DataStax to conduct research on C* usage and adoption, and they
> > would like to contribute the findings to the community.
> >
> > 901 practitioners were interviewed. I analyzed the data and summarized
> in a
> > document here:
> >
> >
> https://docs.google.com/document/d/1aM8muvbldPhSJdgrsM0OiLGvb5wfjwc5uutSCNfGup8/edit?usp=sharing
> >
> > If this seems broadly useful, I’m proposing that we publish to the C*
> blog.
> > New graphics will be created in the same styling as the 4.0 graphic as
> > noted in the doc.
> >
> > If you have questions about the data, please share here or in the doc.
> >
> > Appreciate your thoughts and consideration.
> >
> > Melissa
> >
>

Re: Check in on CASSANDRA-15393

[Joshua McKenzie]

Is there an ETA on them landing? The later, the more risk to stability of
GA due to lack of time soaking.

On Thu, Aug 27, 2020 at 4:01 PM Blake Eggleston
 wrote:

> Hi dev@,
>
> Mick asked that I check in w/ the dev list about CASSANDRA-15393. There's
> some concern regarding the patch and it's suitability for inclusion in
> 4.0-beta.
>
> CASSANDRA-15393 reduces garbage created by compaction and the read paths
> by about 25%. It's part of CASSANDRA-15387, which, including this patch,
> reduces garbage from the read and compaction paths by about 50%.
> CASSANDRA-15393 does this by supporting byte array backed cell and
> clustering types, which is acheived by abstracting the backing type
> (ByteBuffer/byte[]) from the serialization logic.
>
> To avoid paying the allocation cost of adding a container object,
> singleton "accessor" objects are used to operate on the actual data. See
> here for an example:
> https://gist.github.com/bdeggleston/52910225b817a8d54353125ca03f521d
>
> Mick and Robert Stupp have raised a few concerns, summarized below:
>
> 1. The patch is large (208 files / ~3.5k LOC)
> 2. Concerns about impact on stability
> 3. Parameterizing cell/clustering value types in this way makes
> ClassCastExceptions possible.
> 4. implications of feature freeze
>
> The patch is large, but the vast majority of it is adding type parameters
> to things. The changes here are wide, but not deep. The most complex parts
> are the collection serializers and other places where we're now having to
> do offset bookkeeping. These should be carefully reviewed, but they
> shouldn't be too difficult to verify and I've added some randomized tests
> to check them against a wide range of schemas. I'll also run some diff
> tests against clusters internally.
>
> Parameterizing cell and clustering values does make ClassCastExceptions
> possible, but java's type system guards against this for the most part.
> Regarding the feature freeze, I don't think it applies to performance
> improvements.
>
> Back to the point about stability though: in pracice, compaction gc is a
> major contributor to cluster instability. In my experience, about 30% of
> availability issues are gc related. Also, compaction gc tends to be the
> limiting factor for repair, host replacements, and other topology changes,
> which limits how quickly you can recover from other issues. So the patch
> does add some risk, but I think it's a net win for stability.
>
> Thoughts?
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Check in on CASSANDRA-15393

[Blake Eggleston]

Caleb is currently working through his second round of review, and Marcus said 
he's about halfway through his review as of this morning. So I'd expect it to 
be committed within a week or so.

> On Aug 27, 2020, at 5:09 PM, Joshua McKenzie  wrote:
> 
> Is there an ETA on them landing? The later, the more risk to stability of
> GA due to lack of time soaking.
> 
> On Thu, Aug 27, 2020 at 4:01 PM Blake Eggleston
>  wrote:
> 
>> Hi dev@,
>> 
>> Mick asked that I check in w/ the dev list about CASSANDRA-15393. There's
>> some concern regarding the patch and it's suitability for inclusion in
>> 4.0-beta.
>> 
>> CASSANDRA-15393 reduces garbage created by compaction and the read paths
>> by about 25%. It's part of CASSANDRA-15387, which, including this patch,
>> reduces garbage from the read and compaction paths by about 50%.
>> CASSANDRA-15393 does this by supporting byte array backed cell and
>> clustering types, which is acheived by abstracting the backing type
>> (ByteBuffer/byte[]) from the serialization logic.
>> 
>> To avoid paying the allocation cost of adding a container object,
>> singleton "accessor" objects are used to operate on the actual data. See
>> here for an example:
>> https://gist.github.com/bdeggleston/52910225b817a8d54353125ca03f521d
>> 
>> Mick and Robert Stupp have raised a few concerns, summarized below:
>> 
>> 1. The patch is large (208 files / ~3.5k LOC)
>> 2. Concerns about impact on stability
>> 3. Parameterizing cell/clustering value types in this way makes
>> ClassCastExceptions possible.
>> 4. implications of feature freeze
>> 
>> The patch is large, but the vast majority of it is adding type parameters
>> to things. The changes here are wide, but not deep. The most complex parts
>> are the collection serializers and other places where we're now having to
>> do offset bookkeeping. These should be carefully reviewed, but they
>> shouldn't be too difficult to verify and I've added some randomized tests
>> to check them against a wide range of schemas. I'll also run some diff
>> tests against clusters internally.
>> 
>> Parameterizing cell and clustering values does make ClassCastExceptions
>> possible, but java's type system guards against this for the most part.
>> Regarding the feature freeze, I don't think it applies to performance
>> improvements.
>> 
>> Back to the point about stability though: in pracice, compaction gc is a
>> major contributor to cluster instability. In my experience, about 30% of
>> availability issues are gc related. Also, compaction gc tends to be the
>> limiting factor for repair, host replacements, and other topology changes,
>> which limits how quickly you can recover from other issues. So the patch
>> does add some risk, but I think it's a net win for stability.
>> 
>> 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: Check in on CASSANDRA-15393

[Joshua McKenzie]

No qualms with that here; it'll be a bit before GA so this has time to soak.

On Thu, Aug 27, 2020 at 8:21 PM Blake Eggleston
 wrote:

> Caleb is currently working through his second round of review, and Marcus
> said he's about halfway through his review as of this morning. So I'd
> expect it to be committed within a week or so.
>
> > On Aug 27, 2020, at 5:09 PM, Joshua McKenzie 
> wrote:
> >
> > Is there an ETA on them landing? The later, the more risk to stability of
> > GA due to lack of time soaking.
> >
> > On Thu, Aug 27, 2020 at 4:01 PM Blake Eggleston
> >  wrote:
> >
> >> Hi dev@,
> >>
> >> Mick asked that I check in w/ the dev list about CASSANDRA-15393.
> There's
> >> some concern regarding the patch and it's suitability for inclusion in
> >> 4.0-beta.
> >>
> >> CASSANDRA-15393 reduces garbage created by compaction and the read paths
> >> by about 25%. It's part of CASSANDRA-15387, which, including this patch,
> >> reduces garbage from the read and compaction paths by about 50%.
> >> CASSANDRA-15393 does this by supporting byte array backed cell and
> >> clustering types, which is acheived by abstracting the backing type
> >> (ByteBuffer/byte[]) from the serialization logic.
> >>
> >> To avoid paying the allocation cost of adding a container object,
> >> singleton "accessor" objects are used to operate on the actual data. See
> >> here for an example:
> >> https://gist.github.com/bdeggleston/52910225b817a8d54353125ca03f521d
> >>
> >> Mick and Robert Stupp have raised a few concerns, summarized below:
> >>
> >> 1. The patch is large (208 files / ~3.5k LOC)
> >> 2. Concerns about impact on stability
> >> 3. Parameterizing cell/clustering value types in this way makes
> >> ClassCastExceptions possible.
> >> 4. implications of feature freeze
> >>
> >> The patch is large, but the vast majority of it is adding type
> parameters
> >> to things. The changes here are wide, but not deep. The most complex
> parts
> >> are the collection serializers and other places where we're now having
> to
> >> do offset bookkeeping. These should be carefully reviewed, but they
> >> shouldn't be too difficult to verify and I've added some randomized
> tests
> >> to check them against a wide range of schemas. I'll also run some diff
> >> tests against clusters internally.
> >>
> >> Parameterizing cell and clustering values does make ClassCastExceptions
> >> possible, but java's type system guards against this for the most part.
> >> Regarding the feature freeze, I don't think it applies to performance
> >> improvements.
> >>
> >> Back to the point about stability though: in pracice, compaction gc is a
> >> major contributor to cluster instability. In my experience, about 30% of
> >> availability issues are gc related. Also, compaction gc tends to be the
> >> limiting factor for repair, host replacements, and other topology
> changes,
> >> which limits how quickly you can recover from other issues. So the patch
> >> does add some risk, but I think it's a net win for stability.
> >>
> >> 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: naming development branches consistently

[Ekaterina Dimitrova]

Considering the project currently follows the trunk-based development
workflow, I am +1 for trunk
In general I am fine also with main, but trunk sounds more accurate to me
personally.

On Wed, 26 Aug 2020 at 4:03, Benjamin Lerer 
wrote:

> +1 for trunk or main (slight preference for trunk)
>
>
>
>
>
>
>
> On Tue, Aug 25, 2020 at 8:52 PM Mick Semb Wever  wrote:
>
>
>
> > +1 for trunk and main.
>
> >
>
> > Thanks for raising this Brandon.
>
> >
>
> >
>
> >
>
> > On Tue, 25 Aug 2020 at 20:40, Cyril Scetbon 
> wrote:
>
> >
>
> > > Scott, I don’t think it does and don’t see any offense in what I’ve
> said.
>
> > > Can you be more specific instead of sending a link with rules numbers
>
> > that
>
> > > I don’t think apply ? I can also send links to definitions of all the
>
> > words
>
> > > in the rules you sent but it could be a waste of time. We can continue
>
> > that
>
> > > discussion on the list or in private up to you.
>
> > >
>
> > > Cyril Scetbon
>
> > >
>
> > > > On Aug 25, 2020, at 11:50 AM, Scott Hirleman <
> scott.hirle...@gmail.com
>
> > >
>
> > > wrote:
>
> > > >
>
> > > > Cyril, your commentary violates the code of conduct of the ASF
>
> > > >  re rules #2
> and
>
> > > #5.
>
> > > > It could also be very hurtful to those who feel this is important, as
>
> > > many
>
> > > > in the community do. Please think before pushing further on this as
>
> > > > projects need to be welcoming and inclusive. Thank you.
>
> > > >
>
> > > >> On Mon, Aug 24, 2020 at 4:00 PM Cyril Scetbon <
> cyril.scet...@free.fr>
>
> > > wrote:
>
> > > >>
>
> > > >> Wow, thanks for the link Almero. I suppose the dictionary comes next
>
> > > then
>
> > > >> 🤷‍♂️
>
> > > >>
>
> > > >>> On Aug 24, 2020, at 6:54 PM, Gouws, Almero
>
> > 
> > > >
>
> > > >> wrote:
>
> > > >>>
>
> > > >>>
>
> > > >>
>
> > >
>
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.zdnet.com_article_mysql-2Ddrops-2Dmaster-2Dslave-2Dand-2Dblacklist-2Dwhitelist-2Dterminology_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=42Z7FyMoAS1DbvgKNjU8zxi7xTPVAGalPzk7bfmRVgw&m=_KDgXvABczXFLLkrzUHvgLTiGM6FTGPWWBXafxw3QNM&s=nV5LVK6p96fblFesy94FxPvsMgwZbtgwNyXh5wM7yXE&e=
>
> > > >>>
>
> > > >>> -Almero
>
> > > >>>
>
> > > >>> -Original Message-
>
> > > >>> From: Cyril Scetbon 
>
> > > >>> Sent: Monday, August 24, 2020 3:47 PM
>
> > > >>> To: dev@cassandra.apache.org
>
> > > >>> Subject: RE: [EXTERNAL] naming development branches consistently
>
> > > >>>
>
> > > >>> CAUTION: This email originated from outside of the organization. Do
>
> > not
>
> > > >> click links or open attachments unless you can confirm the sender
> and
>
> > > know
>
> > > >> the content is safe.
>
> > > >>>
>
> > > >>>
>
> > > >>>
>
> > > >>> Seriously ? Should we change how MySQL architectures are defined ?
>
> > > >> Should we remove it from the dictionary too ? Just to see how
> radical
>
> > It
>
> > > >> could be … 🤦‍♂️
>
> > > >>>
>
> > >  On Aug 24, 2020, at 12:12 PM, Brandon Williams 
>
> > > >> wrote:
>
> > > 
>
> > >  With the current social climate I thought removing the master
>
> > >  reference rather than proliferating it would be better.
>
> > > 
>
> > >  On Mon, Aug 24, 2020 at 11:07 AM Joshua McKenzie <
>
> > > jmcken...@apache.org>
>
> > > >> wrote:
>
> > > >
>
> > > > Why not rename "trunk" to "master" in C*?   =D
>
> > > >
>
> > > > On Mon, Aug 24, 2020 at 11:17 AM Brandon Williams <
>
> > dri...@gmail.com>
>
> > > >> wrote:
>
> > > >
>
> > > >> Hello,
>
> > > >>
>
> > > >> Currently in the cassandra repo our development branch is named
>
> > > >> 'trunk', but this is not consistently used in other repos, such
> as
>
> > > >> cassandra-dtest, -builds, -website, and probably others, which
> use
>
> > > >> 'master' instead.  I propose we rename all of those to 'trunk'
> to
>
> > > >> match.
>
> > > >>
>
> > > >> Kind Regards,
>
> > > >> Brandon
>
> > > >>
>
> > >
>
> >
>
>

Re: Contributing research on C* usage for blog

[Nate McCall]

>
>
>
> 901 practitioners were interviewed. I analyzed the data and summarized in a
> document here:
>
> https://docs.google.com/document/d/1aM8muvbldPhSJdgrsM0OiLGvb5wfjwc5uutSCNfGup8/edit?usp=sharing
>
> If this seems broadly useful, I’m proposing that we publish to the C* blog.
> New graphics will be created in the same styling as the 4.0 graphic as
> noted in the doc.
>

This is great, Melissa! Would love to see a blog post on this.

Cheers,
-Nate