(→Scope) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 59: | Line 59: | ||
== Feedback == | == Feedback == | ||
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | <!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> | ||
- | |||
* Sorry, but that is just plain wrong, IMO. For example, we have used the deprecation process for the sonatype Java packages. They built just fine, and there were no security issues. Instead, they were made unnecessary and obsolete by changes in the Java ecosystem. If they were orphaned, they'd get retired after some delay, but this is not what was wanted. We want to keep them around as long as something depends on them, but disallow any such new dependencies to be added. Both orphaning and retirement have completely different semantics. Deprecation is for the case where the maintainers know that the package should be removed, orphaning is for the case where the package is or may still be useful but maintainers don't have enough time, and retirement is for the case where the package is not useful or broken and can be get rid of immediately. https://pagure.io/fesco/fesco-docs/pull-request/75 | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
| Line 116: | Line 119: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
This should allow for smoother upgrades by enabling improvement of packages that are dependencies as the community will | |||
have an opportunity to improve them should they choose to do so. | |||
== How To Test == | == How To Test == | ||
Latest revision as of 09:14, 10 July 2023
Requirements for Package Deprecation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
Summary
Detail requirements for package deprecation as unmaintained and fails to build or a security concern.
Owner
- Name: Benson Muite
- Email: benson_muite@emailplus.org
Current status
- Targeted release: Fedora Linux 40
- Last updated: 2023-07-10
- [<will be assigned by the Wrangler> devel thread]
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
Package deprecation prevents addition of new packages to Fedora that depend on the deprecated package. This is reasonable when a package is a security concern or no longer works in Fedora. To encourage a broad software ecosystem, package deprecation should only be done in exceptional cases and otherwise packages should just be orphaned and retired to allow other maintainers to take over.
Feedback
-
- Sorry, but that is just plain wrong, IMO. For example, we have used the deprecation process for the sonatype Java packages. They built just fine, and there were no security issues. Instead, they were made unnecessary and obsolete by changes in the Java ecosystem. If they were orphaned, they'd get retired after some delay, but this is not what was wanted. We want to keep them around as long as something depends on them, but disallow any such new dependencies to be added. Both orphaning and retirement have completely different semantics. Deprecation is for the case where the maintainers know that the package should be removed, orphaning is for the case where the package is or may still be useful but maintainers don't have enough time, and retirement is for the case where the package is not useful or broken and can be get rid of immediately. https://pagure.io/fesco/fesco-docs/pull-request/75
Benefit to Fedora
The main benefit is a clear rationale for deprecating packages. There is a rationale for Orphaning and Retiring packages but none for deprecation. Having a broad set of natively packaged software makes a distribution more useful. Deprecating packages that could still be useful weakens the ecosystem. One could examine status of upstream projects to make suggestions if a packager should become an upstream maintainer and if maintainers of packages that depend on a package should consider removing that package as a dependency. However, forcing new packages not to depend on a particular package without valid cause will weaken the ecosystem since it maybe the case that an existing package can be improved.
Scope
- Proposal owners: Add this policy to the FESCO policy documents.
- Other developers: No work needed from other developers other than giving a clear rationale when proposing to deprecate a package.
- Release engineering: No changes needed
- Policies and guidelines: Change required draft pull request
- Trademark approval: N/A (not needed for this Change)
- Alignment with Community Initiatives: No current community initiatives.
Upgrade/compatibility impact
This should allow for smoother upgrades by enabling improvement of packages that are dependencies as the community will have an opportunity to improve them should they choose to do so.
How To Test
No tests needed.
User Experience
Users will have a wider selection of natively compiled packages that are well integrated with Fedora.
Dependencies
This change does not target a specific package directly, though it will allow for a broader set of dependencies.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) This is a policy change, no contingency mechanism is needed.
- Contingency deadline: This is a policy change, can be implemented if there is agreement.
- Blocks release? No
Documentation
Pull request with suggested change.