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.
These are not intended to be prescriptive rules. Package maintainers are expected to to exercise their own common sense and good judgement.
Understand your responsibilities
Refer
http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility
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 updates-testing or updates 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 Bugs and Notes fields are all the information which users have available when reviewing updates in the PackageKit UI (and not e.g. the RPM %changelog entries).
Some suggestions on what to include in an update:
- For bug fixes, the appropriate bug numbers in the
Bugsfield - 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.