I want to make sure I'm reading this right. A packager puts a package into EPEL. If the user does nothing, that package continues to be in EPEL. If the user wishes to end support, they sent off and email, compose one final build (if it can compose), wait for it to land, then send off another email. If I'm reading this right, I don't see much of a difference between this and what we currently do. The only main difference I see is that we currently say you should maintain the package until the end of the life of the major RHEL release. Or, is that what this is about, just changing the lifetime that a person can commit to. On Wed, Feb 13, 2019 at 9:49 AM Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > https://fedoraproject.org/wiki/EPEL/Changes/Release_based_package_lifetimes > > == Summary == > > The change moves expected package lifetime to that of a Red Hat > Enterprise Linux minor release. > > > == Owner == > * Name: [[User:smooge|Stephen Smoogen]] > * Email: smooge@xxxxxxxxx > > == Detailed Description == > > Extra Packages for Enterprise Linux is a sub-project of Fedora which > recompiles various Fedora packages against various Red Hat Enterprise > Linux releases. When EPEL was started, RHEL lifetimes were 5 years and > it was thought that the repository could have similarly long > lifetimes. Major rebasing of versions were not to be allowed, and fast > moving software was frowned on. > > Over time, the lifetime of a RHEL release grew, and the way RHEL > releases rebased themselved overtime also changed. This has meant that > packagers in EPEL were bound to support software longer than RHEL did > and unable to rebase like RHEL could. > > The current proposal is closely linked to release based composes but > does not depend on it. The changes are as follows: > > Packagers commit to maintaining software in EPEL for at least one RHEL > minor release or 13 months, whichever is shorter. If a packager needs > to stop maintaining the software, they should do the following > > * announce on epel-devel list that they are no longer able to > maintain the package and give the reasons. If someone can take it > over they can do so here. > * release one final version with an additional file named > 'README-RETIRED.txt' in the %docs section which says this software > is retired. > * wait until that package arrives in updates. > * let the EPEL release manager know that the package needs to be > retired for the next release. > > Otherwise the latest update of the package will be retagged for the > next compose of EPEL and will appear without problems. > > If the situation requires a major ABI/API change (security, a new > minor compose occurs, a new LTS package is released) a packager should > announce to epel-devel and put in a ticket in the epel pagure instance > to track. Updates can then be made and will show up in either > /updates/ or the next major.minor compose. > > == Benefit to Fedora == > > * Packagers will feel more likely to make their packages available in > EPEL. > * Users of EPEL will have more software and know it is being kept up. > > > == Scope == > > * Other developers: > * Policies and guidelines: The above need to be coded clearer > * Trademark approval: N/A > > == Known Change Impacts == > > > == How To Test == > > == User Experience == > > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) > * Contingency deadline: > * Blocks release? > * Blocks product? > > == Release Notes == > > -- > Stephen J Smoogen. > _______________________________________________ > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
