packaging-committee

#1458 Review Guidelines: explicitly add relaxed rules for "only technically new" packages
Merged by james. Opened by decathorpe.
Unknown source master

Download 1458.patch

This is a followup for these two tickets:

  • https://pagure.io/packaging-committee/issue/1452
  • https://pagure.io/fesco/issue/3391

I proposed in the FESCo ticket to make it explicit that some rules from the Packaging Guidelines need not apply when packaging something that is already packaged for Fedora, and other FESCo members seemed to be generally in favor of doing so.

There are multiple places where package reviews are documented:

  • https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/
  • https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/
  • https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/

But documenting and approving exceptions to the packaging guidelines are in the domain of the FPC, so I'm opening this as a PR here.

I've split my changes into two parts for easier review - the first commit

  • cleans up some weird formatting issues (looks like the page was never cleaned up after the automated conversion from Wiki markup),
  • applies SemBR (well, at least I tried my best), and
  • removes a heading that had no content below it (not sure if there wasn't anything there to begin with, or if it got lost from the conversion).

The second commit adds a new section to document what FESCo seemed to agree would make sense here.

Note that I have intentionally not added :last-reviewed: AsciiDoc metadata to this document, since I only made formatting changes and didn't make any changes to the actual content (other than the added section). The page could still greatly benefit from being updated for what has changed since the turn of the millennium ...

:thumbsup:

I don't understand how this new rule is supposed to be applied. It most important part is

Some guidelines that apply to "new" packages do not need to be applied when reviewing packages that are only "added" to the distribution in the sense that the name of the source package is "new" but the component was already available from an existing package

It does a good job of describing what those "not-really-new" packages are. But "some guidelines" is very vague. I would expect an explicit enumeration of steps than can be skipped.

BTW. I noticed the following:

The package is being created so that multiple versions of the same package can coexist in the distribution (or coexist between EPEL and RHEL). The package MUST be properly named according to the naming guidelines and MUST NOT conflict with all other versions of the same package.

We routinely use this for "compat packages". But compat packages quite often conflict with one another, or at least their -devel subpackages conflict. Is it intended that those cases require an explicit exception from FPC?

I would expect an explicit enumeration of steps than can be skipped.

I explicitly did not do this, because those exceptions are, in part, already documented elsewhere (legal guidelines, packaging guidelines, fesco package review policy, etc.), and I did not want to add a fifth place.

Feel free to suggest a better solution and / or wording.

We routinely use this for "compat packages". But compat packages quite often conflict with one another, or at least their -devel subpackages conflict. Is it intended that those cases require an explicit exception from FPC?

Can you file a separate ticket for this so it doesn't get lost?

Note that the review guidelines already say that compat packages and epel-only packages don't need to go through review, so they are already implicitly exempt from complying with the latest version of the packaging guidelines (though of course they should!). So in essence this only changes things for package splits and renames, which do need to go through package review, because there is no blanket exception for them.

lgtm

+1

+1

rebased onto a709c6f6e141fc842c5aec8a60f7fa0061c563b6

Pull-Request has been merged by james
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.