[EPEL-devel] Re: ROCm and Backwards-Incompatible Updates in EPEL10

2025-10-27 Thread Jeremy Newton 
The update to 6.4.4 for F43 here:
https://bodhi.fedoraproject.org/updates/FEDORA-2025-6ed0814d96

For Fedora, we are basically just updating rawhide, then when it branches, that 
Fedora release we keep on the same major/minor + updates unless there's a good 
reason to port a newer minor release.

I think the jist of the proposal is to just treat the epel minor release 
branches like we do with Fedora, but tip of EPEL will be more conservative than 
rawhide.

So Fedora is stuck on 6.4.x, so we're updating it to 6.4.4, as it was released 
recently, but rawhide is already on 7.0.x.
Since 6.4.x is the last of the 6.x.x series, we'll keep Fedora 43 on 6.4 for 
its life.
Once 7.0 seems stable enough, we can port it to epel10, and hopefully it will 
happen before 10.2 branches.
-- 
___
epel-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: ROCm and Backwards-Incompatible Updates in EPEL10

2025-10-24 Thread Tim Flink 



On 10/24/25 11:02 AM, Troy Dawson wrote:
On Fri, Oct 24, 2025 at 9:23 AM Tim Flink > wrote:


Hi, I'm one of the folks working on ROCm packaging in Fedora and
EPEL. We're looking to continue updating the ROCm stack in EPEL10
but recognize that this will involve some backwards-incompatible
changes. We realize that this is a little outside what has
historically been done in EPEL and as such, are starting with a
discussion on epel-devel and will follow up with a ticket for the
EPEL steering committee similar to what is outlined in the
incompatible upgrades policy [1].

[1] https://docs.fedoraproject.org/en-US/epel/epel-policy-
incompatible-upgrades/ 

I have included our proposal at the end of this email and welcome
discussion around how we can minimize the pain to others while
keeping ROCm up to date in EPEL10.

Thanks,

Tim

--

tl;dr

The ROCm packagers are proposing to make backwards incompatible
changes in a controlled way so that we can make sure that the latest
ROCm features are available to EPEL10 users.


Background


ROCm is an open-source software platform that provides the tools for
programming AMD Graphics Processing Units (GPUs), from low-level
kernels to high-level end-user applications including AI and HPC.

There seems to have been a decent amount of interest in having the
ROCm packages available in EPEL and we've been able to get the vast
majority of the packages in Rawhide into EPEL for ROCm 6. ROCm 7 has
recently been released and we would like to import this new version
from Rawhide to EPEL but ROCm 7 is a major release and it will
introduce breaking changes.

This is not going to be the only backwards-incompatible change to
ROCm over the EL10 lifecycle. For example, ROCm 8 is expected to
land sometime next year or there could be changes between minor
releases and we want to make the case that it would be worth
granting an exception to allow us to keep the latest ROCm available
in EPEL instead of sticking to a single version (6.x in our case)
for all of EPEL10. We have not requested any EPEL9 branches and we
currently have no plans to build ROCm packages for anything older
than EPEL 10.1.

--
Proposal
--

We'd like to continue updating ROCm in EPEL but don't want to ignore
the existing policies and intents around making changes all the
time. As such, we're requesting and proposing that ROCm package
updates going forward be allowed to break backwards-compatibility so
long follow the following rules:

1. There will only be one minor release of ROCm within a minor
release of EPEL.

This means that the upcoming ROCm 7 will never be part of epel 10.1
because that would be a disruptive, backwards incompatible change.
ROCm 7, if brought into EPEL would be part of 10.2 or later.


2. Backwards incompatible changes could ONLY happen between minor
EPEL releases

Assuming that nothing wholly unexpected happens, this means that
epel 10.2 would get an update to at least ROCm 7.x or maybe even
newer if the release dates work out and stable packages are
available prior to the EPEL 10.2 branching date.


3. The set of ROCm packages consist of all packages co-maintained by
the rocm-packagers-sig that have EPEL branches

This list of packages will likely change over time but can be found
at https://src.fedoraproject.org/group/rocm-packagers-sig 


---
Justification
---

The justification for our request really comes down to keeping the
latest and greatest features for ROCm available for EPEL10 users.
This includes enabling new hardware as it is released (the upcoming
MI350 accelerators will require ROCm > 7.0 as an example) in
addition to enabling the latest versions of software like pytorch.

In the end, we’re looking to make ROCm as easy to install and use as
possible through better integration with Linux distributions and in
this case, EPEL. This is why we are working to package and update
the ROCm stack in Fedora and EPEL.


