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. How
+1 to more visibility. What examples of JDK internals access did you have
in mind? I was just trying to think of some practical application where
this would apply. Cheers!
>
> I think implementation has to work according to expectations described in
> CEP, and have enough tests to prove it. You can follow the progress of the
> patch whenever CEP is accepted and code is published to learn about the
> details.
>
Thanks, will follow the implementation.
If you'd like t
Usually implementations are not documented in CEP. I think implementation has
to work according to expectations described in CEP, and have enough tests to
prove it. You can follow the progress of the patch whenever CEP is accepted and
code is published to learn about the details.
If you'd like
I’m not opposed to this, although I think there is less need for it. Do you
have an example of where you think this policy could have resulted in a
different outcome?
> On 1 Sep 2022, at 16:31, Ekaterina Dimitrova wrote:
>
> Hi everyone,
>
> Some time ago we added a note to the project Cassa
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 accessi
On Thu, Sep 1, 2022 at 11:20 AM Alex Petrov wrote:
> There will be no changes required to our existing Paxos implementation. We
> can just use it. Besides, Paxos is only used as K-sequencer. There is no
> need to use Raft, and both existing LWTs (with Multi-Paxos) and Accord
> aren't tied to a si
