>>>>> "MH" == Miro Hrončok <mhroncok@xxxxxxxxxx> writes: MH> Is there anything we can do to prevent maintains to override the MH> change with their next "magical sync" from jira/RDO/github/whatever? MH> I mean we already say they should not do that, but can we somehow MH> make sure they actually won't? This question comes up with every mass change that gets auto-reverted. I took out the needless %defattr calls a while back and several were added back in, some because of this and some because one maintainer in particular reverted a bunch of the commits Certainly there are things we could do, but… we have avoided doing them in the past. Possibilities: * Checks in the git hooks to prevent pushes which introduce certain things into specfiles. * Adding checks as part of the build process (brp scripts, generally) to fail builds when things are detected. Some other distros fail builds if rpmlint fails (which obviously would be bad for our current rpmlint configuration but could certainly be improved.) * Some limited checks are available within koji to prevent some classes of builds from being tagged. * More post-build checks (rpmgrill, greenwave). Most effort has gone into the latter item, which of course gets ignored just as the existing rules against wiping out changes are ignored. There has been no will to implement the "stronger" checks. If those checks were implemented, the pain would be great due to Fedora's history of not strongly enforcing this type of "packaging quality", so everything has to be "opt out" at best and the general case is that quality checks are "opt in". - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
