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 | >> +---------------------------------------------------------------+ >> >>
