On the opensuse-packaging mailing list, we've recently formed a team that will take care of the packaging guidelines and introduced a small process to change them: http://en.opensuse.org/openSUSE:Packaging_guidelines_change_process
As part of that process, we're announcing regularly the changes to the packaging guidelines. Since this is a first such announcement, it is not a complete change but just points out a few things from the past few months. In the future, we will send out this email once a month.
The Packaging guidelines can be found at http://en.opensuse.org/openSUSE:Packaging_guidelines .
List of changes =============== 1) New Lua Guidelines 2) Reworked font guidelines 3) Documenting changes in packages 4) Teams involved, contact
Details ======= 1) New Lua Guidelines
We now have guidelines for lua: http://en.opensuse.org/openSUSE:Packaging_Lua.
2) Reworked font guidelines
The packaging of fonts has been completely changed, and is documented at http://en.opensuse.org/openSUSE:Packaging_Fonts
3) Documenting changes in packages
The openSUSE review team is now also enforcing proper documenting changes in packages:
First, the .changes entry (rpm changelog) surves two purposes: - News for the user - History tracking of packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixes).
3.1) Information about updates A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed.
Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, Added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will.
3.2) Documenting patch life cycle The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines .
Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed)
The main appeal is to the devel project maintainers / reviewers, to keep out for those rules, to live according to them, as it is frustrating for everybody if a package needs to be declined by the openSUSE Factory Review team:
- The dev prj maintainer is the one getting the 'decline' (as it was usually a forwarded request), which often leaves the 'fixing' to the devel project maintainers, where the 'originator' of the fix would have been willing to actually do that...
Note: The review team is not enforcing the usage of patch markup unless the package already follows this convention.
4) Teams involved, contact
I mentioned two teams previously, these are the openSUSE review team (details at http://en.opensuse.org/openSUSE:OpenSUSE_review_team) and the team taking care of the guidelines (details at http://en.opensuse.org/openSUSE:Packaging_guidelines_change_process#Team_mem...). You can reach both via the openSUSE-packaging mailing list.
On behalf of the teams, Andreas