Tagged with "meeting" so we can start work on Step 1 at next weeks meeting.

I expect that there will also need to be more communication on fedora-devel on this but I figured that would happen after a 'first reading' of the proposal at the meeting.

While wholeheartedly supporting this action, I do have a question: what will happen to the current modular packages? Will they be rebuilt as plain rpm packages? Or just dropped?

That would be up to the maintainers of the packages. Packages in EPEL are volunteered and if the maintainer only wanted to support a module they don't have to move them over to regular. On the other hand, if they decided to drop the module (as some have) it would also go away.

In the end, the modules that were there before the 'end' would be still available in the 'archive' repository that people could aim at as needed.

+1. I'm happy to get rid of any modules I own.

I used EPEL modules to deliver a more modern version of nginx (nginx mainline, specifically) to EL8.
I don't know how many people actually ever used this and I would be okay with dropping modules from EPEL.

I fully endorse getting rid of modularity in epel8 and not enabling it in epel9... Has led to some confusing workflows...

Vote from this week EPEL Steering Committe meeting: +8 For 0 Against.

Let's do this.

Implementation of step 3.

https://src.fedoraproject.org/rpms/epel-release/pull-request/25

We discussed this again at the EPEL Steering Committee meeting. Since the end goal is to EOL epel8-modular, not keep it around as an opt-in/opt-out, we agreed that just setting enabled=0 is a better intermediate step than moving the repo definitions to a subpackage. That has been implemented in https://src.fedoraproject.org/rpms/epel-release/pull-request/26.

The change has been merged and is on its way to the testing repos. The plan has also been announced on the epel-devel list.

I am really very sorry for my late comment but the proposal will negatively effect thousands of end users and they have not a chance to participate on the discussion. I also would like to point out that the proposal will not provide any value to end users. Is there any chance to reconsider the decision?

To be clear, I am fine with modifications for EPEL9, but I have a problem with the change for EPEL8. In Fedora such a change will be only allowed for unreleased Fedora version. Can we at least split the proposal for EPEL8 and EPEL9?

My hope is that the changes as planned would not break people worse than they are currently as the content would still be there but in a different tree. I had thought of keeping it in the current directory structure and 'frozen' but the Fedora Build System compose would have problems with that.

That said, there are several cases which have been brought up where it will cause problems and we need to deal with:

• satellite and similar systems download modules from a URL and not a metalink.
• there is no easy way to move from modular content to non modular via RPM commands.
• various Enterprise sites are going into 'holiday' lockdown from around Oct 15 -> Feb 15 to deal with many holidays.

We do need to discuss this on the epel-devel list and next weeks meeting to figure out how to help.

I also would like to point out that the proposal will not provide any value to end users.

The value proposition is removing a repository of content that is routinely uninstallable and routinely violates policy by overlapping RHEL module streams.

Can we at least split the proposal for EPEL8 and EPEL9?

EPEL 9 Modular was already decided against in #135, separate from this initiative.

Should I interpret the results of this week's meeting to be officially Decided™ or is Oct 31 still officially the plan of record?

I'm very sorry for dropping the ball on this.
It has been officially decided.
October 31st we will push the new epel-release to stable, but we will NOT be disabling, or removing the epel8 modules until February 15th.

emails and articles are coming.

This is very disappointing news. I was hoping for the php-pecl-redis package to become available in epel8 so that the vendor provided PHP packages could be used and to take advantage of the long term support.

Attempts to fix this and work within how EPEL is normally built have been tried for several years by different people but have not worked.

Even if the modular build is not working properly, it is not enough reason to drop the functionality, unless it breaks the non-modular software building/distribution.
The main point of the stream functionality is that you can have multiple versions of the same software. That decision is bad for the long term future of EPEL since the main OS distribution will still be stream based.

Basically the only way that 'worked' for the last multiple years is being able to use 'default' modules. However many of those modules are actually out of 'support' from Red Hat so yes it breaks non-modular software building in some cases.

I realized that our February 15th date is coming up next week. I started looking at what changes might be needed to epel-release so we could have them available in the testing repo ready to go. This item was part of the original plan:

Drop https://src.fedoraproject.org/rpms/epel-release/blob/epel8/f/epel-testing-modular.repo from epel-repos-modular

I'm assuming this was meant to include epel-modular.repo as well. But I also noticed this item in the plan:

Archiving of the modules on XYZ date to /pub/archive/epel/8.YYYY-MM/Modular and pointing mirrormanager to that for that

We already have epel-modular and epel-testing-modular disabled by default with DEPRECATED in the repo name. Once MirrorManager is updated the repo definition will still work if enabled. Do we actually want to remove the repo definitions? I could see the argument that it would be considerate to people that still want that content for us make it easy to access with just an --enablerepo epel-modular flag. However I could also see the alternate argument, that we shouldn't make the content easy to get to since it's unmaintained.

We have always kept old content reachable for fedora/epel. (ie, if you install a fedora 7, or rhel5 with epel box, the repos would point you to archives and still work)

That said, I personally don't feel strongly about the modularity content here. I suspect few people have used it.

I would say we leave it but make it clear in the repository file that the data is end of lifed and no longer updated.

I say leave them. Possibly adding to the name so that it is "UNMAINTAINED" or "ARCHIVED". Although I'm not against just leaving them as "DEPRECATED"

I was planning on doing an email and another Fedora Magazine article. And we'll need to rebase, and merge Diago's fix of the main EPEL documentation.

We discussed this again at today's EPEL Steering Committee meeting.

• #action @carlwgeorge will change DEPRECATED to RETIRED in epel8-modular configs, but no build just for this
• #action @dherrera will create a releng ticket for archiving, removing tags and targets, and removing epel modules from mbs
• #action @tdawson will send out an email to epel-announce announcing the final retirement of epel8 modules.

All actions have been completed.
Modularity has been completely dropped from epel8