OK I wouldn't mind pushing this further. Not a huge deal as long as the policy is kept.
That said, it is totally fine for any committer to call -1 on merged dependency PR and revert the commit (and maybe additionally put it back in 7 days after) once they find the PR to violate the policy we have agreed to. That can play as a technical justification of veto and there is no argument. If we agree upon this, I'm totally fine with it. On Mon, Nov 9, 2026 at 11:39 AM Dongjoon Hyun via dev <[email protected]> wrote: > Jungteak, > > 1. Technically, the Apache Spark community uses the community merge script > which is independent from AGENTS.md. There is no individual skill. > > - https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py > > 2. We only agreed on the commit polity, not a policy to make any PRs. > A contributor is still able to make his/her PRs freely to the > Apache Spark community repository (including the dependency change). > That was what we wanted and agreed. > > In short, I don't think your suggestion is a continuation of the existing > community consensus. And, I'm -1 for any alteration on the existing > decision > on this area because I believe it's too much in the OSS community. > > Dongjoon. > > On 2026/11/08 23:58:36 Jungtaek Lim wrote: > > I'll clarify just to avoid any conflict. > > > > What I want to do is very simple - we discussed and voted for this > subject, > > which seems not that uneasy to codify to AGENTS.md. The condition isn't > > very complicated, and I think someone is already adding on their skill or > > custom agent. > > > > I just want to see it in centralized AGENTS.md if we think this is a sort > > of BYLAWS today. It isn't really only the direction we codify AGENTS to > > block filing the PR (while it is also one of the direction with potential > > side effect) - we can codify AGENTS to formulate the description for > > dependency PR to emphasize the release date, and list up known > > vulnerabilities fixes in that release from very early of the PR. And we > can > > codify AGENTS to take the decision into consideration while doing AI > > review; PMC members can merge the PR with their justification being > > clarified in the PR comment, to override the review if AGENTS do show > false > > positives. > > > > My question is why this is going to be an individual's skill rather than > > our shared skill. > > > > On Mon, Nov 9, 2026 at 7:11 AM Jungtaek Lim < > [email protected]> > > wrote: > > > > > It is probably not very hard to add the check for CVE if the release > has > > > been published due to CVE. > > > > > > LLM can scan a codebase and find bugs and we submit PRs automatically > and > > > PRs are reviewed automatically via LLM. And we can’t ask LLM to check > > > whether there is no CVE fix on the release. One of the two is probably > > > incorrect. > > > > > > 2026년 11월 9일 (월) 오전 1:46, Dongjoon Hyun via dev <[email protected] > >님이 > > > 작성: > > > > > >> -1 for Jungtaek's additional suggestion because we voted to allow PMC > to > > >> upgrade security-related dependency changes under the same rule. > > >> > > >> https://lists.apache.org/thread/cqbxzvtyvpgfy8nqodjpo2ochfw01lzk > > >> [VOTE] Set a buffer time before we upgrade to the latest version of > > >> dependencies > > >> > > >> The following is the original vote content. > > >> > > >> > The proposal is: > > >> > For the apache/spark repo only, we can only upgrade third-party > > >> > dependencies (including Apache projects) to a version released at > least > > >> > seven days ago. This covers Java, Python and all other dependencies. > > >> > Security upgrades are exempted and will be conducted by PMCs. > > >> > > >> AFAIK, the agent has been already helping us in the above context > > >> and Jungtaek's additional suggestion is only to ban > > >> the legit Apache Spark PMC security activities. > > >> > > >> Dongjoopn. > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe e-mail: [email protected] > > >> > > >> > > > > --------------------------------------------------------------------- > To unsubscribe e-mail: [email protected] > >
