>
>
> This is just wonderful and it is an example how it should be done.
>
>
>
> Why can not be this done for other CEPs too? What was different for CEP-37
> when docs were written together with the code but it can not be done
> similarly for other CEPs as well?
>
sking for is really not a rocket science and nothing
>>>>> "rigid". I am all open to lower the requirements.
>>>>>
>>>>>
>>>>>
>>>>> I am not asking for rephrasing whole CEP and present it to a user. I
>>&
ption of the most common usages and scenarios with
>>>> most important consequences and all configuration parameters.
>>>>
>>>>
>>>>
>>>> Let's take a look at CEP-37.
>>>>
>>>>
>>>>
>>>> *https://cas
>>>
>>>
>>> *https://cassandra.apache.org/doc/trunk/cassandra/managing/operating/auto_repair.html
>>> <https://cassandra.apache.org/doc/trunk/cassandra/managing/operating/auto_repair.html>*
>>>
>>>
>>>
>>> This is just wonde
ra/managing/operating/auto_repair.html
>> <https://cassandra.apache.org/doc/trunk/cassandra/managing/operating/auto_repair.html>*
>>
>>
>>
>> This is just wonderful and it is an example how it should be done.
>>
>>
>>
>> Why can
>
>
> Anyway, I would really appreciate if we stayed on track and discussed the
> proposition mentioned in my first email - the end goal is to codify the
> need to provide documentation together with the feature. If not provided
> together, it might be in a separate ticket
e: Thursday, 1 May 2025 at 14:37
To: dev@cassandra.apache.org
Cc: Rolo, Carlos , Miklosovic, Stefan
, dev@cassandra.apache.org
Subject: Re: [DISCUSS] Requirement to document features before releasing them
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
I am opposed to this. T
I love the idea of having great docs, but blocking at this point probably
hurts the project more than it helps. How about we see if we can find
people that are actually interested in working on them? Figuring that out
needs to happen regardless. I suspect not many of us want to, or have time
to.
o decide.
@Jon, @Patrick I've tested this with a driver PR from my team, and it works
wonders!
Cheers,
Carlos
From: Brandon Williams
Sent: 01 May 2025 15:51
To: dev@cassandra.apache.org
Subject: Re: [DISCUSS] Requirement to document features before releas
On Thu, May 1, 2025 at 7:37 AM Benedict wrote:
> I am opposed to this. There’s too much imprecision in the “rule” while
> simultaneously being much too rigid, and it will be improperly enforced (we
> already have lots of rule breaking around modifying public APIs, that
> should have discuss threa
ed
> together, it might be in a separate ticket which will be a blocker for the
> next release.
>
>
>
> I might initiate the voting thread for that ...
>
>
>
> Regards
>
>
>
>
>
> *From: *Rolo, Carlos
> *Date: *Thursday, 1 May 2025 at 12:30
> *To:
@cassandra.apache.org
Cc: Miklosovic, Stefan
Subject: Re: [DISCUSS] Requirement to document features before releasing them
I am bit out of the loop on how/if this would extend to driver sub-projects.
Because this makes 100% sense, and in the driver space as well. Looking into Java driver docs and making
Subject: Re: [DISCUSS] Requirement to document features before releasing them
I am bit out of the loop on how/if this would extend to driver sub-projects.
Because this makes 100% sense, and in the driver space as well. Looking into
Java driver docs and making others similar would be a great
!
From: Miklosovic, Stefan via dev
Sent: 01 May 2025 08:07
To: David Capwell ; dev@cassandra.apache.org
Cc: Miklosovic, Stefan
Subject: Re: [DISCUSS] Requirement to document features before releasing them
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
@cassandra.apache.org
Cc: Miklosovic, Stefan
Subject: Re: [DISCUSS] Requirement to document features before releasing them
EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
I wonder at what level can we enforce this. What I mean, in modeling testing I
have found some odd behaviors that
when releasing it. Same goes for all other non-trivial
> features.
>
>
>
>
>
> *From: *Josh McKenzie
> *Date: *Wednesday, 30 April 2025 at 22:11
> *To: *dev
> *Cc: *Miklosovic, Stefan
> *Subject: *Re: [DISCUSS] Requirement to document features before
> relea
releasing it. Same goes for all other non-trivial features.
>
>
> From: Josh McKenzie mailto:jmcken...@apache.org>>
> Date: Wednesday, 30 April 2025 at 22:11
> To: dev mailto:dev@cassandra.apache.org>>
> Cc: Miklosovic, Stefan <mailto:stefan.mikloso...@netapp.com&g
documentation should be definitely something to think about
when releasing it. Same goes for all other non-trivial features.
From: Josh McKenzie
Date: Wednesday, 30 April 2025 at 22:11
To: dev
Cc: Miklosovic, Stefan
Subject: Re: [DISCUSS] Requirement to document features before releasing them
The current state of LLMs has made this a simple task and one of the best
use cases. I get writing docs sucks, but I don't think that's much of a
burden any more if the tools are applied.
On Wed, Apr 30, 2025 at 1:11 PM Josh McKenzie wrote:
> This makes intuitive sense to me.
>
> In our case we
This makes intuitive sense to me.
In our case we could tie documentation to the process of promoting a feature
from “experimental” to production ready, though I fear that might leave wiggle
room for primary authors of some features to leave them as experimental
forever, not desiring to take on
I am on OpenSearchCon and there was a discussion about the documentation of
features. In a nutshell, the policy they seem to have is that there are some
minimal requirements for documentation in place for each feature introduced.
That way, there is no way (or it is greatly minimised) that there
21 matches
Mail list logo
