To Jungtaek.

Apache Spark community allows the post-commit review and we can revert always.
There is no exception for that.

However, give that your context, if you are trying to say that the reason of 
your `-1` is only for lack of 1-week waiting, you are wrong again.
You are trying to mislead the community once more. I'm really worried about 
that misinformation.

The existing vote literally declares that Apache Spark PMC's security 
activities are the beyond of the grace period.

Dongjoon.

On 2026/11/09 03:28:23 Jungtaek Lim wrote:
> 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]
> >
> >
> 

---------------------------------------------------------------------
To unsubscribe e-mail: [email protected]

Reply via email to