đź‘‹ 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 <e.dimitr...@gmail.com> 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 <e.dimitr...@gmail.com> > wrote: > >> Git and jira , nothing specific >> >> On Fri, 2 Sep 2022 at 12:51, Derek Chen-Becker <de...@chen-becker.org> >> 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 <djo...@apache.org> 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 <e.dimitr...@gmail.com> >>>>> 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 | >>> +---------------------------------------------------------------+ >>> >>>
