This change looks good to me. It is clear and concise. On Fri, Nov 4, 2022 at 9:50 PM Ekaterina Dimitrova <e.dimitr...@gmail.com> wrote:
> 👋 > > 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 | >>>> +---------------------------------------------------------------+ >>>> >>>>
