#75 Update fesco/modules/ROOT/pages/Policy_for_orphan_and_retired_packages.adoc
Closed a year ago by zbyszek. Opened 2 years ago by fed500.
fesco/ fed500/fesco-docs deprecate_policy  into  main

@@ -1,7 +1,7 @@ 

- = Policy for Orphan and Retired Packages

+ = Policy for Orphan, Retired or Deprecated Packages

  

- [orphaning_and_retiring_packages]

- == Orphaning and retiring packages

+ [orphaning_retiring_and_deprecating_packages]

+ == Orphaning, retiring and deprecating packages

  

  When Fedora maintainers do not want or are not able

  to maintain a package any longer,
@@ -26,6 +26,10 @@ 

  are encouraged to do it as early in the development cycle as possible.

  Shortly after the prior release is branched is a good time.

  

+ Maintainers should only deprecate packages when they pose a security

+ concern or will not build in Fedora without significant changes. Orphaning

+ and retirement should be preferred to deprecation.

+ 

  [[unorphaning_and_unretiring_packages]]

  == Unorphaning and unretiring packages

  
@@ -41,4 +45,5 @@ 

  [[guides]]

  == Guides

  * https://docs.fedoraproject.org/en-US/package-maintainers/Package_Orphaning_Process/[Package Orphaning Process]

- * https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/[Package Retirement Process] 

\ No newline at end of file

+ * https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/[Package Retirement Process]

+ * https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/[Prerequisites for deprecation] 

\ No newline at end of file

Add policy for deprecation

Where is this coming from?

Why is retirement preferred to deprecation?

Please see https://fedoraproject.org/wiki/Changes/DeprecationPolicy#Upgrade%2Fcompatibility_impact

Deprecation prevents addition of new packages. Orphaning allows for removal of the package should no one choose to maintain it in Fedora. Retired and orphaned packages can be unorphaned and unretired. Deprecated packages are effectively removed from the distribution once they are orphaned/retired.

Maintainers should only deprecate packages when they pose a security concern or will not build in Fedora without significant changes.

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.

This would be a helpful summary to have. "Made unnecessary/redundant by changes in the ecosystem" seems to be a valid criteria. Retirement then would address security concerns.

FTBFS packages cannot be marked as deprecated, though it seems they will be retired if they remain in this state for some time.

The level of maintenance/upstream activity is not a great criteria for deprecation
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5YVAAPUEEBCIEMH5FX6CX5RTMTMDOS2Y/#5YVAAPUEEBCIEMH5FX6CX5RTMTMDOS2Y

FTBFS packages cannot be marked as deprecated, though it seems they will be retired if they remain in this state for some time.

That is true. But that is a technical limitation that has nothing to do with the proposed change.

Both https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UZQGGQ6TSHF4EDOHFZU5YJVIZJ66M5RW/ and https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KJ27QCQ4I7HUYUIZOVVYBA3J6XTG3J7F/ explain quite well why the proposed change doesn't not fit our practice. We can make changes, of course, but we shouldn't add policy which directly contradicts what we do in various well-known cases.

I'll close this. Feel free to reopen with a new pull request after feedback has been addressed.

Pull-Request has been closed by zbyszek

a year ago