#633 Document unwritten rule about guideline exceptions
Closed: Fixed None Opened 6 years ago by tibbs.

From the time that FPC was formed, we've had the understanding that unless we write guidelines with specific entries for every single package in the distribution, for every rule we make there will be a package which needs to break it. So there's been an unwritten rule which basically says that if you just can't obey some guideline or another, you document it in your specfile and move on, and if you get into a fight with a reviewer over it, eventually you'd go to FPC, FESCO, etc. This is why the guidelines sometimes use "must", sometimes use "should", and sometimes just make suggestions.

Prompted by the recent FESCo ticket https://fedorahosted.org/fesco/ticket/1587 (regarding "offensive" package names) and the related discussion in today's FESCo meeting, I decided to propose that we codify this policy by adding something like the following section near the top of the main guidelines page.

Begin draft.

== General Exception Policy ==

These guidelines can never cover all possible contingencies, there will always be packages which need exceptions. It is the packager's responsibility to follow these guidelines as closely as is feasible and to clearly document, as comments in the package specfile, instances where they cannot be followed.

If, in a guideline, the language "should" or "is suggested" is used and it is not feasible for the package to conform to that guideline, the packager may deviate from the guideline. The deviation MUST be minimal, and both the nature of the deviation and the reasoning behind it MUST be documented in the specfile.

Where the language "must", "is required to" or "needs to" is used, the packager may deviate from the guideline only with approval from the packaging committee. Please follow the procedure at https://fedoraproject.org/wiki/Packaging_Committee for making these requests. (XXX Add the procedure there and use a link to the subsection.)

End draft.

This also highlights the need, which I have long tried to avoid, for using more precise language when it comes to indicating the strength of guidelines. I generally prefer that they read as English instead of Lawyer, but I guess it's time to tighten things up. I can see three states: MUST, SHOULD and "is suggested/is recommended/please consider", where the latter is just a something the packager can ignore without an explanation. If we pass this draft, I'll start going over the existing pages to tighten up the language.

And yes, I know I have enough on my plate already, but I saw this as a way out of this mess without having to worry about writing a guideline on "offensive" package names.

Edit comment:

"The deviation MUST be minimal, and both the nature of the deviation and the reasoning behind it MUST be documented in the specfile."


"The nature of the deviation and the reasoning behind it must be documented in the specfile."

Because it is not clear what makes a deviation minimal or why that is felt to be a requirement. If packagers are already required to document every deviation, or bring it up before committee if it is required, that should be discouraging enough.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-06-23/fpc.2016-06-23-16.00.txt):

  • 633 Document unwritten rule about guideline exceptions (geppetto,

  • ACTION: Document unwritten rule about guideline exceptions (+1:8,
    0:0, -1:0) (geppetto, 16:42:30)

I wrote this up (including the language change from comment 2 as discussed in the meeting, plus a couple of fixes to my poor grammar). I'll work on cleaning up the naming guidelines first.

Announcement text:

A section has been added to the guidelines which documents the procedure for deviation from those guidelines. Work will now begin to clarify the language in existing guidelines into the usual SHOULD and MUST categories to help reduce confusion surrounding the "strength" of guidelines.

Metadata Update from @james:
- Issue assigned to james

5 years ago

Login to comment on this ticket.