English
Who is Allowed to Modify Which Packages
With the current Git layout each member of the xref:Provenpackager_policy.adoc[provenpackager] group can modify most packages. As an exception, some specific packages can be closed to provenpackagers, upon FESCo approval.
Digest
Normally the maintainer that is listed as primary maintainer in the https://src.fedoraproject.org[dist-git repository] of a package is the only one who modifies the package or gives others permission (e.g. by accepting them as co-maintainers) to commit and build changes for that package. Bugzilla or repository's pull requests are normally the best way to contact the package maintainer or to send them patches and suggestions because they are neutral and trackable; but poking people once or twice in IRC or directly via mail might be a good idea.
But there are certain exceptions where maintainers need to accept that other packagers will modify the packages they are responsible for. Those exceptions are described in detail below. They mostly boil down to this: In any of the following cases, the xref:Provenpackager_policy.adoc[provenpackagers] are allowed to fix stuff in other peoples packages:
a packager doesn't fix important bugs in time
there are problems known that might be bad for the whole Project or to a lot of users of the repo/a particular package
the changes are quite minor or considered as a general cleanup to a lot of packages
the changes are part of a Fedora Objective, with a specific plan approved by FESCo
Details
This is section will try to explain above rules in more detail. It will never be able to cover all things that might arise in Fedora, but it should give everyone some idea how to lay out the above rules.
Unhandled issues
Packagers should keep track of the packages for which which they are responsible. That means:
respond in bugs reported in bugzilla, especially fast if it's a serious problem like a security issue
fix issues without explicit poking if it is mentioned in the problem reports somewhere
that includes:
fix EVR problems, when they get mentioned in problem reports (for example, a broken upgrade path)
fix dependency issues (including those in the devel repo)
the script sends problems to both the maintainer and the list
participate in mass-rebuilds and fix xref:Fails_to_build_from_source_Fails_to_install.adoc[Fails to Build from Source] bugs