devel thread here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4DA76SDSIJSTSPFWGYH6PKMSRMYC522Q/

The guideline pages are already versioned; that's why we have a wiki. I'd think that packagers could indicate that their package conforms to the guidelines as of some date if they wanted to indicate that. I personally don't see any use in codifying that unless some heretofore unseen army of package reviewers have appeared and cleaned the existing queue of pending reviews. Maybe if that were done there would be some spare effort to be used to re-review some existing packages.

Personally I'm not interested in adding or maintaining additional version formalization to the guideline pages; I already devote more time to maintaining them than I really should and don't want to introduce additional process which would only make that worse. We already have a reasonable mechanism for tracking changes over time (i.e. the wiki).

Note that some documents used to have version numbers but I believe by now I've removed most of them. Nobody ever updated them in any case.

Replying to [ticket:646 leamas]:

• Would we benefit from having actual releases of the GL?
• Would we benefit form tracking the last version of the GL checked in the
  packages, similar to haw Debian do?

I am not familiar with Debian processes. Would you care to enumerate what problems would be solved by doing this?

Right now, I tend to agree with tibbs: This sounds like busy work.

The basic problem addressed by the Debian workflow is "Updating Packages to current GL."

As josh agreed in the ML thread, the basic package lifecycle is that it is reviewed to current standards, and after that start lagging from the actual standards. To which extent depends on the maintainer.

Debian addresses this using:

• Explicit versioning of the guidelines.
• Tracking the last version of the guidelines used in each package.
• When updating the guidelines, there is also a release-notes with what-to-do when updating a package from previous version.

The state of the "last-GL-version-used" header is easily checked by tools like rpmlint. It's then up to the maintainer to either leave it as-is, just update the header or actually reading the GL release notes and fix what should be fixed before updating the header. It's far from fool-proof, but it gives a hint to maintainers to update the package. And, not least, some help on how.

Please note that I'm not really arguing that we should do this, I'm just asking a question if we can learn something from this workflow. After all, that packages lag from the current GL is an obvious problem.

After all, that packages lag from the current GL is an obvious problem.

That's true, but I think he biggest part of this problem (from my perspective) is lack of resource, not lack of process -- if we did this, there would need to be a commitment from... someone... to actively update packages according to latest guidelines.

Anecdotally, I tend to update for guideline changes when I touch the spec file for other reasons. (I.e. New upstream version? May as well migrate to use that fancy new macro too.) But I don't have time to inspect all my (nearly 100) packages every time there are guideline changes.

The responsible person is IMHO the package maintainer; full stop.

That said, perhaps the point here is that Debian offers some support for maintainers which are willing to update their packages that Fedora doesn't. In fedora:

• there is no indication whatsoever that a package is outdated w r t current GL
• The only info on what has changed is the messages in devel about updated GL.

Your anecdotal story is from a person maintaining the GL. As such you know what has changed. We mere mortal doesn't.

The lack of resources is of course the main problem. But perhaps it would be possible to make the updating task easier for maintainers somehow. And perhaps this would make packages somewhat more aligned with current GL, dunno.

It was josh who made me file this as a fpc ticket. Given the state of this discussion it might perhaps be better to just close the ticket and possibly continue in devel. I have just a vague idea that Debian handles something we don't, and that something could be learned.

Ok, for the sake of discussion: adapting the debian update process for fedora.

• The fpc work with the GL is done in the wiki, more or less as now.
• Early in the release cycle, the GL are released. This includes ripping the wiki content to a pagure instance where the GL are published with a given version (i. e., a git tag).
• The release is accompanied by release notes describing what's changed, possibly making the current messages in devel obsolete. These are targeted to package maintainers.
• Publishing the GL basically says that for this release GL vers X.Y should be used.
• A new header Standards-Version: is added to rpm.
• The Taskotron checks and rpmlint are patched to check that the Standards-Version field matches the correct version of the GL for current release. Warning messages includes pointers to relevant GL release notes.

Adapting this workflow would give package maintainers a hint about updating to current GL, and more focused documentation on how to make this update, all in all making this task easier.

FWIW, the taskotron checks on Standards-Version would also give a hint about packages which are not maintained at all, not even on the level to update this field.

Again, this is not to say this is what we should do, it's merely putting some flesh this idea in order to contribute to the discussion.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-09-15/fpc.2016-09-15-16.01.txt):

• 646 Versioning the Packaging Guidelines (geppetto, 16:15:32)

• ACTION: tibbs Write comment about using 13th months of year to fix
  policy, and make everything better. (geppetto, 16:26:41)

The bottom line here is, I think, that there are plenty of things we can take away from the idea, but that we don't actually want to do this. Emulating Debian policy is rather not something we are able, or even want, to do.

Some specific points:

• We don't want to lock guideline updates to the release cycle.
• We don't have the manpower to deal with guideline changes in the way you suggest.
• Adding versions to the guidelines isn't helpful as we have dates and wiki history, so you're just swapping one number for another.
• Adding RPM tags (what you call a header) isn't up to us, and isn't something we could actually use without angering a significant number of maintainers. At least until EPEL7 goes EOL, as RPM doesn't ignore unrecognized tags and you can't assume that

I'm starting various other initiatives to clean up packages and otherwise detect guidelines conformance where possible, but this is an enormously difficult task that it will take some time. Until our packaging in general is in a cleaner state, doing much else would just not be productive (especially when it takes time away from what we really need to be doing).