Howdy folks,
A large part of my day job is working on CentOS Stream. Naturally I would like it to be successful and have wide adoption. I know that EPEL will play a big role in this success. EPEL is extremely popular. Many users consider RHEL and CentOS unusable without it.
The problem we are facing is that EPEL 8 cannot be 100% compatible with RHEL/CentOS 8 and CentOS 8 Stream at the same time. It is not uncommon for RHEL to ship library soname changes in minor releases. In the RHEL 8 cycle, those changes are showing up in CentOS 8 Stream first. EPEL 8 builds against the latest RHEL 8 release. This can result in EPEL 8 packages that are uninstallable on CentOS 8 Stream due to the library differences. One prominent example we have already seen is llvm-libs, which has increased its library soname in every RHEL 8 minor release so far. Another increase is planned for RHEL 8.3, which has already been released in CentOS 8 Stream. There are likely other incompatibilities that haven't been noticed yet. I expect this problem to grow worse as RHEL development continues and more packages are added to EPEL 8. This situation is hurting the adoption of CentOS Stream.
To solve this problem, I am proposing that we create a new repository called EPEL 8 Next.
- built against CentOS 8 Stream - opt-in for packagers (must request epel8-next dist-git branch) - opt-in for users (part of epel-release but disabled by default) - used *with* epel8, not *instead of*
This will provide EPEL packagers a place where they can update their packages when necessary to be compatible with CentOS 8 Stream. These packages would also be useful for RHEL 8 users during the gap between a RHEL minor release and the equivalent CentOS 8 Linux rebuild. In theory this repository should also be directly consumable by RHEL 8 Beta releases. Similar to RHEL itself, breaking changes could be permitted in epel8-next in preparation for delivering them to epel8 around the time of the next RHEL minor release.
This proposal may sound similar to epel8-playground. However, that was still built against RHEL 8, so it didn't solve the compatibility issue with CentOS 8 Stream. This proposal does draw on lessons learned from the playground experiment.
- no automatic builds via packages.cfg - opt-in rather than opt-out - layering on top of epel8, rather than duplicating content
I first suggested this idea at the last EPEL Steering Committee meeting, and we plan to discuss it again during the next one. Please share your thoughts on this proposal.
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
To solve this problem, I am proposing that we create a new repository called EPEL 8 Next.
- built against CentOS 8 Stream
- opt-in for packagers (must request epel8-next dist-git branch)
- opt-in for users (part of epel-release but disabled by default)
- used *with* epel8, not *instead of*
I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it is to be use with Stream, why don't we call it EPEL 8 Stream? I think the meaning of the repository would be easier to understand.
-- Petr
On Wed, Sep 9, 2020 at 5:51 AM Petr Pisar ppisar@redhat.com wrote:
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
To solve this problem, I am proposing that we create a new repository called EPEL 8 Next.
- built against CentOS 8 Stream
- opt-in for packagers (must request epel8-next dist-git branch)
- opt-in for users (part of epel-release but disabled by default)
I do not like it being part of epel-release, because it is (possibly) not compatible with a regular RHEL/CentOS release. I don't mind it being a sub-package of epel-release, something like epel-stream-repo, but not what they get when they do the basic epel-release install. Users have to go through extra steps to get and use CentOS Stream, they can do an extra step to get the EPEL next repo.
- used *with* epel8, not *instead of*
I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it is to be use with Stream, why don't we call it EPEL 8 Stream? I think the meaning of the repository would be easier to understand.
Very good question, one I asked in the meeting. If I got the argument right, then the amount of red-tape / legal work it would take to call it epel-stream would be much higher than we want to pay. Many of us didn't like the name "Stream" to begin with since it is sooo overloaded.
But that also is part of the reason I don't want the repo installed by default. If your average EPEL user were to see that there was now a repo called epel-next, they would think it is what we currently call playground. Where the maintainers put their next versions of things. Those users (and I'm sure there are many) who want to test, or use the next version of ... whatever it is ... let's say nedit, would enable epel-next, and then be disappointed that anything in there won't install on their system.
I believe there is one other thing that was mentioned during the meeting, and that is the lifetime. If I remember right, the lifetime of epel8-next would only be until N months after RHEL9 was released. (1 < N < 12)
Troy
From: Troy Dawson tdawson@redhat.com Sent: Wednesday, September 9, 2020 16:30 To: EPEL Development List Subject: [EPEL-devel] Re: proposal: EPEL 8 Next
On Wed, Sep 9, 2020 at 5:51 AM Petr Pisar ppisar@redhat.com wrote:
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it is to be use with Stream, why don't we call it EPEL 8 Stream? I think the meaning of the repository would be easier to understand.
Very good question, one I asked in the meeting. If I got the argument right, then the amount of red-tape / legal work
i> t would take to call it epel-stream would be much higher than we want
to pay. Many of us didn't like the name "Stream" to begin with since it is sooo overloaded.
EPEL Upstream?
Mika
On Wed, Sep 09, 2020 at 06:30:08AM -0700, Troy Dawson wrote:
Very good question, one I asked in the meeting. If I got the argument right, then the amount of red-tape / legal work it would take to call it epel-stream would be much higher than we want to pay. Many of us didn't like the name "Stream" to begin with since it is sooo overloaded.
I'm also ... eyerolly ... about the Stream name, but it's the one we've got, and I think it makes a LOT of sense for this to be aligned. It'll be so much easer for users to actually find and understand than anything else I can think of. So.... I'm willing to tackle the red tape and legal work if that's the blocker.
I do not like it being part of epel-release, because it is (possibly) not compatible with a regular RHEL/CentOS release.
My thinking there is that shipping it as a disabled repository in epel-release makes it easier to consume in that gap between a RHEL minor release and the corresponding CentOS Linux rebuild. Imagine the scenario where an issue with an uninstallable package during that gap is solved just by running `dnf --enablerepo epel-next update`. I'm not entirely opposed to doing it as a subpackage, but it does add an extra step in the scenario I'm describing. As far as users enabling it when they shouldn't, we'll never be able to completely idiot proof things. Personally I think disabled by default is a sufficient safety measure here, but I won't lose any sleep if the steering committee insists on it being an optional subpackage.
I believe there is one other thing that was mentioned during the meeting, and that is the lifetime. If I remember right, the lifetime of epel8-next would only be until N months after RHEL9 was released. (1 < N < 12)
That would align with CentOS Stream, but we could keep it around for RHEL Betas and the CentOS Linux rebuild gap. Library changes are less common after the next RHEL major version is released, but they still happen. For example, in RHEL 7 ImageMagick had a library soname bump in 7.8, over six years after the initial RHEL 7 release.
On Wed, Sep 9, 2020 at 8:31 AM Troy Dawson tdawson@redhat.com wrote:
On Wed, Sep 9, 2020 at 5:51 AM Petr Pisar ppisar@redhat.com wrote:
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
To solve this problem, I am proposing that we create a new repository called EPEL 8 Next.
- built against CentOS 8 Stream
- opt-in for packagers (must request epel8-next dist-git branch)
- opt-in for users (part of epel-release but disabled by default)
I do not like it being part of epel-release, because it is (possibly) not compatible with a regular RHEL/CentOS release. I don't mind it being a sub-package of epel-release, something like epel-stream-repo, but not what they get when they do the basic epel-release install. Users have to go through extra steps to get and use CentOS Stream, they can do an extra step to get the EPEL next repo.
- used *with* epel8, not *instead of*
I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it is to be use with Stream, why don't we call it EPEL 8 Stream? I think the meaning of the repository would be easier to understand.
Very good question, one I asked in the meeting. If I got the argument right, then the amount of red-tape / legal work it would take to call it epel-stream would be much higher than we want to pay. Many of us didn't like the name "Stream" to begin with since it is sooo overloaded.
But that also is part of the reason I don't want the repo installed by default. If your average EPEL user were to see that there was now a repo called epel-next, they would think it is what we currently call playground. Where the maintainers put their next versions of things. Those users (and I'm sure there are many) who want to test, or use the next version of ... whatever it is ... let's say nedit, would enable epel-next, and then be disappointed that anything in there won't install on their system.
I believe there is one other thing that was mentioned during the meeting, and that is the lifetime. If I remember right, the lifetime of epel8-next would only be until N months after RHEL9 was released. (1 < N < 12)
Troy _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
On Wed, Sep 9, 2020, 6:50 AM Petr Pisar ppisar@redhat.com wrote:
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
To solve this problem, I am proposing that we create a new repository
called
EPEL 8 Next.
- built against CentOS 8 Stream
- opt-in for packagers (must request epel8-next dist-git branch)
- opt-in for users (part of epel-release but disabled by default)
- used *with* epel8, not *instead of*
I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it is to be use with Stream, why don't we call it EPEL 8 Stream? I think the meaning of the repository would be easier to understand.
I was thinking the same thing. EPEL stream is so much easier for users to understand.
- Ken
On Wed, 9 Sep 2020 at 09:58, Ken Dreyer ktdreyer@ktdreyer.com wrote:
On Wed, Sep 9, 2020, 6:50 AM Petr Pisar ppisar@redhat.com wrote:
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
To solve this problem, I am proposing that we create a new repository
called
EPEL 8 Next.
- built against CentOS 8 Stream
- opt-in for packagers (must request epel8-next dist-git branch)
- opt-in for users (part of epel-release but disabled by default)
- used *with* epel8, not *instead of*
I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it is to be use with Stream, why don't we call it EPEL 8 Stream? I think the meaning of the repository would be easier to understand.
I was thinking the same thing. EPEL stream is so much easier for users to understand.
I can see two big reasons for not using Stream in the name as the starting point of a proposal: 1. There is always a complaint that Red Hat related projects jump onto a single name to the point of overuse. Atomic, -Shift, -Stack, and a couple others have been ones in just recent memory. Participants in the various communities feel usually railroaded to use a brand even if they don't think it wise. 2.EPEL has a hard enough time getting Fedora contributions with various community members seeing it as a useless diversion. Putting Stream in the title will just add to the 'why isn't EPEL just in CentOS already so I don't have to look at those ugly named branches in MY package'.
On Wed, Sep 09, 2020 at 10:25:50AM -0400, Stephen John Smoogen wrote:
- There is always a complaint that Red Hat related projects jump onto a
single name to the point of overuse. Atomic, -Shift, -Stack, and a couple others have been ones in just recent memory. Participants in the various communities feel usually railroaded to use a brand even if they don't think it wise.
Yesssss, that's a problem. In this case, though, it really *is* directly related.
2.EPEL has a hard enough time getting Fedora contributions with various community members seeing it as a useless diversion. Putting Stream in the title will just add to the 'why isn't EPEL just in CentOS already so I don't have to look at those ugly named branches in MY package'.
So, the distinction is: EPEL is in Fedora because it's direct community ownership and maintenance. CentOS Stream is explicitly Red Hat controlled with a "patches appreciated!" approach. It's valuable to have both, but I also like the clarity of the separation.
This all leads me to think that actually what we want is not "EPEL Stream" but "EPEL for Stream". (epel-for-stream? epel-4-stream? epel4s? no not that last one for sure.)
On Wed, 2020-09-09 at 12:27 -0400, Matthew Miller wrote:
This all leads me to think that actually what we want is not "EPEL Stream" but "EPEL for Stream". (epel-for-stream? epel-4-stream? epel4s? no not that last one for sure.)
From a mulit-language perspective, I prefer not to use '4' in place of the English word 'for'. It makes the translation work a bit wonky.
Pat
On Wednesday, September 9, 2020 5:56:43 PM WEST Patrick Riehecky wrote:
From a mulit-language perspective, I prefer not to use '4' in place of the English word 'for'. It makes the translation work a bit wonky.
Not only that, do not forget the meaning/association of 4 in different cultures. :-)
At the EPEL Steering Committee last week, we had an extensive discussion of this proposal, specifically focused on how to handle the dist macro. I believe these are the possible choices.
* keep dist the same as epel8 (.el8)
RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for dist. It would make sense to continue using the same dist for EPEL Next. However, this would put a little more work on packagers. They would not be able to build the same commit for both EPEL and EPEL Next because the NVR will conflict in Koji. In simple rebuild situations, this is not a problem because at a minimum the release will be higher. But if a packager wanted to update the package in both EPEL and EPEL Next, they will need to first update and build it in EPEL, then bump the release and build it in EPEL Next. This isn't ideal, but isn't terrible either, and can be partially mitigated by good documentation around EPEL Next workflows.
* modify dist to always be higher than epel8 (.el8.next or similar)
In EPEL Next we could define dist to a string that RPM evaluates higher than .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be in sync and the same commit could be built for both targets. The higher dist would ensure the upgrade path works.
* modify dist to reflect future rhel version (.el8_3)
This is similar to the previous choice as far as the upgrade path. It would make things a bit more obvious during the CentOS Linux rebuild gap. For example, a user who upgrades from RHEL 8.2 to 8.3 could grab a .el8_3 build from EPEL Next if the EPEL package hasn't been rebuilt yet. However, the dist could be misleading. Building against CentOS Stream at a given point in time doesn't necessarily give you all the libraries that will be in the next final RHEL minor release. There will be situations early in the cycle where some libraries have changed and others that will haven't yet. Additionally, there will be a short period of time late in the cycle where CentOS Stream will have release+2 content prior to release+1 reaching RHEL GA. Leaving the minor release out of the dist leaves us more wiggle room on user expectations.
We need to make a decision on dist before moving further. Here are some other thoughts from the meeting:
- epel-next-release as a subpackage of epel-release - automatic nightly compose or bodhi enablement? - start enumerating the steps necessary to move forward (WIP)
On Wed, Sep 9, 2020 at 2:55 PM José Abílio Matos jamatos@fc.up.pt wrote:
On Wednesday, September 9, 2020 5:56:43 PM WEST Patrick Riehecky wrote:
From a mulit-language perspective, I prefer not to use '4' in place of
the English word 'for'. It makes the translation work a bit wonky.
Not only that, do not forget the meaning/association of 4 in different cultures. :-)
--
José Abílio
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote:
At the EPEL Steering Committee last week, we had an extensive discussion of this proposal, specifically focused on how to handle the dist macro. I believe these are the possible choices.
- keep dist the same as epel8 (.el8)
RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for dist. It would make sense to continue using the same dist for EPEL Next. However, this would put a little more work on packagers. They would not be able to build the same commit for both EPEL and EPEL Next because the NVR will conflict in Koji. In simple rebuild situations, this is not a problem because at a minimum the release will be higher. But if a packager wanted to update the package in both EPEL and EPEL Next, they will need to first update and build it in EPEL, then bump the release and build it in EPEL Next. This isn't ideal, but isn't terrible either, and can be partially mitigated by good documentation around EPEL Next workflows.
- modify dist to always be higher than epel8 (.el8.next or similar)
In EPEL Next we could define dist to a string that RPM evaluates higher than .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be in sync and the same commit could be built for both targets. The higher dist would ensure the upgrade path works.
I think this makes the most sense and will help packages workflows the best.
kevin
I agree, using .el8.next for the dist macro makes the most sense. This will enable maintainers to use a similar workflow to Fedora branches, where older branches can be fast forwarded, and the same commit can be built for different targets but still have different NVRs in Koji. Here is an example workflow for a fictional foo package that already exists in Fedora.
- request epel8 branch - merge master branch to epel8 branch - build epel8 branch, resulting in foo-1-1.el8 - realize it won't install on CentOS Stream due to a library difference - request epel8-next branch - merge epel8 branch to epel8-next branch - build epel8-next branch, resulting in foo-1-1.el8.next
After the next RHEL 8 minor release (when that library difference affects everyone), the maintainer can increment the release on the epel8 branch and proceed as usual.
On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi kevin@scrye.com wrote:
On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote:
At the EPEL Steering Committee last week, we had an extensive discussion of this proposal, specifically focused on how to handle the dist macro. I believe these are the possible choices.
- keep dist the same as epel8 (.el8)
RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for dist. It would make sense to continue using the same dist for EPEL Next. However, this would put a little more work on packagers. They would not be able to build the same commit for both EPEL and EPEL Next because the NVR will conflict in Koji. In simple rebuild situations, this is not a problem because at a minimum the release will be higher. But if a packager wanted to update the package in both EPEL and EPEL Next, they will need to first update and build it in EPEL, then bump the release and build it in EPEL Next. This isn't ideal, but isn't terrible either, and can be partially mitigated by good documentation around EPEL Next workflows.
- modify dist to always be higher than epel8 (.el8.next or similar)
In EPEL Next we could define dist to a string that RPM evaluates higher than .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be in sync and the same commit could be built for both targets. The higher dist would ensure the upgrade path works.
I think this makes the most sense and will help packages workflows the best.
kevin _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
Here is my rough outline of the steps required to implement this proposal. I imagine things would happen roughly in this order, but some things could probably take place in parallel.
1. EPEL Steering Committee approves the proposal 2. koji changes: - create CentOS Stream 8 external repo - create epel8-next build target (inheriting from epel8) - dist macro override for that target 3. create PDC entries 4. update fedscm-admin with branch SLAs 5. configure dist-git to allow branch name 6. update pungi config 7. add epel-next-repo subpackage to epel-release 8. add epel8-next release in bodhi 9. document in the wiki 10. announcement email
Please let me know if I'm missing anything.
On Wed, Sep 23, 2020 at 8:43 PM Carl George carl@redhat.com wrote:
I agree, using .el8.next for the dist macro makes the most sense. This will enable maintainers to use a similar workflow to Fedora branches, where older branches can be fast forwarded, and the same commit can be built for different targets but still have different NVRs in Koji. Here is an example workflow for a fictional foo package that already exists in Fedora.
- request epel8 branch
- merge master branch to epel8 branch
- build epel8 branch, resulting in foo-1-1.el8
- realize it won't install on CentOS Stream due to a library difference
- request epel8-next branch
- merge epel8 branch to epel8-next branch
- build epel8-next branch, resulting in foo-1-1.el8.next
After the next RHEL 8 minor release (when that library difference affects everyone), the maintainer can increment the release on the epel8 branch and proceed as usual.
On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi kevin@scrye.com wrote:
On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote:
At the EPEL Steering Committee last week, we had an extensive discussion of this proposal, specifically focused on how to handle the dist macro. I believe these are the possible choices.
- keep dist the same as epel8 (.el8)
RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for dist. It would make sense to continue using the same dist for EPEL Next. However, this would put a little more work on packagers. They would not be able to build the same commit for both EPEL and EPEL Next because the NVR will conflict in Koji. In simple rebuild situations, this is not a problem because at a minimum the release will be higher. But if a packager wanted to update the package in both EPEL and EPEL Next, they will need to first update and build it in EPEL, then bump the release and build it in EPEL Next. This isn't ideal, but isn't terrible either, and can be partially mitigated by good documentation around EPEL Next workflows.
- modify dist to always be higher than epel8 (.el8.next or similar)
In EPEL Next we could define dist to a string that RPM evaluates higher than .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be in sync and the same commit could be built for both targets. The higher dist would ensure the upgrade path works.
I think this makes the most sense and will help packages workflows the best.
kevin _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
-- Carl George
On Thu, Oct 1, 2020 at 9:13 PM Carl George carl@redhat.com wrote:
Here is my rough outline of the steps required to implement this proposal. I imagine things would happen roughly in this order, but some things could probably take place in parallel.
- EPEL Steering Committee approves the proposal
- koji changes:
- create CentOS Stream 8 external repo
- create epel8-next build target (inheriting from epel8)
- dist macro override for that target
- create PDC entries
- update fedscm-admin with branch SLAs
- configure dist-git to allow branch name
- update pungi config
- add epel-next-repo subpackage to epel-release
- add epel8-next release in bodhi
- document in the wiki
- announcement email
Please let me know if I'm missing anything.
You had everything I thought of, and more. Looks good to me.
On Wed, Sep 23, 2020 at 8:43 PM Carl George carl@redhat.com wrote:
I agree, using .el8.next for the dist macro makes the most sense. This will enable maintainers to use a similar workflow to Fedora branches, where older branches can be fast forwarded, and the same commit can be built for different targets but still have different NVRs in Koji. Here is an example workflow for a fictional foo package that already exists in Fedora.
- request epel8 branch
- merge master branch to epel8 branch
- build epel8 branch, resulting in foo-1-1.el8
- realize it won't install on CentOS Stream due to a library difference
- request epel8-next branch
- merge epel8 branch to epel8-next branch
- build epel8-next branch, resulting in foo-1-1.el8.next
After the next RHEL 8 minor release (when that library difference affects everyone), the maintainer can increment the release on the epel8 branch and proceed as usual.
On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi kevin@scrye.com wrote:
On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote:
At the EPEL Steering Committee last week, we had an extensive discussion of this proposal, specifically focused on how to handle the dist macro. I believe these are the possible choices.
- keep dist the same as epel8 (.el8)
RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for dist. It would make sense to continue using the same dist for EPEL Next. However, this would put a little more work on packagers. They would not be able to build the same commit for both EPEL and EPEL Next because the NVR will conflict in Koji. In simple rebuild situations, this is not a problem because at a minimum the release will be higher. But if a packager wanted to update the package in both EPEL and EPEL Next, they will need to first update and build it in EPEL, then bump the release and build it in EPEL Next. This isn't ideal, but isn't terrible either, and can be partially mitigated by good documentation around EPEL Next workflows.
- modify dist to always be higher than epel8 (.el8.next or similar)
In EPEL Next we could define dist to a string that RPM evaluates higher than .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be in sync and the same commit could be built for both targets. The higher dist would ensure the upgrade path works.
I think this makes the most sense and will help packages workflows the best.
kevin _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
-- Carl George
-- Carl George _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
On Thu, Oct 01, 2020 at 11:12:28PM -0500, Carl George wrote:
Here is my rough outline of the steps required to implement this proposal. I imagine things would happen roughly in this order, but some things could probably take place in parallel.
- EPEL Steering Committee approves the proposal
- koji changes:
- create CentOS Stream 8 external repo
- create epel8-next build target (inheriting from epel8)
- dist macro override for that target
- create PDC entries
- update fedscm-admin with branch SLAs
- configure dist-git to allow branch name
- update pungi config
- add epel-next-repo subpackage to epel-release
- add epel8-next release in bodhi
- document in the wiki
- announcement email
Please let me know if I'm missing anything.
Looks pretty good to me, but two things:
1. I assume (but good to ask) that we are not going to change anything in bugzilla? ie, bug reports should just go against the epel component? Of course now that playground is 'seperate' and next will also be, would we ever have cases where we have a component without epel branch, but with playground and/or next? And what would we do for bugs there?
2. We are heading into final freeze for Fedora 33 next tuesday, so not sure how much will get done until f33 is out the door. Is it ok to do this after? Some of it could be done with freeze breaks and such, but might be easier just to do it all at once after f33 freeze is over?
Thanks much for putting this together!
kevin --
On Wed, Sep 23, 2020 at 8:43 PM Carl George carl@redhat.com wrote:
I agree, using .el8.next for the dist macro makes the most sense. This will enable maintainers to use a similar workflow to Fedora branches, where older branches can be fast forwarded, and the same commit can be built for different targets but still have different NVRs in Koji. Here is an example workflow for a fictional foo package that already exists in Fedora.
- request epel8 branch
- merge master branch to epel8 branch
- build epel8 branch, resulting in foo-1-1.el8
- realize it won't install on CentOS Stream due to a library difference
- request epel8-next branch
- merge epel8 branch to epel8-next branch
- build epel8-next branch, resulting in foo-1-1.el8.next
After the next RHEL 8 minor release (when that library difference affects everyone), the maintainer can increment the release on the epel8 branch and proceed as usual.
On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi kevin@scrye.com wrote:
On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote:
At the EPEL Steering Committee last week, we had an extensive discussion of this proposal, specifically focused on how to handle the dist macro. I believe these are the possible choices.
- keep dist the same as epel8 (.el8)
RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for dist. It would make sense to continue using the same dist for EPEL Next. However, this would put a little more work on packagers. They would not be able to build the same commit for both EPEL and EPEL Next because the NVR will conflict in Koji. In simple rebuild situations, this is not a problem because at a minimum the release will be higher. But if a packager wanted to update the package in both EPEL and EPEL Next, they will need to first update and build it in EPEL, then bump the release and build it in EPEL Next. This isn't ideal, but isn't terrible either, and can be partially mitigated by good documentation around EPEL Next workflows.
- modify dist to always be higher than epel8 (.el8.next or similar)
In EPEL Next we could define dist to a string that RPM evaluates higher than .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be in sync and the same commit could be built for both targets. The higher dist would ensure the upgrade path works.
I think this makes the most sense and will help packages workflows the best.
kevin _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
-- Carl George
-- Carl George _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
Thanks for looking over the plan Kevin.
1. I wasn't planning any changes for bugzilla. I think it's appropriate for the bug reports to be filed against the epel8 component. Typically there should be an epel8 branch already when an epel8-next branch is requested. The only exception I can imagine is if a package has a dependency on a package that is in CentOS Stream but isn't in a RHEL GA release yet. Even then, it would only be a temporary situation, because within six months that package would make it into RHEL and then the package should be built in epel8, not epel8-next. Do you think it would be worthwhile for fedscm-admin to enforce a requirement of an epel8 branch before allowing the creation of an epel8-next branch?
2. I'm perfectly fine waiting until after F33 is done. That makes lots of sense.
On Sat, Oct 3, 2020 at 12:07 PM Kevin Fenzi kevin@scrye.com wrote:
On Thu, Oct 01, 2020 at 11:12:28PM -0500, Carl George wrote:
Here is my rough outline of the steps required to implement this proposal. I imagine things would happen roughly in this order, but some things could probably take place in parallel.
- EPEL Steering Committee approves the proposal
- koji changes:
- create CentOS Stream 8 external repo
- create epel8-next build target (inheriting from epel8)
- dist macro override for that target
- create PDC entries
- update fedscm-admin with branch SLAs
- configure dist-git to allow branch name
- update pungi config
- add epel-next-repo subpackage to epel-release
- add epel8-next release in bodhi
- document in the wiki
- announcement email
Please let me know if I'm missing anything.
Looks pretty good to me, but two things:
- I assume (but good to ask) that we are not going to change anything
in bugzilla? ie, bug reports should just go against the epel component? Of course now that playground is 'seperate' and next will also be, would we ever have cases where we have a component without epel branch, but with playground and/or next? And what would we do for bugs there?
- We are heading into final freeze for Fedora 33 next tuesday, so not
sure how much will get done until f33 is out the door. Is it ok to do this after? Some of it could be done with freeze breaks and such, but might be easier just to do it all at once after f33 freeze is over?
Thanks much for putting this together!
kevin
On Wed, Sep 23, 2020 at 8:43 PM Carl George carl@redhat.com wrote:
I agree, using .el8.next for the dist macro makes the most sense. This will enable maintainers to use a similar workflow to Fedora branches, where older branches can be fast forwarded, and the same commit can be built for different targets but still have different NVRs in Koji. Here is an example workflow for a fictional foo package that already exists in Fedora.
- request epel8 branch
- merge master branch to epel8 branch
- build epel8 branch, resulting in foo-1-1.el8
- realize it won't install on CentOS Stream due to a library difference
- request epel8-next branch
- merge epel8 branch to epel8-next branch
- build epel8-next branch, resulting in foo-1-1.el8.next
After the next RHEL 8 minor release (when that library difference affects everyone), the maintainer can increment the release on the epel8 branch and proceed as usual.
On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi kevin@scrye.com wrote:
On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote:
At the EPEL Steering Committee last week, we had an extensive discussion of this proposal, specifically focused on how to handle the dist macro. I believe these are the possible choices.
- keep dist the same as epel8 (.el8)
RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for dist. It would make sense to continue using the same dist for EPEL Next. However, this would put a little more work on packagers. They would not be able to build the same commit for both EPEL and EPEL Next because the NVR will conflict in Koji. In simple rebuild situations, this is not a problem because at a minimum the release will be higher. But if a packager wanted to update the package in both EPEL and EPEL Next, they will need to first update and build it in EPEL, then bump the release and build it in EPEL Next. This isn't ideal, but isn't terrible either, and can be partially mitigated by good documentation around EPEL Next workflows.
- modify dist to always be higher than epel8 (.el8.next or similar)
In EPEL Next we could define dist to a string that RPM evaluates higher than .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be in sync and the same commit could be built for both targets. The higher dist would ensure the upgrade path works.
I think this makes the most sense and will help packages workflows the best.
kevin _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
-- Carl George
-- Carl George _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
On Mon, Oct 05, 2020 at 11:08:27AM -0500, Carl George wrote:
Thanks for looking over the plan Kevin.
- I wasn't planning any changes for bugzilla. I think it's appropriate for
the bug reports to be filed against the epel8 component. Typically there should be an epel8 branch already when an epel8-next branch is requested. The only exception I can imagine is if a package has a dependency on a package that is in CentOS Stream but isn't in a RHEL GA release yet. Even then, it would only be a temporary situation, because within six months that package would make it into RHEL and then the package should be built in epel8, not epel8-next. Do you think it would be worthwhile for fedscm-admin to enforce a requirement of an epel8 branch before allowing the creation of an epel8-next branch?
I think if it's easy/possible to make it reject epel8-next and epel8-playground branches when a package doesn't have a epel8 branch that would be nice. I am not sure this is required however, as you note it should be a pretty rare case...
- I'm perfectly fine waiting until after F33 is done. That makes lots of
sense.
Cool. Thanks
kevin --
On Sat, Oct 3, 2020 at 12:07 PM Kevin Fenzi kevin@scrye.com wrote:
On Thu, Oct 01, 2020 at 11:12:28PM -0500, Carl George wrote:
Here is my rough outline of the steps required to implement this proposal. I imagine things would happen roughly in this order, but some things could probably take place in parallel.
- EPEL Steering Committee approves the proposal
- koji changes:
- create CentOS Stream 8 external repo
- create epel8-next build target (inheriting from epel8)
- dist macro override for that target
- create PDC entries
- update fedscm-admin with branch SLAs
- configure dist-git to allow branch name
- update pungi config
- add epel-next-repo subpackage to epel-release
- add epel8-next release in bodhi
- document in the wiki
- announcement email
Please let me know if I'm missing anything.
Looks pretty good to me, but two things:
- I assume (but good to ask) that we are not going to change anything
in bugzilla? ie, bug reports should just go against the epel component? Of course now that playground is 'seperate' and next will also be, would we ever have cases where we have a component without epel branch, but with playground and/or next? And what would we do for bugs there?
- We are heading into final freeze for Fedora 33 next tuesday, so not
sure how much will get done until f33 is out the door. Is it ok to do this after? Some of it could be done with freeze breaks and such, but might be easier just to do it all at once after f33 freeze is over?
Thanks much for putting this together!
kevin
On Wed, Sep 23, 2020 at 8:43 PM Carl George carl@redhat.com wrote:
I agree, using .el8.next for the dist macro makes the most sense. This will enable maintainers to use a similar workflow to Fedora branches, where older branches can be fast forwarded, and the same commit can be built for different targets but still have different NVRs in Koji. Here is an example workflow for a fictional foo package that already exists in Fedora.
- request epel8 branch
- merge master branch to epel8 branch
- build epel8 branch, resulting in foo-1-1.el8
- realize it won't install on CentOS Stream due to a library difference
- request epel8-next branch
- merge epel8 branch to epel8-next branch
- build epel8-next branch, resulting in foo-1-1.el8.next
After the next RHEL 8 minor release (when that library difference affects everyone), the maintainer can increment the release on the epel8 branch and proceed as usual.
On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi kevin@scrye.com wrote:
On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote:
At the EPEL Steering Committee last week, we had an extensive discussion of this proposal, specifically focused on how to handle the dist macro. I believe these are the possible choices.
- keep dist the same as epel8 (.el8)
RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for dist. It would make sense to continue using the same dist for EPEL Next. However, this would put a little more work on packagers. They would not be able to build the same commit for both EPEL and EPEL Next because the NVR will conflict in Koji. In simple rebuild situations, this is not a problem because at a minimum the release will be higher. But if a packager wanted to update the package in both EPEL and EPEL Next, they will need to first update and build it in EPEL, then bump the release and build it in EPEL Next. This isn't ideal, but isn't terrible either, and can be partially mitigated by good documentation around EPEL Next workflows.
- modify dist to always be higher than epel8 (.el8.next or similar)
In EPEL Next we could define dist to a string that RPM evaluates higher than .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be in sync and the same commit could be built for both targets. The higher dist would ensure the upgrade path works.
I think this makes the most sense and will help packages workflows the best.
kevin _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
-- Carl George
-- Carl George _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
-- Carl George _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
Matthew Miller wrote:
This all leads me to think that actually what we want is not "EPEL Stream" but "EPEL for Stream".
That seems to be true.
(epel-for-stream? epel-4-stream? epel4s? no not that last one for sure.)
Please, no "4"! It looks like a version number.
Björn Persson
On Wed, Sep 9, 2020 at 10:34 AM Stephen John Smoogen smooge@gmail.com wrote:
I can see two big reasons for not using Stream in the name as the starting point of a proposal:
- There is always a complaint that Red Hat related projects jump onto a single name to the point of overuse. Atomic, -Shift, -Stack, and a couple others have been ones in just recent memory. Participants in the various communities feel usually railroaded to use a brand even if they don't think it wise.
I don't think that's as much of an issue here since this would be specifically targeting CentOS Stream. It's not really a name so much as a version in string form.
2.EPEL has a hard enough time getting Fedora contributions with various community members seeing it as a useless diversion. Putting Stream in the title will just add to the 'why isn't EPEL just in CentOS already so I don't have to look at those ugly named branches in MY package'.
Warning: heresy and rampant speculation ahead! It's too early to do this now, but I think there's a compelling case to be made for shifting EPEL from Fedora to Stream at some point. This would be dependent on getting a solid contributor community established for Stream, of course. Realistically, I'd say we're a few years away from making that transition, but I think the Stream community would be a more natural fit. If CentOS Stream had existed when EPEL started, I don't think we'd have made EPEL a part of Fedora, despite the good points Matthew makes below. (In other words, it's not a foregone conclusion that EPEL should be a part of Stream, and there are reasons not to do that, but there are also reasons to do that. That's a problem for Future Us to solve.)
On Wed, Sep 9, 2020 at 12:28 PM Matthew Miller mattdm@fedoraproject.org wrote:
So, the distinction is: EPEL is in Fedora because it's direct community ownership and maintenance. CentOS Stream is explicitly Red Hat controlled with a "patches appreciated!" approach. It's valuable to have both, but I also like the clarity of the separation.
See comments above (just leaving this quote in for reference)
This all leads me to think that actually what we want is not "EPEL Stream" but "EPEL for Stream". (epel-for-stream? epel-4-stream? epel4s? no not that last one for sure.)
2EPEL2Streamious. In seriousness, EPEL 8 is Extra Packages for Enterprise Linux 8, right? So we can go one of two ways: 1. Loosen the definition of what "Enterprise Linux" means (after all, it's not EPRHEL...) and go with something like "EPEL 8 Stream" or "EPEL Stream 8" (I'm inclined toward the latter) 2. Keep the pattern and call it "EPCS 8" for "Extra Packages for CentOS Stream 8". That has the benefit of being more clear what we're targeting at the cost of potential changes in tooling and adding YAA (yet another acronym) to the mix. (I say "acronym" here because it would clearly be pronounced as "epics", not the initialism "Eee pee cee ess")
On Wed, Sep 09, 2020 at 12:36:44PM -0400, Ben Cotton wrote: ...snip...
Warning: heresy and rampant speculation ahead! It's too early to do this now, but I think there's a compelling case to be made for shifting EPEL from Fedora to Stream at some point. This would be dependent on getting a solid contributor community established for Stream, of course. Realistically, I'd say we're a few years away from making that transition, but I think the Stream community would be a more natural fit. If CentOS Stream had existed when EPEL started, I don't think we'd have made EPEL a part of Fedora, despite the good points Matthew makes below. (In other words, it's not a foregone conclusion that EPEL should be a part of Stream, and there are reasons not to do that, but there are also reasons to do that. That's a problem for Future Us to solve.)
I'm a bit confused here... you seem to be conflating epel and this epel-stream/epel-next. Do you mean both of them? or just the new one would move over? We would need at least shared git (is that still something that might happen someday?)
kevin
On Wed, Sep 9, 2020 at 12:59 PM Kevin Fenzi kevin@scrye.com wrote:
I'm a bit confused here... you seem to be conflating epel and this epel-stream/epel-next. Do you mean both of them?
Yeah, I'm thinking both. From a high level, I don't see them as being distinct, just different targets for the same idea. Of course, that doesn't mean there aren't lower-level issues that would make it hard or impossible. It's also possible that I'm just totally wrong; I've been a little under quota on that lately, so I'm due. :-)
would move over? We would need at least shared git (is that still something that might happen someday?)
"In the fullness of time", as they say, that's something that might happen. Is that before the heat death of the universe? I can't say.
I won't continue distracting the thread with this idea for now, I just tossed it out as an idle thought. But the naming suggestions are sincere.
Holy name bikeshedding Batman! To adddress all the naming comments collectively, I am also of the opinion that "stream" is an overloaded term. Can you tell someone with a straight face to install a package from a module stream from the AppStream repo on CentOS Stream? Not to be confused with the appstream-data package that is also in the AppStream repo but isn't part of a module stream. I wouldn't be surprised by any entity currently using "stream" in their name moving away from it in the future for clarity. "Next" correctly describes the purpose of the repository, which is providing packages compatible with the next minor release of RHEL. That works for CentOS Stream, RHEL Betas, and RHEL during the CentOS Linux rebuild gap.
On Wed, Sep 9, 2020 at 12:17 PM Ben Cotton bcotton@redhat.com wrote:
On Wed, Sep 9, 2020 at 12:59 PM Kevin Fenzi kevin@scrye.com wrote:
I'm a bit confused here... you seem to be conflating epel and this epel-stream/epel-next. Do you mean both of them?
Yeah, I'm thinking both. From a high level, I don't see them as being distinct, just different targets for the same idea. Of course, that doesn't mean there aren't lower-level issues that would make it hard or impossible. It's also possible that I'm just totally wrong; I've been a little under quota on that lately, so I'm due. :-)
would move over? We would need at least shared git (is that still something that might happen someday?)
"In the fullness of time", as they say, that's something that might happen. Is that before the heat death of the universe? I can't say.
I won't continue distracting the thread with this idea for now, I just tossed it out as an idle thought. But the naming suggestions are sincere.
-- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
It's too early to do this now, but I think there's a compelling case to be made for shifting EPEL from Fedora to Stream at some point.
One of the biggest benefits to EPEL being in Fedora is the ability to do fast forward merges from Fedora branches to EPEL branches. Unless CentOS Stream and Fedora are on the same dist-git, we would lose that ability, which I am 100% opposed to.
2EPEL2Streamious
This is the only alternative name I'm willing to accept. /s
On Wed, Sep 9, 2020 at 11:37 AM Ben Cotton bcotton@redhat.com wrote:
On Wed, Sep 9, 2020 at 10:34 AM Stephen John Smoogen smooge@gmail.com wrote:
I can see two big reasons for not using Stream in the name as the starting point of a proposal:
- There is always a complaint that Red Hat related projects jump onto a single name to the point of overuse. Atomic, -Shift, -Stack, and a couple others have been ones in just recent memory. Participants in the various communities feel usually railroaded to use a brand even if they don't think it wise.
I don't think that's as much of an issue here since this would be specifically targeting CentOS Stream. It's not really a name so much as a version in string form.
2.EPEL has a hard enough time getting Fedora contributions with various community members seeing it as a useless diversion. Putting Stream in the title will just add to the 'why isn't EPEL just in CentOS already so I don't have to look at those ugly named branches in MY package'.
Warning: heresy and rampant speculation ahead! It's too early to do this now, but I think there's a compelling case to be made for shifting EPEL from Fedora to Stream at some point. This would be dependent on getting a solid contributor community established for Stream, of course. Realistically, I'd say we're a few years away from making that transition, but I think the Stream community would be a more natural fit. If CentOS Stream had existed when EPEL started, I don't think we'd have made EPEL a part of Fedora, despite the good points Matthew makes below. (In other words, it's not a foregone conclusion that EPEL should be a part of Stream, and there are reasons not to do that, but there are also reasons to do that. That's a problem for Future Us to solve.)
On Wed, Sep 9, 2020 at 12:28 PM Matthew Miller mattdm@fedoraproject.org wrote:
So, the distinction is: EPEL is in Fedora because it's direct community ownership and maintenance. CentOS Stream is explicitly Red Hat controlled with a "patches appreciated!" approach. It's valuable to have both, but I also like the clarity of the separation.
See comments above (just leaving this quote in for reference)
This all leads me to think that actually what we want is not "EPEL Stream" but "EPEL for Stream". (epel-for-stream? epel-4-stream? epel4s? no not that last one for sure.)
2EPEL2Streamious. In seriousness, EPEL 8 is Extra Packages for Enterprise Linux 8, right? So we can go one of two ways:
- Loosen the definition of what "Enterprise Linux" means (after all,
it's not EPRHEL...) and go with something like "EPEL 8 Stream" or "EPEL Stream 8" (I'm inclined toward the latter) 2. Keep the pattern and call it "EPCS 8" for "Extra Packages for CentOS Stream 8". That has the benefit of being more clear what we're targeting at the cost of potential changes in tooling and adding YAA (yet another acronym) to the mix. (I say "acronym" here because it would clearly be pronounced as "epics", not the initialism "Eee pee cee ess")
-- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
On Wed, Sep 9, 2020 at 2:50 PM Petr Pisar ppisar@redhat.com wrote:
I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it is to be use with Stream, why don't we call it EPEL 8 Stream? I think the meaning of the repository would be easier to understand.
Agreed. Using the "Stream" suffix is much easier to understand. In fact, it is obvious.
and, keep in mind: The first thing, we want to differ would be epel-release.
Jochen
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
Howdy folks,
A large part of my day job is working on CentOS Stream. Naturally I would like it to be successful and have wide adoption. I know that EPEL will play a big role in this success. EPEL is extremely popular. Many users consider RHEL and CentOS unusable without it.
The problem we are facing is that EPEL 8 cannot be 100% compatible with RHEL/CentOS 8 and CentOS 8 Stream at the same time. It is not uncommon for RHEL to ship library soname changes in minor releases. In the RHEL 8 cycle, those changes are showing up in CentOS 8 Stream first. EPEL 8 builds against the latest RHEL 8 release. This can result in EPEL 8 packages that are uninstallable on CentOS 8 Stream due to the library differences. One prominent example we have already seen is llvm-libs, which has increased its library soname in every RHEL 8 minor release so far. Another increase is planned for RHEL 8.3, which has already been released in CentOS 8 Stream. There are likely other incompatibilities that haven't been noticed yet. I expect this problem to grow worse as RHEL development continues and more packages are added to EPEL 8. This situation is hurting the adoption of CentOS Stream.
To solve this problem, I am proposing that we create a new repository called EPEL 8 Next.
- built against CentOS 8 Stream
- opt-in for packagers (must request epel8-next dist-git branch)
- opt-in for users (part of epel-release but disabled by default)
I like tdawsons idea down thread that it be a 'epel-release-stream' or whatever subpackage, so they have to install that and enable it (just like they would for enabling stream)
- used *with* epel8, not *instead of*
So, maintainers would need to be careful to make sure epel8-next or whatever packages are rpm 'newer' at all times to make this work right? Or I guess if they were fixing soname issues like above, dnf might be smart enough to pull in the next version anyhow even if it was lower than the epel8 one (unless the user used --best).
Possibly it would be best to say 'must be newer' and have some kind of check... ?
This will provide EPEL packagers a place where they can update their packages when necessary to be compatible with CentOS 8 Stream. These packages would also be useful for RHEL 8 users during the gap between a RHEL minor release and the equivalent CentOS 8 Linux rebuild. In theory this repository should also be directly consumable by RHEL 8 Beta releases. Similar to RHEL itself, breaking changes could be permitted in epel8-next in preparation for delivering them to epel8 around the time of the next RHEL minor release.
So, say I have package foo that needs a rebuild to work with stream. I request a branch, do a build and everything there is happy. Now, 8.x comes out and the main epel8 one needs a rebuild. I do that and push it out and everything is happy again... but what about the epel8-stream/next package? It just sits there older and unused?
This proposal may sound similar to epel8-playground. However, that was still built against RHEL 8, so it didn't solve the compatibility issue with CentOS 8 Stream. This proposal does draw on lessons learned from the playground experiment.
- no automatic builds via packages.cfg
- opt-in rather than opt-out
- layering on top of epel8, rather than duplicating content
I first suggested this idea at the last EPEL Steering Committee meeting, and we plan to discuss it again during the next one. Please share your thoughts on this proposal.
I assume this would work like playground/rawhide as far as landing in the buildroot right after build and going out in the daily compose? Or would you want to use bodhi updates?
kevin
So, maintainers would need to be careful to make sure epel8-next or whatever packages are rpm 'newer' at all times to make this work right? Or I guess if they were fixing soname issues like above, dnf might be smart enough to pull in the next version anyhow even if it was lower than the epel8 one (unless the user used --best).
Yes, I believe dnf helps us out here as you described. We could also document that packagers should take care to ensure the upgrade path works from epel8 to epel8-next, similar to Fedora branches. Fedora has the added benefit of the dist macro always ensuring the release field is higher on higher branches, but in our cases it's .el8 for both. Maybe we could consider redefining dist for epel8-next builds to accomplish the same thing, but I'm not sure it's worth the effort.
So, say I have package foo that needs a rebuild to work with stream. I request a branch, do a build and everything there is happy. Now, 8.x comes out and the main epel8 one needs a rebuild. I do that and push it out and everything is happy again... but what about the epel8-stream/next package? It just sits there older and unused?
Yes, but I don't see a problem with this.
I assume this would work like playground/rawhide as far as landing in the buildroot right after build and going out in the daily compose? Or would you want to use bodhi updates?
My preference would be to use bodhi updates. I think updates getting published without review would degrade the experience for CentOS Stream users. We could do a lower karma/time threashold than regular EPEL if desired.
On Wed, Sep 9, 2020 at 11:55 AM Kevin Fenzi kevin@scrye.com wrote:
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
Howdy folks,
A large part of my day job is working on CentOS Stream. Naturally I would like it to be successful and have wide adoption. I know that EPEL will play a big role in this success. EPEL is extremely popular. Many users consider RHEL and CentOS unusable without it.
The problem we are facing is that EPEL 8 cannot be 100% compatible with RHEL/CentOS 8 and CentOS 8 Stream at the same time. It is not uncommon for RHEL to ship library soname changes in minor releases. In the RHEL 8 cycle, those changes are showing up in CentOS 8 Stream first. EPEL 8 builds against the latest RHEL 8 release. This can result in EPEL 8 packages that are uninstallable on CentOS 8 Stream due to the library differences. One prominent example we have already seen is llvm-libs, which has increased its library soname in every RHEL 8 minor release so far. Another increase is planned for RHEL 8.3, which has already been released in CentOS 8 Stream. There are likely other incompatibilities that haven't been noticed yet. I expect this problem to grow worse as RHEL development continues and more packages are added to EPEL 8. This situation is hurting the adoption of CentOS Stream.
To solve this problem, I am proposing that we create a new repository called EPEL 8 Next.
- built against CentOS 8 Stream
- opt-in for packagers (must request epel8-next dist-git branch)
- opt-in for users (part of epel-release but disabled by default)
I like tdawsons idea down thread that it be a 'epel-release-stream' or whatever subpackage, so they have to install that and enable it (just like they would for enabling stream)
- used *with* epel8, not *instead of*
So, maintainers would need to be careful to make sure epel8-next or whatever packages are rpm 'newer' at all times to make this work right? Or I guess if they were fixing soname issues like above, dnf might be smart enough to pull in the next version anyhow even if it was lower than the epel8 one (unless the user used --best).
Possibly it would be best to say 'must be newer' and have some kind of check... ?
This will provide EPEL packagers a place where they can update their packages when necessary to be compatible with CentOS 8 Stream. These packages would also be useful for RHEL 8 users during the gap between a RHEL minor release and the equivalent CentOS 8 Linux rebuild. In theory this repository should also be directly consumable by RHEL 8 Beta releases. Similar to RHEL itself, breaking changes could be permitted in epel8-next in preparation for delivering them to epel8 around the time of the next RHEL minor release.
So, say I have package foo that needs a rebuild to work with stream. I request a branch, do a build and everything there is happy. Now, 8.x comes out and the main epel8 one needs a rebuild. I do that and push it out and everything is happy again... but what about the epel8-stream/next package? It just sits there older and unused?
This proposal may sound similar to epel8-playground. However, that was still built against RHEL 8, so it didn't solve the compatibility issue with CentOS 8 Stream. This proposal does draw on lessons learned from the playground experiment.
- no automatic builds via packages.cfg
- opt-in rather than opt-out
- layering on top of epel8, rather than duplicating content
I first suggested this idea at the last EPEL Steering Committee meeting, and we plan to discuss it again during the next one. Please share your thoughts on this proposal.
I assume this would work like playground/rawhide as far as landing in the buildroot right after build and going out in the daily compose? Or would you want to use bodhi updates?
kevin _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
On Wed, Sep 09, 2020 at 01:15:29PM -0500, Carl George wrote:
So, maintainers would need to be careful to make sure epel8-next or whatever packages are rpm 'newer' at all times to make this work right? Or I guess if they were fixing soname issues like above, dnf might be smart enough to pull in the next version anyhow even if it was lower than the epel8 one (unless the user used --best).
Yes, I believe dnf helps us out here as you described. We could also document that packagers should take care to ensure the upgrade path works from epel8 to epel8-next, similar to Fedora branches. Fedora has the added benefit of the dist macro always ensuring the release field is higher on higher branches, but in our cases it's .el8 for both. Maybe we could consider redefining dist for epel8-next builds to accomplish the same thing, but I'm not sure it's worth the effort.
Changing the dist tag is pretty easy (can be done in koji)...
% rpmdev-vercmp 1.0-1.el8 1.0-1.epel8stream 1.0-1.el8 < 1.0-1.epel8stream
Might also make it easier to see where packages came from?
So, say I have package foo that needs a rebuild to work with stream. I request a branch, do a build and everything there is happy. Now, 8.x comes out and the main epel8 one needs a rebuild. I do that and push it out and everything is happy again... but what about the epel8-stream/next package? It just sits there older and unused?
Yes, but I don't see a problem with this.
ok. I'm not sure it's a problem per se, but something to note.
I assume this would work like playground/rawhide as far as landing in the buildroot right after build and going out in the daily compose? Or would you want to use bodhi updates?
My preference would be to use bodhi updates. I think updates getting published without review would degrade the experience for CentOS Stream users. We could do a lower karma/time threashold than regular EPEL if desired.
ok. Thats a non trivial amount of work added on. (creating bodhi release for it, updating sync scripts and punji config, etc). Can be done, but will definitely be more work.
kevin
Howdy again folks,
I know people have been curious about what happened with this proposal. I apologize for the lack of updates in this thread. The proposal was approved by unanimous vote by the EPEL Steering Committee last October [0]. It has been a regular topic at the weekly committee meetings since then, with slow but steady progress.
I'm happy to report that we are near completion of the work to launch EPEL Next. Initial documentation is on the wiki [1]. Fedpkg 1.40-6 [2] added support for requesting epel8-next branches, and has been widely available since April. The epel-next-release subpackage is currently available in the testing repo [3]. There is already one package available in the repo (qt5-qtwebkit [4]), which we used to verify the pipeline worked correctly.
Let me know if there is anything else you would like to see in the documentation, especially FAQ items [5]. I would also appreciate any testing and karma on the epel-next-release bodhi update [2]. If you have a package that requires an EPEL Next rebuild (mainly qt packages currently), go ahead and try the workflow [6] and report any issues.
[0] https://meetbot.fedoraproject.org/teams/epel/epel.2020-10-23-21.01.html [1] https://fedoraproject.org/wiki/EPEL_Next [2] https://src.fedoraproject.org/rpms/fedpkg/c/ee2d8465803e11c236ae764d445b9959... [3] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-159d68a2ef [4] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2021-c0fcb78eb0 [5] https://fedoraproject.org/wiki/EPEL_Next#FAQ [6] https://fedoraproject.org/wiki/EPEL_Next#Example_Workflow
On Tue, Sep 8, 2020 at 11:00 PM Carl George carl@redhat.com wrote:
Howdy folks,
A large part of my day job is working on CentOS Stream. Naturally I would like it to be successful and have wide adoption. I know that EPEL will play a big role in this success. EPEL is extremely popular. Many users consider RHEL and CentOS unusable without it.
The problem we are facing is that EPEL 8 cannot be 100% compatible with RHEL/CentOS 8 and CentOS 8 Stream at the same time. It is not uncommon for RHEL to ship library soname changes in minor releases. In the RHEL 8 cycle, those changes are showing up in CentOS 8 Stream first. EPEL 8 builds against the latest RHEL 8 release. This can result in EPEL 8 packages that are uninstallable on CentOS 8 Stream due to the library differences. One prominent example we have already seen is llvm-libs, which has increased its library soname in every RHEL 8 minor release so far. Another increase is planned for RHEL 8.3, which has already been released in CentOS 8 Stream. There are likely other incompatibilities that haven't been noticed yet. I expect this problem to grow worse as RHEL development continues and more packages are added to EPEL 8. This situation is hurting the adoption of CentOS Stream.
To solve this problem, I am proposing that we create a new repository called EPEL 8 Next.
- built against CentOS 8 Stream
- opt-in for packagers (must request epel8-next dist-git branch)
- opt-in for users (part of epel-release but disabled by default)
- used *with* epel8, not *instead of*
This will provide EPEL packagers a place where they can update their packages when necessary to be compatible with CentOS 8 Stream. These packages would also be useful for RHEL 8 users during the gap between a RHEL minor release and the equivalent CentOS 8 Linux rebuild. In theory this repository should also be directly consumable by RHEL 8 Beta releases. Similar to RHEL itself, breaking changes could be permitted in epel8-next in preparation for delivering them to epel8 around the time of the next RHEL minor release.
This proposal may sound similar to epel8-playground. However, that was still built against RHEL 8, so it didn't solve the compatibility issue with CentOS 8 Stream. This proposal does draw on lessons learned from the playground experiment.
- no automatic builds via packages.cfg
- opt-in rather than opt-out
- layering on top of epel8, rather than duplicating content
I first suggested this idea at the last EPEL Steering Committee meeting, and we plan to discuss it again during the next one. Please share your thoughts on this proposal.
-- Carl George
epel-devel@lists.fedoraproject.org
-
Ben Cotton -
Björn Persson -
Carl George -
Heiskanen Mika (FMI) -
Jochen Wiedmann -
José Abílio Matos -
Ken Dreyer -
Kevin Fenzi -
Matthew Miller -
Patrick Riehecky -
Petr Pisar -
Stephen John Smoogen -
Troy Dawson