|
|
| Line 1: |
Line 1: |
| This page is intended to give some guidelines relevant to package maintainers who wish to update a package on an already-released branch. It does not apply to rawhide updates or newly introduced packages.
| | #REDIRECT Updates_Policy |
| | |
| These are not intended to be prescriptive rules. Package maintainers are expected to to exercise their own common sense and good judgement.
| |
| | |
| For more information on the responsibilities of package maintainers, see [[PackageMaintainers/MaintainerResponsibility]].
| |
| __TOC__
| |
| | |
| == Maintaining Stability ==
| |
| | |
| Many Fedora users update automatically, so it is most important that an update doesn't cause a users' applications or system to stop working suddenly.
| |
| | |
| Bug fix updates should generally be first pushed to testing and only pushed to stable after it has achieved sufficient karma in bodhi.
| |
| | |
| New upstream releases should not necessarily be pushed to release branches. The benefit of the bugfixes and new features should be weighed up against the risk of regressions. A simple rule of thumb might be to not push the new release unless it fixes a problem that a user has reported or introduces a new feature that Fedora users have previously requested. Even still, for more complex packages it might make sense to backport the specific patch needed.
| |
| | |
| The risk of serious regressions always exists and should be considered. Rawhide is the development branch, so package maintainers may choose to push an update to rawhide for a period before pushing to a release branch. This gives rawhide testers the opportunity to catch any issues before <code>updates-testing</code> or <code>updates</code> users can be affected.
| |
| | |
| == Update Descriptions ==
| |
| | |
| Fedora users who do not update automatically may review (via PackageKit) the descriptions attached to updates before choosing whether they should apply them.
| |
| | |
| Package maintainers should bear this in mind when preparing updates in bodhi and try to help their users make as informed decisions as possible. The <code>Bugs</code> and <code>Notes</code> fields are all the information which users have available when reviewing updates in the PackageKit UI (and not e.g. the RPM <code>%changelog</code> entries).
| |
| | |
| Some suggestions on what to include in an update:
| |
| | |
| # For bug fixes, the appropriate bug numbers in the <code>Bugs</code> field | |
| # For security issues, links to the appropriate CVEs
| |
| # For new upstream releases, a summary of the important changes and/or a link to the upstream changelog
| |
| # Any other information that might be important to users
| |
| | |
| Good judgement is required, though. Overly verbose descriptions can be almost as useless as overly terse descriptions.
| |
| | |
| == Rate of Updates ==
| |
| | |
| Package maintainers should bear in mind that not all Fedora users have good Internet bandwidth available.
| |
| | |
| Where a package is likely to require many small changes in a short period of time, a maintainer may decide to commit and build those changes individually but push them as a single update. This is especially important in the case of large packages.
| |
| | |
| [[Category:Package Maintainers]]
| |
