On Fri, 15 Feb 2019 at 09:39, Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > 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. > 1. It codifies what we do. The items that packagers keep bringing up is that EPEL means I have to maintain a package for the lifetime of RHEL. While that was true when EPEL-4/5 were being planned.. it hasn't been but people keep saying it is. Being clear in policy saying packages in EPEL are only committed to for N amount of time makes it clear to both packagers and consumers. 2. With the release cycle change, it means that /pub/epel/releases/7.6/ will eventually moved to /pub/archive/epel/releases/7.6/ . If the user needs something that was in 7.6 but not in 7.7 they can grab it out of there... many of them are already doing it out of kojipkgs or /pub/archive/fedora/releases/18 anyway so we aren't saving the user from themselves. Does that help? > > 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 -- 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
