On Fri, 15 Feb 2019 at 11:45, Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > > 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? > We should have a policy on those. I don't know how to word it so would like someone else to take a stab please. > > > > > > > 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 > _______________________________________________ > 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