Thank you for starting the discussion.
I know you want to talk about EPEL, but I'm curious what the process 
is /or will be for Fedora, so I/we can compare.


So far, our process has been similar for Fedora. All of the intentionally 
backwards-incompatible changes are made in rawhide and we have kept to one 
minor release of ROCm per Fedora release.

The most that we plan on changing within a Fedora release would be something 
like the pending update for F43 [1]. ROCm 6.4.3 was current when rawhide 
branched but 6.4.4 adds support for some of AMD's newer APUs. That update has 
been built and is c

[EPEL-devel] Re: ROCm and Backwards-Incompatible Updates in EPEL10

2025-10-24 Thread Troy Dawson 
On Fri, Oct 24, 2025 at 9:23 AM Tim Flink  wrote:

> Hi, I'm one of the folks working on ROCm packaging in Fedora and EPEL.
> We're looking to continue updating the ROCm stack in EPEL10 but recognize
> that this will involve some backwards-incompatible changes. We realize that
> this is a little outside what has historically been done in EPEL and as
> such, are starting with a discussion on epel-devel and will follow up with
> a ticket for the EPEL steering committee similar to what is outlined in the
> incompatible upgrades policy [1].
>
> [1]
> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>
> I have included our proposal at the end of this email and welcome
> discussion around how we can minimize the pain to others while keeping ROCm
> up to date in EPEL10.
>
> Thanks,
>
> Tim
>
> --
>
> tl;dr
>
> The ROCm packagers are proposing to make backwards incompatible changes in
> a controlled way so that we can make sure that the latest ROCm features are
> available to EPEL10 users.
>
> 
> Background
> 
>
> ROCm is an open-source software platform that provides the tools for
> programming AMD Graphics Processing Units (GPUs), from low-level kernels to
> high-level end-user applications including AI and HPC.
>
> There seems to have been a decent amount of interest in having the ROCm
> packages available in EPEL and we've been able to get the vast majority of
> the packages in Rawhide into EPEL for ROCm 6. ROCm 7 has recently been
> released and we would like to import this new version from Rawhide to EPEL
> but ROCm 7 is a major release and it will introduce breaking changes.
>
> This is not going to be the only backwards-incompatible change to ROCm
> over the EL10 lifecycle. For example, ROCm 8 is expected to land sometime
> next year or there could be changes between minor releases and we want to
> make the case that it would be worth granting an exception to allow us to
> keep the latest ROCm available in EPEL instead of sticking to a single
> version (6.x in our case) for all of EPEL10. We have not requested any
> EPEL9 branches and we currently have no plans to build ROCm packages for
> anything older than EPEL 10.1.
>
> --
> Proposal
> --
>
> We'd like to continue updating ROCm in EPEL but don't want to ignore the
> existing policies and intents around making changes all the time. As such,
> we're requesting and proposing that ROCm package updates going forward be
> allowed to break backwards-compatibility so long follow the following rules:
>
> 1. There will only be one minor release of ROCm within a minor release of
> EPEL.
>
> This means that the upcoming ROCm 7 will never be part of epel 10.1
> because that would be a disruptive, backwards incompatible change. ROCm 7,
> if brought into EPEL would be part of 10.2 or later.
>
>
> 2. Backwards incompatible changes could ONLY happen between minor EPEL
> releases
>
> Assuming that nothing wholly unexpected happens, this means that epel 10.2
> would get an update to at least ROCm 7.x or maybe even newer if the release
> dates work out and stable packages are available prior to the EPEL 10.2
> branching date.
>
>
> 3. The set of ROCm packages consist of all packages co-maintained by the
> rocm-packagers-sig that have EPEL branches
>
> This list of packages will likely change over time but can be found at
> https://src.fedoraproject.org/group/rocm-packagers-sig
>
>
> ---
> Justification
> ---
>
> The justification for our request really comes down to keeping the latest
> and greatest features for ROCm available for EPEL10 users. This includes
> enabling new hardware as it is released (the upcoming MI350 accelerators
> will require ROCm > 7.0 as an example) in addition to enabling the latest
> versions of software like pytorch.
>
> In the end, we’re looking to make ROCm as easy to install and use as
> possible through better integration with Linux distributions and in this
> case, EPEL. This is why we are working to package and update the ROCm stack
> in Fedora and EPEL.


Thank you for starting the discussion.
I know you want to talk about EPEL, but I'm curious what the process is /or
will be for Fedora, so I/we can compare.
-- 
___
epel-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue