m sure everyone is looking forward to the improved consistency of this
>> work.
>>
>>
>> From: Ekaterina Dimitrova
>> Date: Wednesday, 20 October 2021 at 22:27
>> To: dev@cassandra.apache.org
>> Subject: Re: [DISCUSS] CASSANDRA-15234
>> Hi everyone
s looking forward to the improved consistency of this
> work.
>
>
> From: Ekaterina Dimitrova
> Date: Wednesday, 20 October 2021 at 22:27
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] CASSANDRA-15234
> Hi everyone,
>
> I think it is time to summarize t
decisions.
I’m sure everyone is looking forward to the improved consistency of this work.
From: Ekaterina Dimitrova
Date: Wednesday, 20 October 2021 at 22:27
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CASSANDRA-15234
Hi everyone,
I think it is time to summarize the discussion.
First
ers getting an overall description. Even
> as a
> > developer who understands most of the toggles I found the old file very
> > hard to navigate.
> > >>
> > >> I also don’t see why we cannot have both heavily commented versions
> and
> > uncommented
why we cannot have both heavily commented versions and
> uncommented (or lightly commented) versions.
> >>
> >> I don’t personally see why multiple different config templates would be
> confusing if they’re in a suitably labelled directory, even if we settle on
> one for t
l user to need, so it’s
>> particularly easy to navigate.
>>
>>
>> From: Ekaterina Dimitrova
>> Date: Friday, 3 September 2021 at 14:40
>> To: dev@cassandra.apache.org
>> Subject: Re: [DISCUSS] CASSANDRA-15234
>>>>
>>>> It
ve a pared-down config that
> has only those properties we expect the normal user to need, so it’s
> particularly easy to navigate.
>
>
> From: Ekaterina Dimitrova
> Date: Friday, 3 September 2021 at 14:40
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] CASSANDRA-
:40
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] CASSANDRA-15234
> >
> > It’s worth noting that the two don’t have to be in >conflict: we could
> offer two template yaml with the parameters grouped differently, for users
> to decide for themselves.
Sure, my only concer
>
> at this point we shouldn’t be comparing the length of the files I think as
> the comments were stripped only for the POC
Ah - my misunderstanding then. I assumed we were relying on the local
context of the grouping to provide insight into the functionality of
parameters and removed the comment
> >
> > It’s worth noting that the two don’t have to be in >conflict: we could
> offer two template yaml with the parameters grouped differently, for users
> to decide for themselves.
Sure, my only concern is that three versions of the yaml could bring
confusion (we will have backward compatibilit
Reading through the two, the grouping approach seems like it's a lot more
friendly to newcomers as well as providing context specific cues for
relationships between params you're editing. Showing and not telling, if
you will.
Opening up a 1500+ line .yaml file is very daunting, even if most of it
Thanks for bringing this back up; Caleb and I were talking about the lack of
clarity with regard to CASSANDRA-16896, fleshing this out would make those
configs nicer!
> To standardize naming - that we did by agreeing to the form noun_verb
If we can document this, it would be great as stuff li
Thanks for bringing this to the list Ekaterina!
It’s worth noting that the two don’t have to be in conflict: we could offer two
template yaml with the parameters grouped differently, for users to decide for
themselves.
The proposals primarily define parameter names differently, with my proposal
13 matches
Mail list logo
