-1 as long as this is opt-out instead of opt-in, that would just be a footgun-as-a-service.

-1 for similar reasons.

-1

I understand the objective, but part of being a good package maintainer is having a deep understanding of all of the steps along the way. Automated services are great, but they should be opt-in and the maintainer should understand what pieces it is automating.

We already have a lot of very specific and obfuscated aspects of package maintenance (cough RPM macros cough). We should avoid continuing that trend.

I'm voting +1 here.

One thing I think keeps getting overlooked is that the "opt-out" part is just for whether Packit sends a single merge request when the package is first imported. The maintainer has the option to accept this merge request and enable Packit support or else close it. The merge request description will include information about the benefits and risks. If they reject the merge request, nothing happens.

If it was going to automatically add Packit configuration without maintainer consent, that would be a definite "no", but that's not what's happening here.

And yes, there may be some people that blindly accept the merge request, but I suspect the opposite will be more common: a glut of emails to the Fedora Devel list asking for clarification before accepting an unexpected contribution.

+1 for the same reasons as @sgallagh

I’m on the fence here

Some ecosystems need to be opted out anyway (eg Rust, Golang) - there blindly enabling packit is unworkable

And it’s unclear if there will be an easy way to choose what level of packit automation is provided (I normally only turn it on for Rawhide on my packages)

So… if I really have to vote I might be -1 but I could be persuaded if those two issues are addressed

I’m on the fence here

Some ecosystems need to be opted out anyway (eg Rust, Golang) - there blindly enabling packit is unworkable

The rust and golang tooling could be modified to just add the opt-out flag when requesting the repos. I don't see that being a blocker.

And it’s unclear if there will be an easy way to choose what level of packit automation is provided (I normally only turn it on for Rawhide on my packages)

The submitted MRs will be reviewable, not automatically merged. If the amount of automation provided is not desirable, the MRs can be rejected.

So… if I really have to vote I might be -1 but I could be persuaded if those two issues are addressed

The rust and golang tooling could be modified to just add the opt-out flag when requesting the repos. I don't see that being a blocker.

Huh? The tool to request repos is fedpkg, there are no language-specific tools / wrappers for this.

Sorry, I thought I remembered there was automation to request dependencies too. But yeah, there's a flag for fedpkg to skip the Packit MR.

This was discussed in the meeting today:
AGREED: The proposal is approved with the modification that it's just opt-in for F42. Switching to opt-out can be proposed for F43 (+9, 0, 0)
INFO: FESCo also requests that the Packit team investigate conditionalizing for known problematic packages such as rust-* to be excluded from future opt-out.

See https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-01-07/fesco.2025-01-07-17.01.log.html for the details of the discussion.