Re: naming development branches consistently

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://www.zdnet.com/article/mysql-drops-master-slave-and-blacklist-whitelist-terminology/ > > -Almero > > -Original Message- > From: Cyril Scetbon

Re: naming development branches consistently

Just saw it’s actually a thing https://github.com/github/renaming … > On Aug 24, 2020, at 6:47 PM, Cyril Scetbon wrote: > > Seriously ? Should we change how MySQL architectures are defined ? Should we > remove it from the dictionary too ? Just to see how ra

RE: naming development branches consistently

https://www.zdnet.com/article/mysql-drops-master-slave-and-blacklist-whitelist-terminology/ -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 e

Re: naming development branches consistently

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 rath

Re: naming development branches consistently

+1 to trunk and main > On Aug 24, 2020, at 9:59 AM, Brandon Williams wrote: > > I'm fine with that, though it's probably a tab bit more involved than > the rest due to website/doc changes. > > On Mon, Aug 24, 2020 at 11:29 AM Aleksey Yeshchenko > wrote: >> >> Last thing I want is to bikeshed,

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

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.

Re: naming development branches consistently

I'm fine with that, though it's probably a tab bit more involved than the rest due to website/doc changes. On Mon, Aug 24, 2020 at 11:29 AM Aleksey Yeshchenko wrote: > > Last thing I want is to bikeshed, but seems like ‘main’ is what’s being > adopted by GitHub, so we might as well rename all ‘m

Re: naming development branches consistently

Last thing I want is to bikeshed, but seems like ‘main’ is what’s being adopted by GitHub, so we might as well rename all ‘master’ and ’trunk’ branches to that. > On 24 Aug 2020, at 17:22, Joshua McKenzie wrote: > > Ah! Totally didn't even think of that. Good point. > > On Mon, Aug 24, 2020 at

Re: naming development branches consistently

Ah! Totally didn't even think of that. Good point. On Mon, 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 > wrote: > >

Re: naming development branches consistently

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 wrote: > > Why not rename "trunk" to "master" in C*? =D > > On Mon, Aug 24, 2020 at 11:17 AM Brandon Williams wrote: > > > Hell

Re: naming development branches consistently

Why not rename "trunk" to "master" in C*? =D On Mon, Aug 24, 2020 at 11:17 AM Brandon Williams 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 prob

naming development branches consistently

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, Brand

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

*Hello everyone,* *I was thinking about the latest discussions on the topic. During our last Cassandra Contributor meeting we agreed it would be good to cover in our agenda discussions/brainstorming on different topics. So I would like to suggest to organize a brainstorming session on CASSANDRA-137

Re: [DISCUSS] CEP-7 Storage Attached Index

Adding to Duy's questions… * Hardware specs 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? Fl

Re: [DISCUSS] CEP-7 Storage Attached Index

> I think the project needs to conclude the discussions that keep being started around the "definition of done" before determining what sufficient quality assurance looks like for this feature. Looking forward to the Test/QA guideline. Thanks for bringing this up. > the CEP process suggest a wik