On Fri, Feb 15, 2019 at 8:34 AM Stephen John Smoogen <smo...@gmail.com> wrote: > > On Fri, 15 Feb 2019 at 09:39, Troy Dawson <tdaw...@redhat.com> 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? >
Yes it does. Do we want to put anything in about packages that no longer install due to updates. Whether those updates are in EPEL or RHEL. An example would be when EPEL7 nodejs goes to nodejs 8 (or 10), There will be a handful of packages that no longer will be installable. Can we have a policy for those, or is that beyond the scope of this proposal? > > > > On Wed, Feb 13, 2019 at 9:49 AM Stephen John Smoogen <smo...@gmail.com> > > 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: smo...@gmail.com > > > > > > == 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@lists.fedoraproject.org > > > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > > > 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@lists.fedoraproject.org > > _______________________________________________ > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > > 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@lists.fedoraproject.org > > > > -- > Stephen J Smoogen. > _______________________________________________ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
