👋
I finally got the chance to put down a proposal for a section at the end of
the Cassandra Code Style document.
Please help a fellow non-native speaker and definitely not a writer with
some constructive criticism. :-)
My proposal is in this commit -
https://github.com/ekaterinadimitrova2/cassandra-website/commit/4a9edc7e88fd9fc2c6aa8a84290b75b02cac03bf
I noticed the Dependencies section suggested in the past by Benedict was
missing, even if we had a consensus around that. I added it back from the
original doc.
Best regards ,
Ekaterina
On Fri, 9 Sep 2022 at 13:34, Ekaterina Dimitrova
wrote:
> Hi everyone,
> Seems to me that people will be fine with heads up on the mailing list and
> details on tickets?
> Plus update of the Code Style to add a point around that, as suggested.
>
> I will leave this thread open a few more days and if there are no
> objections I will continue with documenting it.
>
> Have a great weekend everyone!
>
> On Fri, 2 Sep 2022 at 14:01, Ekaterina Dimitrova
> wrote:
>
>> Git and jira , nothing specific
>>
>> On Fri, 2 Sep 2022 at 12:51, Derek Chen-Becker
>> wrote:
>>
>>> I think it's fine to state it explicitly rather than making it an
>>> assumption. Are we tracking any usage of internals in the codebase
>>> currently?
>>>
>>> Cheers,
>>>
>>> Derek
>>>
>>> On Fri, Sep 2, 2022 at 6:30 AM Ekaterina Dimitrova <
>>> e.dimitr...@gmail.com> wrote:
>>>
“ A quick heads up to the dev list with the jira would be sufficient
for anybody interested in discussing it further to comment on the jira.”
Agreed, I did’t mean voting but more or less we have the lazy consensus
or sharing concerns. Discussing them on a ticket should be enough but it
needs to happen. Also, it shouldn’t be more often than adding dependencies
I guess.
JDK team is only closing more and more internals and warning us about
potential breakages. I want to prevent us from urgent fixing in patch
releases and to ease the maintenance.
I think ensuring that it is clearly documented why an exception is
acceptable and what options were considered will be of benefit for
maintenance. We can revise in time what has changed.
“ . Unless absolutely needed we should avoid accessing the internals.
Folks on this project should understand why. We can make the dangers of
this explicit in our contributor documentation. ”
+1
On Fri, 2 Sep 2022 at 1:26, Dinesh Joshi wrote:
> Personally not opposed to this. However, this is something that should
> be vetted closely by the reviewers. Unless absolutely needed we should
> avoid accessing the internals. Folks on this project should understand
> why.
> We can make the dangers of this explicit in our contributor documentation.
> However, requiring an entire dev list discussion around it seems
> unnecessary. A quick heads up to the dev list with the jira would be
> sufficient for anybody interested in discussing it further to comment on
> the jira. WDYT?
>
> Dinesh
>
> On Sep 1, 2022, at 8:31 AM, Ekaterina Dimitrova
> wrote:
>
> Hi everyone,
>
>
> Some time ago we added a note to the project Cassandra Code Style:
> “New dependencies should not be included without community consensus
> first being obtained via a [DISCUSS] thread on the
> dev@cassandra.apache.org mailing list”
>
> I would like to suggest also to add a point around accessing JDK
> internals. Any patch that suggests accessing internals and/or adding even
> more add-opens/add-exports to be approved prior commit on the mailing
> list.
>
> It seems to me the project can only benefit of this visibility. If
> something is accepted as an exception, we need to have the right
> understanding and visibility of why; in some cases maybe to see for
> alternatives, to have follow up tickets opened, ownership taken. In my
> opinion this will be very helpful for maintaining the codebase.
>
> If others agree with that I can add a sentence to the Code Style.
> Please let me know what you think.
>
> Best regards,
> Ekaterina
>
>
>
>>>
>>> --
>>> +---+
>>> | Derek Chen-Becker |
>>> | GPG Key available at https://keybase.io/dchenbecker and |
>>> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
>>> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC |
>>> +---+
>>>
>>>
