On Thu, 10 Oct 2019 at 04:04, LAHAYE Olivier <olivier.lahaye@xxxxxx> wrote: > > Hi, > > What is the strategy regarding packages like nextcould that has a major update every 5/6 months? > I mean, regarding incompatible upgrades policy. > The incompatible upgrades policy was something we could never really enforce and so is a gentleman's agreement that it won't happen. [I thought I also removed all references to it on our policies but seem to have missed it somewhere.] The problem is that EPEL is a volunteer group. No one is assigned to work permanently on making EPEL work. It is done by people who are either assigned temporarily to make something go.. or just by the rest of us when we have finished our regular day-to-day tasks. This means we try to put in policies to allow people to self-manage problems as best they can. In the case of any incompatible upgrades, the current policy is that the maintainer should email the lists that they want to upgrade to a version which will break things. They outline the plan they have and why they are doing it. The EPEL Steering Committee checks it over and usually says 'ok that makes sense, make it so.' The maintainer then emails epel-announce and epel-devel and any other lists that it is going to happen. They then put the packages in epel-testing and see how much it breaks things. If they get negative karma they don't push to stable.. if they don't they push after 3-6 weeks. However it is up to the maintainer to have the volunteer time to do this > Right now, nextcloud-V10 is in EPEL7 and is not upgraded. On nextcloud site, it is obsolete and the current version is nextcloud-V17.0.0 > https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule > > Nextcloud supports upgrading from one version to another, but now, upgrading from v10 to V17 is impossible. > > How will EPEL8 handle those kind of software? Will there be a specific repo for those kind of software that constantly evolve or will it be frozen for entire EPEL8 life? Or will it never be eligible for inclusion in EPEL8 due to its lifecycle? > For EPEL-8 it would be that the person would make a module for nextcloud, and give it a 12 month lifetime in pdc. Then they would update to the next version as time went on. Or they could just put the package in playground-epel8 and update the sets whenever they wanted. > Regards, > > Olivier. > > Le 09/10/2019 23:05, « Kevin Fenzi » <kevin@xxxxxxxxx> a écrit : > > On Mon, Oct 07, 2019 at 01:16:47PM -0500, Merlin Mathesius wrote: > > I was asked to draft a plan stating what EPEL 8 should do regarding > > Software Collections. The draft I came up with is included below. > > Looks good to me. +1 here. > > > EPEL Steering Committee: Please ratify this plan or provide feedback as > > necessary. When it's ready, and I will prepare a PR for this to land in > > https://pagure.io/epel/blob/master/f/docs/source > > That would be great... > > kevin > -- > > > > Regards, > > > > Merlin > > > > ------------------------------ > > > > > > *Regarding EPEL and Software Collections* > > *Background* > > > > For RHEL 8, Red Hat made the decision to provide multiple versions of > > software in the form of App Stream modules instead of Red Hat Software > > Collections (RHSCLs). > > > > SCLs are maintained by the CentOS Software Collections SIG, not the EPEL > > SIG. > > > > RHEL 8 comes with the scl-utils and scl-utils-build packages--which contain > > tools for using and building SCLs. These packages appear to function as > > expected with RHEL 8 and CentOS 8. > > > > *Recommendations* > > > > EPEL will not provide SCL support, although it will not prohibit use of the > > SCL tools provided with RHEL 8. > > > > EPEL will not provide any SCLs. > > > > EPEL encourages the community to follow Red Hat’s lead and provide multiple > > versions of software for RHEL 8 and CentOS 8 in the form of modules rather > > than SCLs. > > > > For use cases that require the parallel installation of multiple versions > > of the same component, EPEL recommends the same solution as RHEL 8: > > containers. > > > > ------------------------------ > > > _______________________________________________ > > epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
