On Fri, 15 Feb 2019 at 11:45, Troy Dawson <tdawson(a)redhat.com> 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(a)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: smooge(a)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(a)lists.fedoraproject.org
> > > > To unsubscribe send an email to
epel-devel-leave(a)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.fedoraproj...
> > > _______________________________________________
> > > epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
> > > To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
>
>
>
> >
--
> > Stephen J Smoogen.
> > _______________________________________________
> > epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
> _______________________________________________
> epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
--
Stephen J Smoogen.