Hi,
As PMC members/committers we aren't supposed to abdicate this to legal or to
contributors. Despite the fact that we aren't equipped to solve this problem we
are supposed to be making sure that code contributed is non-infringing.
This is a quotation from Roman Shaposhnik from this legal thre
I don’t think I said we should abdicate responsibility? I said the key
point is that contributors, and more importantly reviewers and committers
understand the ASF guidelines and hold all code to those standards. Any
suspect code should be blocked during review. As Roman says in your quote,
this i
Hello Everyone,
I was debugging
https://lists.apache.org/thread/ykkwhjdpgyqzw5xtol4v5ysz664bxxl3 and found
the issue. The Result inner class has a circular dependency on its inner
classes. (
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundConnectionInitiato
> Ultimately it's the contributor's (and committer's) job to ensure that
their contributions meet the bar for acceptance
To me this is the key point. Given how pervasive this stuff is becoming, I
don’t think it’s feasible to make some list of tools and enforce it. Even
without getting into extra
> To clarify are you saying that we should not accept AI generated code until
> it has been looked at by a human
I think AI code would normally be the same process as normal code; the author
and reviewers all reviewed the code; I am not against AI code in this context.
> then written again wit
Hi,
To clarify are you saying that we should not accept AI generated code until it
has been looked at by a human and then written again with different "wording"
to ensure that it doesn't directly copy anything?
Or do you mean something else about the quality of "vibe coding" and how we
shouldn
I think the risk outlined here is real only if we don’t run the upgrade
tests to trunk, no?
That should be probably the ultimate safeguard. And while pre-commit we do
not run all tests for every patch - I think that does not apply to JDK
addition/removal where we would run all suites normally pre-
I originally had "everyone supports highest language level whee" which of
course would fail to build on older branches.
So this new paradigm would give us the following branch:language level support
(assuming JDK bump on each release which also won't always happen):
- trunk: latest
- trunk-1: la
> fine tuning encourage not reproducing things verbatim
> I think not producing copyrighted output from your training data is a
> technically feasible achievement for these vendors so I have a moderate level
> of trust they will succeed at it if they say they do it.
Some team members and I discu
Only thing I’d suggest changing here is “Trunk targets the language level of
that JDK” shouldn’t happen until after we’ve confirmed the back port of the new
JDK LTS changes to previous versions - otherwise, you have folks starting to
use new language features and then have to rip them all out wh
Updated 5.0 and trunk branches to reflect this under CASSANDRA-20681. Let
us know if this is, for some reason, not enough and you want to propagate
this information further.
On Wed, May 28, 2025 at 11:32 PM Jeremiah Jordan
wrote:
> +1
>
> On May 28, 2025 at 4:28:22 PM, Mick Semb Wever wrote:
>
11 matches
Mail list logo
