Hi All, EPEL2RHEL is part of the RHEL 8 and 9 new package workflow. When a RHEL maintainer wants to add a package to RHEL 8 or 9 they start a "new package workflow". There are several automations that happen when they start that workflow. One of them is checking if the package is already in epel. If it is, it creates a bugzilla against that package, and links that bug against the EPEL2RHEL tracker. [1] Remember, this check currently happens at the beginning of the new package workflow. Before a package has been branched, built, or put into testing repos.
Thus far, there are three problems.
1 - The wording can be confusing: Subject: Remove <package> from epel9 Comment: This package is being added to RHEL 9.1 at the next minor release. Please remove it from epel after the next RHEL minor release.
The subject sounds like it should be removed right now. Only if the maintainer reads the comments do they see it should be removed after the next release. What is further confusing is if the package is coming out for a release that has already happened. We just had one that said it was being added to RHEL 8.6. The instructions clearly state that it should be removed after RHEL 8.6 is released, and so it was removed.
2 - What about BuildRoot only packages. If a RHEL package is a BuildRoot only package, they are fine being in epel. But at the time the new package is requested, the scripts have no way of knowing where the binary packages will end up. Thus, it is possible that a package creates an EPEL2RHEL bug, that package ends up being in RHEL BuildRoot only, and the epel maintainer removed the package anyway.
3 - Race conditions We already saw in RHEL 8.6 that race conditions exist. There were two packages that were requested in epel and RHEL on the same week. Both checked, didn't see anything, and then went along their proper path. Only to find out that when RHEL 8.6 was released, we had duplicate packages in epel8.
** Solution(s) A - At the very least, we need to change the wording of the bugs. I am proposing the following
Subject: Remove <package> from epel9 when rhel 9.1 is released Comment: This package is being added to RHEL 9.1 at the next minor release. After the next RHEL minor release, please verify this package was released in RHEL, and if so remove it from epel9.
B - If possible, move the EPEL2RHEL check to later in the development cycle. I would like it to be in the step where the packages get added to BaseOS, AppStream, or CRB. That way we would know it isn't going to be a BuildRoot only package, and it would reduce the time the bugs sit waiting. I don't know if this is possible, but I'm going to ask.
C - ?? What if we only created the bugs on the tracker itself, and not the individual packages ?? Would that be a good thing? Or would it irritate the maintainers?
Troy
On 01. 09. 22 0:19, Troy Dawson wrote:
** Solution(s) A - At the very least, we need to change the wording of the bugs. I am proposing the following
Subject: Remove <package> from epel9 when rhel 9.1 is released Comment: This package is being added to RHEL 9.1 at the next minor release. After the next RHEL minor release, please verify this package was released in RHEL, and if so remove it from epel9.
Yes please. Ideally, even add a reproducer that verifies this ("go to X and search for the package name" or "run this repoquery" or even "go to this documentation page to check it")
B - If possible, move the EPEL2RHEL check to later in the development cycle. I would like it to be in the step where the packages get added to BaseOS, AppStream, or CRB. That way we would know it isn't going to be a BuildRoot only package, and it would reduce the time the bugs sit waiting. I don't know if this is possible, but I'm going to ask.
Agreed. It could even say which (sub)packages are being added and link to the appropriate documentation in case some of the EPEL subpackages need to be split into a spearate component.
C - ?? What if we only created the bugs on the tracker itself, and not the individual packages ?? Would that be a good thing? Or would it irritate the maintainers?
What do you mean by this? I don't understand it. File it against the distribution? If there is a dedicated (and educated) person/team who would deal with this at all RHEL release boundaries, than this makes sense. Otherwise it just hides this information from the EPEL maintainers.
On Wednesday, August 31, 2022 Troy Dawson wrote:
EPEL2RHEL is part of the RHEL 8 and 9 new package workflow. When a RHEL maintainer wants to add a package to RHEL 8 or 9 they start a "new package workflow". There are several automations that happen when they start that workflow. One of them is checking if the package is already in epel. If it is, it creates a bugzilla against that package, and links that bug against the EPEL2RHEL tracker. [1] Remember, this check currently happens at the beginning of the new package workflow. Before a package has been branched, built, or put into testing repos.
I think this whole process should be automated. File bugs that say "Heads up: your package will be automatically retired after the release of RHEL X.X" and provide some explanation. This will have multiple benefits:
1. Saying "you'll have to do something in six months, but it'll be bad if you do it now" is quite difficult to follow.
2. We can send out one announcement to epel-announce about which packages are going to be retired and when that'll happen, instead of retiring packages in a piecemeal manner.
3. The maintainers won't have to remember to do it.
4. If we find out that a package is buildroot only, then we'll close the bug and exclude it from the automatic retiring.
On Thu, Sep 01, 2022 at 12:12:07PM -0500, Maxwell G via epel-devel wrote:
On Wednesday, August 31, 2022 Troy Dawson wrote:
EPEL2RHEL is part of the RHEL 8 and 9 new package workflow. When a RHEL maintainer wants to add a package to RHEL 8 or 9 they start a "new package workflow". There are several automations that happen when they start that workflow. One of them is checking if the package is already in epel. If it is, it creates a bugzilla against that package, and links that bug against the EPEL2RHEL tracker. [1] Remember, this check currently happens at the beginning of the new package workflow. Before a package has been branched, built, or put into testing repos.
I think this whole process should be automated. File bugs that say "Heads up: your package will be automatically retired after the release of RHEL X.X" and provide some explanation. This will have multiple benefits:
- Saying "you'll have to do something in six months, but it'll be bad if you
do it now" is quite difficult to follow.
- We can send out one announcement to epel-announce about which packages are
going to be retired and when that'll happen, instead of retiring packages in a piecemeal manner.
The maintainers won't have to remember to do it.
If we find out that a package is buildroot only, then we'll close the bug
and exclude it from the automatic retiring.
I really like this approach... :)
kevin
On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
I think this whole process should be automated. File bugs that say "Heads up: your package will be automatically retired after the release of RHEL X.X" and provide some explanation.
Agreed. This is a pretty mechanical process: all the maintainer would do is run "fedpkg retire" for the appropriate branches, and that looks reasonable to automate. If we're concerned about bugs in the automation retiring packages that shouldn't be impacted, we can have it file a ticket for signoff on the EPEL tracker (or have some other process to spot check, at least until we're confiden it'll do the right thing).
Cheers Davide
On Friday, 02 September 2022 at 18:25, Kevin Fenzi wrote:
On Thu, Sep 01, 2022 at 12:12:07PM -0500, Maxwell G via epel-devel wrote:
On Wednesday, August 31, 2022 Troy Dawson wrote:
EPEL2RHEL is part of the RHEL 8 and 9 new package workflow. When a RHEL maintainer wants to add a package to RHEL 8 or 9 they start a "new package workflow". There are several automations that happen when they start that workflow. One of them is checking if the package is already in epel. If it is, it creates a bugzilla against that package, and links that bug against the EPEL2RHEL tracker. [1] Remember, this check currently happens at the beginning of the new package workflow. Before a package has been branched, built, or put into testing repos.
I think this whole process should be automated. File bugs that say "Heads up: your package will be automatically retired after the release of RHEL X.X" and provide some explanation. This will have multiple benefits:
- Saying "you'll have to do something in six months, but it'll be bad if you
do it now" is quite difficult to follow.
- We can send out one announcement to epel-announce about which packages are
going to be retired and when that'll happen, instead of retiring packages in a piecemeal manner.
The maintainers won't have to remember to do it.
If we find out that a package is buildroot only, then we'll close the bug
and exclude it from the automatic retiring.
I really like this approach... :)
It would be really nice if the wording of the bug could contain some kind of a "thank you" note to the EPEL maintainers of the package in question. Not everyone will understand this process as "great, I don't have to maintain package X anymore, Red Hat will be doing that for me from now on". Some folks may take it as "Oh no! Red Hat is taking away my toy! Why?!" Ideally, there should still be a way for EPEL maintainer(s) to continue contributing to the RHEL package.
Regards, Dominik
On Mon, 2022-09-05 at 11:33 +0200, Dominik 'Rathann' Mierzejewski wrote:
It would be really nice if the wording of the bug could contain some kind of a "thank you" note to the EPEL maintainers of the package in question. Not everyone will understand this process as "great, I don't have to maintain package X anymore, Red Hat will be doing that for me from now on". Some folks may take it as "Oh no! Red Hat is taking away my toy! Why?!" Ideally, there should still be a way for EPEL maintainer(s) to continue contributing to the RHEL package.
This is a great idea. Maybe we could have a link to a doc that explains what's going on in more details and how to contribute to the package once it's in RHEL ?
Cheers Davide
On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel < epel-devel@lists.fedoraproject.org> wrote:
On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
I think this whole process should be automated. File bugs that say "Heads up: your package will be automatically retired after the release of RHEL X.X" and provide some explanation.
Agreed. This is a pretty mechanical process: all the maintainer would do is run "fedpkg retire" for the appropriate branches, and that looks reasonable to automate. If we're concerned about bugs in the automation retiring packages that shouldn't be impacted, we can have it file a ticket for signoff on the EPEL tracker (or have some other process to spot check, at least until we're confiden it'll do the right thing).
Sorry for delaying this for so long. Things came up, but now I have some time.
I think step one in this automation workflow is to not assign the bugs to the package at all. Assign the bugs to EPEL / distribution, but keep them as blockers on the EPEL2RHEL tracker[1]. This gets rid of the busy maintainer problem. Where they just read the subject and do what it says. This also allows the automation to not have to deal with all the different packages.
I think for the automation to happen, we also have to get the subject line updated. If we can get it to have what release is in it, parsing the subject line is much easier than going through all the bugzilla comments trying to find what release this is supposed to come out in. Something like "Remove yara from epel8 when RHEL 8.7 is released"
I think once we get to that point, I should be able to write a script that can grab all the open tickets on the EPEL2RHEL tracker and check if they are released, and do appropriate things.
Does this sound good to people?
Troy
Hi Troy,
On Tue Nov 1, 2022 at 07:07 -0700, Troy Dawson wrote:
On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel < epel-devel@lists.fedoraproject.org> wrote:
On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
I think this whole process should be automated. File bugs that say "Heads up: your package will be automatically retired after the release of RHEL X.X" and provide some explanation.
Agreed. This is a pretty mechanical process: all the maintainer would do is run "fedpkg retire" for the appropriate branches, and that looks reasonable to automate. If we're concerned about bugs in the automation retiring packages that shouldn't be impacted, we can have it file a ticket for signoff on the EPEL tracker (or have some other process to spot check, at least until we're confiden it'll do the right thing).
Sorry for delaying this for so long. Things came up, but now I have some time.
I think step one in this automation workflow is to not assign the bugs to the package at all. Assign the bugs to EPEL / distribution, but keep them as blockers on the EPEL2RHEL tracker[1]. This gets rid of the busy maintainer problem. Where they just read the subject and do what it says. This also allows the automation to not have to deal with all the different packages.
I'm not sure filling against distribution is a good idea. I'd just file bugs against the affected component, set the bug assignee to yourself, and close it once you preform the automatic retirement. This way, you won't have to worry about CCing the proper maintainer on the distribution bug and the bugs will be more organized. The subject is a separate problem.
I think for the automation to happen, we also have to get the subject line updated. If we can get it to have what release is in it, parsing the subject line is much easier than going through all the bugzilla comments trying to find what release this is supposed to come out in. Something like "Remove yara from epel8 when RHEL 8.7 is released"
I'd prefer something like the originally suggested "Notice: PACKAGE_HERE will be automatically retired in RHEL X.X" so it's clear that maintainers don't need to take manual action.
-- Maxwell G (@gotmax23) Pronouns: He/They
On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
It would be really nice if the wording of the bug could contain some kind of a "thank you" note to the EPEL maintainers of the package in question. Not everyone will understand this process as "great, I don't have to maintain package X anymore, Red Hat will be doing that for me from now on". Some folks may take it as "Oh no! Red Hat is taking away my toy! Why?!" Ideally, there should still be a way for EPEL maintainer(s) to continue contributing to the RHEL package.
Perhaps add something like (wordsmithed by someone competent in such things):
"The package you have been maintaining in EPEL is now considered important enough to a large enough part of our customers that Red Hat has decided to promote it to being an officially supported part of the product...."
On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
It would be really nice if the wording of the bug could contain some kind of a "thank you" note to the EPEL maintainers of the package in question. Not everyone will understand this process as "great, I don't have to maintain package X anymore, Red Hat will be doing that for me from now on". Some folks may take it as "Oh no! Red Hat is taking away my toy! Why?!" Ideally, there should still be a way for EPEL maintainer(s) to continue contributing to the RHEL package.
Perhaps add something like (wordsmithed by someone competent in such things):
"The package you have been maintaining in EPEL is now considered important enough to a large enough part of our customers that Red Hat has decided to promote it to being an officially supported part of the product...."
I like that idea. It's much more positive. A nice "Thank you for doing this in EPEL" type of feel.
Troy
On Sun, Feb 19, 2023 at 4:34 PM Maxwell G maxwell@gtmx.me wrote:
Hi Troy,
On Tue Nov 1, 2022 at 07:07 -0700, Troy Dawson wrote:
On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel < epel-devel@lists.fedoraproject.org> wrote:
On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
I think this whole process should be automated. File bugs that say "Heads up: your package will be automatically retired after the release of RHEL X.X" and provide some explanation.
Agreed. This is a pretty mechanical process: all the maintainer would do is run "fedpkg retire" for the appropriate branches, and that looks reasonable to automate. If we're concerned about bugs in the automation retiring packages that shouldn't be impacted, we can have it file a ticket for signoff on the EPEL tracker (or have some other process to spot check, at least until we're confiden it'll do the right thing).
Sorry for delaying this for so long. Things came up, but now I have some time.
I think step one in this automation workflow is to not assign the bugs to the package at all. Assign the bugs to EPEL / distribution, but keep them as blockers on the EPEL2RHEL tracker[1]. This gets rid of the busy maintainer problem. Where they just read the subject and do what it says. This also allows the automation to not have to deal with all the
different
packages.
I'm not sure filling against distribution is a good idea. I'd just file bugs against the affected component, set the bug assignee to yourself, and close it once you preform the automatic retirement. This way, you won't have to worry about CCing the proper maintainer on the distribution bug and the bugs will be more organized. The subject is a separate problem.
I think for the automation to happen, we also have to get the subject
line
updated. If we can get it to have what release is in it, parsing the subject line
is
much easier than going through all the bugzilla comments trying to find what release this is supposed to come out in. Something like "Remove yara from epel8 when RHEL 8.7 is released"
I'd prefer something like the originally suggested "Notice: PACKAGE_HERE will be automatically retired in RHEL X.X" so it's clear that maintainers don't need to take manual action.
That is a good point.
On a related note. For the past month or so, as new packages get added to the tracker I've been manually adding a comment that the package shouldn't be retired until (date) which is when (release) will come out. That has usually been May 2023 when RHEL 8.8 / 9.2 comes out. Several of the maintainers have thanked me for the clarification. I've been doing this mainly so I can get a feel for what the script should be doing. But one thing came up that I don't have an answer to.
I haven't said "We will automatically retire this for you" because I don't know who "we" is/are. Is it the committee? (could be, that seems the most likely) Is it the epel-packagers-sig? (I don't think that's right.) Is it a different "retirement group"?
Thoughts? Troy
On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson tdawson@redhat.com wrote:
On Sun, Feb 19, 2023 at 4:34 PM Maxwell G maxwell@gtmx.me wrote:
Hi Troy,
On Tue Nov 1, 2022 at 07:07 -0700, Troy Dawson wrote:
On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel < epel-devel@lists.fedoraproject.org> wrote:
On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
I think this whole process should be automated. File bugs that say "Heads up: your package will be automatically retired after the release of RHEL X.X" and provide some explanation.
Agreed. This is a pretty mechanical process: all the maintainer would do is run "fedpkg retire" for the appropriate branches, and that looks reasonable to automate. If we're concerned about bugs in the automation retiring packages that shouldn't be impacted, we can have it file a ticket for signoff on the EPEL tracker (or have some other process to spot check, at least until we're confiden it'll do the right thing).
Sorry for delaying this for so long. Things came up, but now I have some time.
I think step one in this automation workflow is to not assign the bugs to the package at all. Assign the bugs to EPEL / distribution, but keep them as blockers on the EPEL2RHEL tracker[1]. This gets rid of the busy maintainer problem. Where they just read the subject and do what it says. This also allows the automation to not have to deal with all the different packages.
I'm not sure filling against distribution is a good idea. I'd just file bugs against the affected component, set the bug assignee to yourself, and close it once you preform the automatic retirement. This way, you won't have to worry about CCing the proper maintainer on the distribution bug and the bugs will be more organized. The subject is a separate problem.
I think for the automation to happen, we also have to get the subject line updated. If we can get it to have what release is in it, parsing the subject line is much easier than going through all the bugzilla comments trying to find what release this is supposed to come out in. Something like "Remove yara from epel8 when RHEL 8.7 is released"
I'd prefer something like the originally suggested "Notice: PACKAGE_HERE will be automatically retired in RHEL X.X" so it's clear that maintainers don't need to take manual action.
That is a good point.
On a related note. For the past month or so, as new packages get added to the tracker I've been manually adding a comment that the package shouldn't be retired until (date) which is when (release) will come out. That has usually been May 2023 when RHEL 8.8 / 9.2 comes out. Several of the maintainers have thanked me for the clarification. I've been doing this mainly so I can get a feel for what the script should be doing. But one thing came up that I don't have an answer to.
I haven't said "We will automatically retire this for you" because I don't know who "we" is/are. Is it the committee? (could be, that seems the most likely) Is it the epel-packagers-sig? (I don't think that's right.) Is it a different "retirement group"?
Thoughts?
It should probably be done by automation, not a person.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, Feb 20, 2023 at 6:45 AM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson tdawson@redhat.com wrote:
On Sun, Feb 19, 2023 at 4:34 PM Maxwell G maxwell@gtmx.me wrote:
Hi Troy,
On Tue Nov 1, 2022 at 07:07 -0700, Troy Dawson wrote:
On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel < epel-devel@lists.fedoraproject.org> wrote:
On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
I think this whole process should be automated. File bugs that say "Heads up: your package will be automatically retired after the release of
RHEL
X.X" and provide some explanation.
Agreed. This is a pretty mechanical process: all the maintainer
would
do is run "fedpkg retire" for the appropriate branches, and that
looks
reasonable to automate. If we're concerned about bugs in the
automation
retiring packages that shouldn't be impacted, we can have it file a ticket for signoff on the EPEL tracker (or have some other process
to
spot check, at least until we're confiden it'll do the right thing).
Sorry for delaying this for so long. Things came up, but now I have
some
time.
I think step one in this automation workflow is to not assign the
bugs to
the package at all. Assign the bugs to EPEL / distribution, but keep them as blockers on
the
EPEL2RHEL tracker[1]. This gets rid of the busy maintainer problem. Where they just read
the
subject and do what it says. This also allows the automation to not have to deal with all the
different
packages.
I'm not sure filling against distribution is a good idea. I'd just file bugs against the affected component, set the bug assignee to yourself, and close it once you preform the automatic retirement. This way, you won't have to worry about CCing the proper maintainer on the distribution bug and the bugs will be more organized. The subject is a separate problem.
I think for the automation to happen, we also have to get the subject
line
updated. If we can get it to have what release is in it, parsing the subject
line is
much easier than going through all the bugzilla comments trying to
find
what release this is supposed to come out in. Something like "Remove yara from epel8 when RHEL 8.7 is released"
I'd prefer something like the originally suggested "Notice: PACKAGE_HERE will be automatically retired in RHEL X.X" so it's clear that maintainers don't need to take manual action.
That is a good point.
On a related note. For the past month or so, as new packages get added to the tracker I've
been manually adding a comment that the package shouldn't be retired until (date) which is when (release) will come out. That has usually been May 2023 when RHEL 8.8 / 9.2 comes out.
Several of the maintainers have thanked me for the clarification. I've been doing this mainly so I can get a feel for what the script
should be doing. But one thing came up that I don't have an answer to.
I haven't said "We will automatically retire this for you" because I
don't know who "we" is/are.
Is it the committee? (could be, that seems the most likely) Is it the epel-packagers-sig? (I don't think that's right.) Is it a different "retirement group"?
Thoughts?
It should probably be done by automation, not a person.
That scares me more than anything. There are so many things that can go wrong when checking if a package is in the repo. The script I was planning on writing would send a list of packages to be removed somewhere and then someone would manually remove them.
Troy
On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson tdawson@redhat.com wrote:
On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
It would be really nice if the wording of the bug could contain some kind of a "thank you" note to the EPEL maintainers of the package in question. Not everyone will understand this process as "great, I don't have to maintain package X anymore, Red Hat will be doing that for me from now on". Some folks may take it as "Oh no! Red Hat is taking away my toy! Why?!" Ideally, there should still be a way for EPEL maintainer(s) to continue contributing to the RHEL package.
Perhaps add something like (wordsmithed by someone competent in such things):
"The package you have been maintaining in EPEL is now considered important enough to a large enough part of our customers that Red Hat has decided to promote it to being an officially supported part of the product...."
I like that idea. It's much more positive. A nice "Thank you for doing this in EPEL" type of feel.
Troy
This is what I have on my ticket. Respond soon (by tomorrow end of day) if you think I need changes.
Subject: Notice: <package> will be automatically retired from epel<major> when RHEL <major>.<minor> is released
Comment: Thank you for your work maintaining <package> in epel<major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from epel<major>.
Troy
On Thu, Mar 16, 2023 at 6:10 PM Troy Dawson tdawson@redhat.com wrote:
On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson tdawson@redhat.com wrote:
On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
It would be really nice if the wording of the bug could contain some kind of a "thank you" note to the EPEL maintainers of the package in question. Not everyone will understand this process as "great, I don't have to maintain package X anymore, Red Hat will be doing that for me from now on". Some folks may take it as "Oh no! Red Hat is taking away my toy! Why?!" Ideally, there should still be a way for EPEL maintainer(s) to continue contributing to the RHEL package.
Perhaps add something like (wordsmithed by someone competent in such things):
"The package you have been maintaining in EPEL is now considered important enough to a large enough part of our customers that Red Hat has decided to promote it to being an officially supported part of the product...."
I like that idea. It's much more positive. A nice "Thank you for doing this in EPEL" type of feel.
Troy
This is what I have on my ticket. Respond soon (by tomorrow end of day) if you think I need changes.
Subject: Notice: <package> will be automatically retired from epel<major> when RHEL <major>.<minor> is released
Comment: Thank you for your work maintaining <package> in epel<major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from epel<major>.
That is pretty well worded, though you can just use "EPEL <major>" instead of "epel<major>".
On Thu, Mar 16, 2023 at 03:10:23PM -0700, Troy Dawson wrote:
This is what I have on my ticket. Respond soon (by tomorrow end of day) if you think I need changes.
Subject: Notice: <package> will be automatically retired from epel<major> when RHEL <major>.<minor> is released
Comment: Thank you for your work maintaining <package> in epel<major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from epel<major>.
That looks pretty good, but I might suggest adding something more explicit at the end:
Note that this issue is purely informational, you do not need to take any actions at this time.
But perhaps thats overkill. ;)
kevin
On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi kevin@scrye.com wrote:
On Thu, Mar 16, 2023 at 03:10:23PM -0700, Troy Dawson wrote:
This is what I have on my ticket. Respond soon (by tomorrow end of day)
if
you think I need changes.
Subject: Notice: <package> will be automatically retired from epel<major> when
RHEL
<major>.<minor> is released
Comment: Thank you for your work maintaining <package> in epel<major>. This
package
has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be
part
of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from epel<major>.
That looks pretty good, but I might suggest adding something more explicit at the end:
Note that this issue is purely informational, you do not need to take any actions at this time.
But perhaps thats overkill. ;)
kevin
It's slight overkill, but you are correct, they might think they have to do something. I have changed the last sentence to be
When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
Troy
On Thu, Mar 16, 2023 at 3:35 PM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Mar 16, 2023 at 6:10 PM Troy Dawson tdawson@redhat.com wrote:
On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson tdawson@redhat.com wrote:
On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster <
gary.buhrmaster@gmail.com> wrote:
On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
It would be really nice if the wording of the bug could contain some kind of a "thank you" note to the EPEL maintainers of the package in question. Not everyone will understand this process as "great, I
don't
have to maintain package X anymore, Red Hat will be doing that for me from now on". Some folks may take it as "Oh no! Red Hat is taking
away
my toy! Why?!" Ideally, there should still be a way for EPEL maintainer(s) to continue contributing to the RHEL package.
Perhaps add something like (wordsmithed by someone competent in such things):
"The package you have been maintaining in EPEL is now considered important enough to a large enough part of our customers that Red Hat has decided to promote it to being an officially supported part of the product...."
I like that idea. It's much more positive. A nice "Thank you for
doing this in EPEL" type of feel.
Troy
This is what I have on my ticket. Respond soon (by tomorrow end of day)
if you think I need changes.
Subject: Notice: <package> will be automatically retired from epel<major> when
RHEL <major>.<minor> is released
Comment: Thank you for your work maintaining <package> in epel<major>. This
package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from epel<major>.
That is pretty well worded, though you can just use "EPEL <major>" instead of "epel<major>".
I was debating whether to use capital letters or not. I agree with you, I think it does look better, and I have capital RHEL. With the bit I added for Kevin, here is what I currently have
Subject: Notice: <package> will be automatically retired from EPEL <major> when RHEL <major>.<minor> is released
Comment:
Thank you for your work maintaining <package> in EPEL <major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
On Thu, Mar 16, 2023 at 7:08 PM Troy Dawson tdawson@redhat.com wrote:
On Thu, Mar 16, 2023 at 3:35 PM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Mar 16, 2023 at 6:10 PM Troy Dawson tdawson@redhat.com wrote:
On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson tdawson@redhat.com wrote:
On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster gary.buhrmaster@gmail.com wrote:
On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
It would be really nice if the wording of the bug could contain some kind of a "thank you" note to the EPEL maintainers of the package in question. Not everyone will understand this process as "great, I don't have to maintain package X anymore, Red Hat will be doing that for me from now on". Some folks may take it as "Oh no! Red Hat is taking away my toy! Why?!" Ideally, there should still be a way for EPEL maintainer(s) to continue contributing to the RHEL package.
Perhaps add something like (wordsmithed by someone competent in such things):
"The package you have been maintaining in EPEL is now considered important enough to a large enough part of our customers that Red Hat has decided to promote it to being an officially supported part of the product...."
I like that idea. It's much more positive. A nice "Thank you for doing this in EPEL" type of feel.
Troy
This is what I have on my ticket. Respond soon (by tomorrow end of day) if you think I need changes.
Subject: Notice: <package> will be automatically retired from epel<major> when RHEL <major>.<minor> is released
Comment: Thank you for your work maintaining <package> in epel<major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from epel<major>.
That is pretty well worded, though you can just use "EPEL <major>" instead of "epel<major>".
I was debating whether to use capital letters or not. I agree with you, I think it does look better, and I have capital RHEL. With the bit I added for Kevin, here is what I currently have
Subject: Notice: <package> will be automatically retired from EPEL <major> when RHEL <major>.<minor> is released
Comment:
Thank you for your work maintaining <package> in EPEL <major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
That looks great!
On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote:
On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi kevin@scrye.com wrote:
On Thu, Mar 16, 2023 at 03:10:23PM -0700, Troy Dawson wrote:
This is what I have on my ticket. Respond soon (by tomorrow end of day) if you think I need changes.
Subject: Notice: <package> will be automatically retired from epel<major> when RHEL <major>.<minor> is released
Comment: Thank you for your work maintaining <package> in epel<major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from epel<major>.
That looks pretty good, but I might suggest adding something more explicit at the end:
Note that this issue is purely informational, you do not need to take any actions at this time.
But perhaps thats overkill. ;)
kevin
It's slight overkill, but you are correct, they might think they have to do something. I have changed the last sentence to be
When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
Troy
I'd consider something in a final paragraph that says "something like":
No action is required from you at this time.
Having an explicit "non-call to action" int its own paragraph may help folks feel more comfortable that they know what to expect and what they do/do not need to do.
Pat
On Thu, Mar 16, 2023 at 6:31 PM Patrick Riehecky via epel-devel < epel-devel@lists.fedoraproject.org> wrote:
On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote:
On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi kevin@scrye.com wrote:
On Thu, Mar 16, 2023 at 03:10:23PM -0700, Troy Dawson wrote:
This is what I have on my ticket. Respond soon (by tomorrow end of day) if you think I need changes.
Subject: Notice: <package> will be automatically retired from epel<major> when RHEL <major>.<minor> is released
Comment: Thank you for your work maintaining <package> in epel<major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from epel<major>.
That looks pretty good, but I might suggest adding something more explicit at the end:
Note that this issue is purely informational, you do not need to take any actions at this time.
But perhaps thats overkill. ;)
kevin
It's slight overkill, but you are correct, they might think they have to do something. I have changed the last sentence to be
When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
Troy
I'd consider something in a final paragraph that says "something like":
No action is required from you at this time.
Having an explicit "non-call to action" int its own paragraph may help folks feel more comfortable that they know what to expect and what they do/do not need to do.
Pat
Although I do agree having something in a separate paragraph would be best, my concern is that I don't know how they are creating these bugs. Doing a single paragraph, everything can fit between a pair of quotes, and you don't have to worry about special characters. That always works for any scripting or automation you are working with. Doing a separate paragraph might be easy, it might be a pain in the rear.
Troy
On Fri, 2023-03-17 at 06:22 -0700, Troy Dawson wrote:
On Thu, Mar 16, 2023 at 6:31 PM Patrick Riehecky via epel-devel epel-devel@lists.fedoraproject.org wrote:
On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote:
On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi kevin@scrye.com wrote:
On Thu, Mar 16, 2023 at 03:10:23PM -0700, Troy Dawson wrote:
This is what I have on my ticket. Respond soon (by tomorrow end of day) if you think I need changes.
Subject: Notice: <package> will be automatically retired from epel<major> when RHEL <major>.<minor> is released
Comment: Thank you for your work maintaining <package> in epel<major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from epel<major>.
That looks pretty good, but I might suggest adding something more explicit at the end:
Note that this issue is purely informational, you do not need to take any actions at this time.
But perhaps thats overkill. ;)
kevin
It's slight overkill, but you are correct, they might think they have to do something. I have changed the last sentence to be
When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
Troy
I'd consider something in a final paragraph that says "something like":
No action is required from you at this time.
Having an explicit "non-call to action" int its own paragraph may help folks feel more comfortable that they know what to expect and what they do/do not need to do.
Pat
Although I do agree having something in a separate paragraph would be best, my concern is that I don't know how they are creating these bugs. Doing a single paragraph, everything can fit between a pair of quotes, and you don't have to worry about special characters. That always works for any scripting or automation you are working with. Doing a separate paragraph might be easy, it might be a pain in the rear.
Troy
hmmmm, perhaps as sentence #1 then?
Pat
On Fri, Mar 17, 2023 at 6:48 AM Patrick Riehecky riehecky@fnal.gov wrote:
On Fri, 2023-03-17 at 06:22 -0700, Troy Dawson wrote:
On Thu, Mar 16, 2023 at 6:31 PM Patrick Riehecky via epel-devel epel-devel@lists.fedoraproject.org wrote:
On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote:
On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi kevin@scrye.com wrote:
On Thu, Mar 16, 2023 at 03:10:23PM -0700, Troy Dawson wrote:
This is what I have on my ticket. Respond soon (by tomorrow end of day) if you think I need changes.
Subject: Notice: <package> will be automatically retired from epel<major> when RHEL <major>.<minor> is released
Comment: Thank you for your work maintaining <package> in epel<major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from epel<major>.
That looks pretty good, but I might suggest adding something more explicit at the end:
Note that this issue is purely informational, you do not need to take any actions at this time.
But perhaps thats overkill. ;)
kevin
It's slight overkill, but you are correct, they might think they have to do something. I have changed the last sentence to be
When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
Troy
I'd consider something in a final paragraph that says "something like":
No action is required from you at this time.
Having an explicit "non-call to action" int its own paragraph may help folks feel more comfortable that they know what to expect and what they do/do not need to do.
Pat
Although I do agree having something in a separate paragraph would be best, my concern is that I don't know how they are creating these bugs. Doing a single paragraph, everything can fit between a pair of quotes, and you don't have to worry about special characters. That always works for any scripting or automation you are working with. Doing a separate paragraph might be easy, it might be a pain in the rear.
Troy
hmmmm, perhaps as sentence #1 then?
Pat
Good idea. I think if we put a modified version of Kevin's as the first sentance, we get.
Subject: Notice: <package> will be automatically retired from EPEL <major> when RHEL <major>.<minor> is released
Comment:
This issue is purely informational, you do not need to take any action. Thank you for your work maintaining <package> in EPEL <major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
On Fri, 2023-03-17 at 07:09 -0700, Troy Dawson wrote:
On Fri, Mar 17, 2023 at 6:48 AM Patrick Riehecky riehecky@fnal.gov wrote:
On Fri, 2023-03-17 at 06:22 -0700, Troy Dawson wrote:
On Thu, Mar 16, 2023 at 6:31 PM Patrick Riehecky via epel-devel epel-devel@lists.fedoraproject.org wrote:
On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote:
On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi kevin@scrye.com wrote:
On Thu, Mar 16, 2023 at 03:10:23PM -0700, Troy Dawson wrote: > > This is what I have on my ticket. Respond soon (by > tomorrow > end > of day) if > you think I need changes. > > Subject: > Notice: <package> will be automatically retired from > epel<major> > when RHEL > <major>.<minor> is released > > Comment: > Thank you for your work maintaining <package> in > epel<major>. > This package > has been considered important enough to Red Hat's > customers > that > Red Hat > has decided to promote it to be an official part of > RHEL. It > will be part > of RHEL <major>.<minor>. When that is released, EPEL > automation > will > remove <package> from epel<major>.
That looks pretty good, but I might suggest adding something more explicit at the end:
Note that this issue is purely informational, you do not need to take any actions at this time.
But perhaps thats overkill. ;)
kevin
It's slight overkill, but you are correct, they might think they have to do something. I have changed the last sentence to be
When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
Troy
I'd consider something in a final paragraph that says "something like":
No action is required from you at this time.
Having an explicit "non-call to action" int its own paragraph may help folks feel more comfortable that they know what to expect and what they do/do not need to do.
Pat
Although I do agree having something in a separate paragraph would be best, my concern is that I don't know how they are creating these bugs. Doing a single paragraph, everything can fit between a pair of quotes, and you don't have to worry about special characters. That always works for any scripting or automation you are working with. Doing a separate paragraph might be easy, it might be a pain in the rear.
Troy
hmmmm, perhaps as sentence #1 then?
Pat
Good idea. I think if we put a modified version of Kevin's as the first sentance, we get.
Subject: Notice: <package> will be automatically retired from EPEL <major> when RHEL <major>.<minor> is released Comment: This issue is purely informational, you do not need to take any action. Thank you for your work maintaining <package> in EPEL <major>. This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
That looks great to me!
On 17. 03. 23 0:08, Troy Dawson wrote:
This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL.
I know I am late to the party, so feel free to ignore me.
Is it OK to claim guessed reasons for new packages being added to RHEL?
I could think of other reasons as well. E.g. it's not important for customers but it's important for Red Hat. Or maybe it is a not-so-important dependency of something else.
What I am trying to say, wouldn't it be generally more accurate to simply state:
"Red Hat has decided to promote this package to be an official part of RHEL."
?
On Mon, Mar 20, 2023 at 5:37 AM Miro Hrončok mhroncok@redhat.com wrote:
On 17. 03. 23 0:08, Troy Dawson wrote:
This package has been considered important enough to Red Hat's customers that Red Hat has decided to promote it to be an official part of RHEL.
I know I am late to the party, so feel free to ignore me.
Is it OK to claim guessed reasons for new packages being added to RHEL?
I could think of other reasons as well. E.g. it's not important for customers but it's important for Red Hat. Or maybe it is a not-so-important dependency of something else.
Does Red Hat have any other motivation with RHEL other than a customer needing the functionality? Those other reasons are generally driven by someone needing it.
What I am trying to say, wouldn't it be generally more accurate to simply state:
"Red Hat has decided to promote this package to be an official part of RHEL."
?
This feels cold, which I think is why Troy was trying to add more color here.
On 20. 03. 23 12:20, Neal Gompa wrote:
I could think of other reasons as well. E.g. it's not important for customers but it's important for Red Hat. Or maybe it is a not-so-important dependency of something else.
Does Red Hat have any other motivation with RHEL other than a customer needing the functionality? Those other reasons are generally driven by someone needing it.
See e.g. https://bugzilla.redhat.com/2175213
On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok mhroncok@redhat.com wrote:
On 20. 03. 23 12:20, Neal Gompa wrote:
I could think of other reasons as well. E.g. it's not important for
customers
but it's important for Red Hat. Or maybe it is a not-so-important
dependency of
something else.
Does Red Hat have any other motivation with RHEL other than a customer needing the functionality? Those other reasons are generally driven by someone needing it.
See e.g. https://bugzilla.redhat.com/2175213
I see your point. It sometimes also happens when the EPEL package is a dependency of the important package, the customers aren't actually asking for the EPEL package. It looks like this change still hasn't been merged in so I'll see if I can get a change in. How about this?
Subject: Notice: <package> will be automatically retired from EPEL <major> when RHEL <major>.<minor> is released
Comment:
This issue is purely informational, you do not need to take any action. Thank you for your work maintaining <package> in EPEL <major>. Red Hat considers this package important enough to promote it to official RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson tdawson@redhat.com wrote:
I see your point. It sometimes also happens when the EPEL package is a dependency of the important package, the customers aren't actually asking for the EPEL package.
While I am sure that occasionally RH chooses to add a package to RHEL just because they think it is a good idea[0], I would expect that these days adding a package is mostly about customer requirements[1], even if it is an indirect requirement (even as a dependency of a dependency of a dependency).
I think your new wording is fine.
There will of course still be a few EPEL maintainers who will ask the question of "why now?", but those are likely to be few enough to handle on a case by case basis.
Thanks.
[0] Although I suspect that is not a common occurrence, as few organizations want to add to their ongoing support burden without something more formal than a whim.
[1] Formal requests, or easily anticipated requests based on industry technology directions, and/or from the various industry advisory boards.
I'm also late to the party with this feedback, but just in case it's not too late to include, can we include something about not updating the package further? Beyond just "you do not need to take any action", we should advise against making any changes at that point, as often the RHEL package will be exactly one release higher than the current EPEL package, and updating the EPEL package further (either release or version) will screw up the upgrade path.
On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson tdawson@redhat.com wrote:
On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok mhroncok@redhat.com wrote:
On 20. 03. 23 12:20, Neal Gompa wrote:
I could think of other reasons as well. E.g. it's not important for customers but it's important for Red Hat. Or maybe it is a not-so-important dependency of something else.
Does Red Hat have any other motivation with RHEL other than a customer needing the functionality? Those other reasons are generally driven by someone needing it.
See e.g. https://bugzilla.redhat.com/2175213
I see your point. It sometimes also happens when the EPEL package is a dependency of the important package, the customers aren't actually asking for the EPEL package. It looks like this change still hasn't been merged in so I'll see if I can get a change in. How about this?
Subject: Notice: <package> will be automatically retired from EPEL <major> when RHEL <major>.<minor> is released
Comment:
This issue is purely informational, you do not need to take any action. Thank you for your work maintaining <package> in EPEL <major>. Red Hat considers this package important enough to promote it to official RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
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... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
As a lurker of no note (feel free to ignore this rest of this post) I have resisted commenting since the thread started last fall. And I'm sure anything I post might come off as 'from the peanut gallery,' as it probably should. I'm going 'off-topic,' but I feel it's related. And I don't envy the EPEL maintainers, and their pains are something that most others will never understand well.
But given the EPEL2RHEL aspect, I figured this was as good of a thread to tangent from.
With the success of and major account buy-in of CentOS Stream, despite the negative press due to the messaging problems (not unlike Fedora 20 years ago), I'm really at the point I think Red Hat needs to step in, strategically, and address this in a greater way, by support EPEL maintainers more directly... possibly via Stream steering?
Not-so-differently than how Fedora Extras and Fedora Core were addressed within 5 years... but, I'm probably over simplifying things.
Because even today, like I started a dozen years ago, as a RHEL consumer, even for development systems**, I've pretty much continued to only use EPEL on RHEL via 'includepkgs=' in YUM, now DNF, previously updated by Puppet, now Ansible (and definitely after seeing Ansible itself upgraded to a newer version in EPEL years ago). And so with every new RHEL Update, I ensure any changes in those whitelists, including via Stream and Next, along with the Update Betas.
Maybe I'm ignorant, and some of this is already in progress or at least under consideration, but I think it would address a lot of things if CentOS Stream and EPEL steering was more integrated, if not during the Stream/RHEL9 lifecycle, but for 10. I haven't been able to get away from whitelists (includepkgs=) completely, not even with Modular (although that has helped immensely, like with Ansible itself too).
E.g., I for one, just have to 'shake my head' when I see all the various CentOS Stream 'repositories,' and have to ask myself... what if that effort by Red Hat engineers was put into assisting EPEL as well, even finally integrating them, via Modularity?
Just an observation, from the 'peanut gallery,' and I could be quite ignorant. That and I know nothing changes overnight, but the segmentation with EPEL doesn't have to be like CentOS was before Stream in 2019.
- bjs
**P.S. even though I still advocate everyone get a free RHEL Developer Entitlement, and argued for it to become free even before 2014, when I was on the inside of Red Hat (and love the recent move to 16 entitlements), so professionals and enthusiasts alike can run actual RHEL... I'm still loving the fact that Stream is now public, and we have standardized on Stream for container development.
E.g., although ultimately we do deliver for RHEL, we don't let UBI limit our considerations, and it becomes more of a 'develop what's possible' and then evaluate whether the deliverable can run on the UBI (possibly with library alternatives), or if a full entitlement is required (we just need stuff not in the UBI).
It doesn't look like they've done their merge yet, so I'll see if I can get your change in. How does this sound?
Subject: Notice: <package> will be automatically retired from EPEL <major> when RHEL <major>.<minor> is released
Comment:
This issue is purely informational, you do not need to take any action. Thank you for your work maintaining <package> in EPEL <major>. Red Hat considers this package important enough to promote it to official RHEL. It will be part of RHEL <major>.<minor>. Please do not update <package> in EPEL <major> so the RHEL version can have a higher version and release. When RHEL <major>.<minor> is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
On Tue, Mar 28, 2023 at 9:14 AM Carl George carl@redhat.com wrote:
I'm also late to the party with this feedback, but just in case it's not too late to include, can we include something about not updating the package further? Beyond just "you do not need to take any action", we should advise against making any changes at that point, as often the RHEL package will be exactly one release higher than the current EPEL package, and updating the EPEL package further (either release or version) will screw up the upgrade path.
On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson tdawson@redhat.com wrote:
On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok mhroncok@redhat.com
wrote:
On 20. 03. 23 12:20, Neal Gompa wrote:
I could think of other reasons as well. E.g. it's not important for
customers
but it's important for Red Hat. Or maybe it is a not-so-important
dependency of
something else.
Does Red Hat have any other motivation with RHEL other than a customer needing the functionality? Those other reasons are generally driven by someone needing it.
See e.g. https://bugzilla.redhat.com/2175213
I see your point. It sometimes also happens when the EPEL package is a
dependency of the important package, the customers aren't actually asking for the EPEL package.
It looks like this change still hasn't been merged in so I'll see if I
can get a change in. How about this?
Subject: Notice: <package> will be automatically retired from EPEL <major> when
RHEL <major>.<minor> is released
Comment:
This issue is purely informational, you do not need to take any action.
Thank you for your work maintaining <package> in EPEL <major>. Red Hat considers this package important enough to promote it to official RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
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...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
-- 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... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
That sounds great, thanks.
On Thu, Mar 30, 2023, 8:28 AM Troy Dawson tdawson@redhat.com wrote:
It doesn't look like they've done their merge yet, so I'll see if I can get your change in. How does this sound?
Subject: Notice: <package> will be automatically retired from EPEL <major> when RHEL <major>.<minor> is released
Comment:
This issue is purely informational, you do not need to take any action. Thank you for your work maintaining <package> in EPEL <major>. Red Hat considers this package important enough to promote it to official RHEL. It will be part of RHEL <major>.<minor>. Please do not update <package> in EPEL <major> so the RHEL version can have a higher version and release. When RHEL <major>.<minor> is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
On Tue, Mar 28, 2023 at 9:14 AM Carl George carl@redhat.com wrote:
I'm also late to the party with this feedback, but just in case it's not too late to include, can we include something about not updating the package further? Beyond just "you do not need to take any action", we should advise against making any changes at that point, as often the RHEL package will be exactly one release higher than the current EPEL package, and updating the EPEL package further (either release or version) will screw up the upgrade path.
On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson tdawson@redhat.com wrote:
On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok mhroncok@redhat.com
wrote:
On 20. 03. 23 12:20, Neal Gompa wrote:
I could think of other reasons as well. E.g. it's not important for
customers
but it's important for Red Hat. Or maybe it is a not-so-important
dependency of
something else.
Does Red Hat have any other motivation with RHEL other than a
customer
needing the functionality? Those other reasons are generally driven
by
someone needing it.
See e.g. https://bugzilla.redhat.com/2175213
I see your point. It sometimes also happens when the EPEL package is a
dependency of the important package, the customers aren't actually asking for the EPEL package.
It looks like this change still hasn't been merged in so I'll see if I
can get a change in. How about this?
Subject: Notice: <package> will be automatically retired from EPEL <major> when
RHEL <major>.<minor> is released
Comment:
This issue is purely informational, you do not need to take any
action. Thank you for your work maintaining <package> in EPEL <major>. Red Hat considers this package important enough to promote it to official RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
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...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
-- 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... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The change has now been implemented. We'll have to wait for a package to be affected before we see it, but I *think* it should look like what we have there.
Note: It is still doing everything as separate steps. So package maintainers will still get several emails. I got to see the code, and I think we can trim a couple of the steps off, which will trim a couple of the emails off. But I wanted to get this change through first, because it's a straightforward wording change and shouldn't break anything.
Troy
On Fri, Mar 31, 2023 at 8:00 AM Carl George carl@redhat.com wrote:
That sounds great, thanks.
On Thu, Mar 30, 2023, 8:28 AM Troy Dawson tdawson@redhat.com wrote:
It doesn't look like they've done their merge yet, so I'll see if I can get your change in. How does this sound?
Subject: Notice: <package> will be automatically retired from EPEL <major> when RHEL <major>.<minor> is released
Comment:
This issue is purely informational, you do not need to take any action. Thank you for your work maintaining <package> in EPEL <major>. Red Hat considers this package important enough to promote it to official RHEL. It will be part of RHEL <major>.<minor>. Please do not update <package> in EPEL <major> so the RHEL version can have a higher version and release. When RHEL <major>.<minor> is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
On Tue, Mar 28, 2023 at 9:14 AM Carl George carl@redhat.com wrote:
I'm also late to the party with this feedback, but just in case it's not too late to include, can we include something about not updating the package further? Beyond just "you do not need to take any action", we should advise against making any changes at that point, as often the RHEL package will be exactly one release higher than the current EPEL package, and updating the EPEL package further (either release or version) will screw up the upgrade path.
On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson tdawson@redhat.com wrote:
On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok mhroncok@redhat.com
wrote:
On 20. 03. 23 12:20, Neal Gompa wrote:
> I could think of other reasons as well. E.g. it's not important
for customers
> but it's important for Red Hat. Or maybe it is a not-so-important
dependency of
> something else. > Does Red Hat have any other motivation with RHEL other than a
customer
needing the functionality? Those other reasons are generally driven
by
someone needing it.
See e.g. https://bugzilla.redhat.com/2175213
I see your point. It sometimes also happens when the EPEL package is
a dependency of the important package, the customers aren't actually asking for the EPEL package.
It looks like this change still hasn't been merged in so I'll see if I
can get a change in. How about this?
Subject: Notice: <package> will be automatically retired from EPEL <major> when
RHEL <major>.<minor> is released
Comment:
This issue is purely informational, you do not need to take any
action. Thank you for your work maintaining <package> in EPEL <major>. Red Hat considers this package important enough to promote it to official RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
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...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
-- 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... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
epel-devel@lists.fedoraproject.org
-
Bryan Smith -
Carl George -
Davide Cavalca -
Dominik 'Rathann' Mierzejewski -
Gary Buhrmaster -
Kevin Fenzi -
Maxwell G -
Maxwell G -
Miro Hrončok -
Neal Gompa -
Patrick Riehecky -
Troy Dawson