[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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 wrote: > That sounds great, thanks. > > On Thu, Mar 30, 2023, 8:28 AM Troy Dawson 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: will be automatically retired from EPEL when >> RHEL . is released >> >> Comment: >> >> This issue is purely informational, you do not need to take any action. >> Thank you for your work maintaining in EPEL . Red Hat >> considers this package important enough to promote it to official RHEL. It >> will be part of RHEL .. Please do not update in >> EPEL so the RHEL version can have a higher version and release. >> When RHEL . is released, EPEL automation will remove >> from EPEL and close this bug. >> >> >> On Tue, Mar 28, 2023 at 9:14 AM Carl George 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 wrote: >>> > >>> > On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok >>> 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: will be automatically retired from EPEL when >>> RHEL . is released >>> > >>> > Comment: >>> > >>> > This issue is purely informational, you do not need to take any >>> action. Thank you for your work maintaining in EPEL . >>> Red Hat considers this package important enough to promote it to official >>> RHEL. It will be part of RHEL .. When that is released, >>> EPEL automation will remove from EPEL and close this bug. >>> > >>> > ___ >>> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org >>> > To unsubscribe send an email to >>> epel-devel-le...@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.org >>> > 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-le...@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.org >>> 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-le...@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.org >> Do not reply to spam, report it: >>
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
That sounds great, thanks. On Thu, Mar 30, 2023, 8:28 AM Troy Dawson 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: will be automatically retired from EPEL when > RHEL . is released > > Comment: > > This issue is purely informational, you do not need to take any action. > Thank you for your work maintaining in EPEL . Red Hat > considers this package important enough to promote it to official RHEL. It > will be part of RHEL .. Please do not update in > EPEL so the RHEL version can have a higher version and release. > When RHEL . is released, EPEL automation will remove > from EPEL and close this bug. > > > On Tue, Mar 28, 2023 at 9:14 AM Carl George 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 wrote: >> > >> > On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok >> 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: will be automatically retired from EPEL when >> RHEL . is released >> > >> > Comment: >> > >> > This issue is purely informational, you do not need to take any >> action. Thank you for your work maintaining in EPEL . >> Red Hat considers this package important enough to promote it to official >> RHEL. It will be part of RHEL .. When that is released, >> EPEL automation will remove from EPEL and close this bug. >> > >> > ___ >> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org >> > To unsubscribe send an email to >> epel-devel-le...@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.org >> > 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-le...@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.org >> 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-le...@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.org > 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-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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: will be automatically retired from EPEL when RHEL . is released Comment: This issue is purely informational, you do not need to take any action. Thank you for your work maintaining in EPEL . Red Hat considers this package important enough to promote it to official RHEL. It will be part of RHEL .. Please do not update in EPEL so the RHEL version can have a higher version and release. When RHEL . is released, EPEL automation will remove from EPEL and close this bug. On Tue, Mar 28, 2023 at 9:14 AM Carl George 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 wrote: > > > > On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok > 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: will be automatically retired from EPEL when > RHEL . is released > > > > Comment: > > > > This issue is purely informational, you do not need to take any action. > Thank you for your work maintaining in EPEL . Red Hat > considers this package important enough to promote it to official RHEL. It > will be part of RHEL .. When that is released, EPEL > automation will remove from EPEL and close this bug. > > > > ___ > > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > > To unsubscribe send an email to epel-devel-le...@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.org > > 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-le...@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.org > 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-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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 wrote: > > On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok 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: will be automatically retired from EPEL when RHEL > . is released > > Comment: > > This issue is purely informational, you do not need to take any action. > Thank you for your work maintaining in EPEL . Red Hat > considers this package important enough to promote it to official RHEL. It > will be part of RHEL .. When that is released, EPEL automation > will remove from EPEL and close this bug. > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@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.org > 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-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson 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. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok 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: will be automatically retired from EPEL when RHEL . is released Comment: This issue is purely informational, you do not need to take any action. Thank you for your work maintaining in EPEL . Red Hat considers this package important enough to promote it to official RHEL. It will be part of RHEL .. When that is released, EPEL automation will remove from EPEL and close this bug. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Mon, Mar 20, 2023 at 5:37 AM Miro Hrončok 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. -- 真実はいつも一つ！/ Always, there's only one truth! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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." ? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Fri, 2023-03-17 at 07:09 -0700, Troy Dawson wrote: > On Fri, Mar 17, 2023 at 6:48 AM Patrick Riehecky > 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 > > > wrote: > > > > On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote: > > > > > > > > > > > > > > > On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi > > > > > 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: will be automatically retired from > > > > > > > epel > > > > > > > when RHEL > > > > > > > . is released > > > > > > > > > > > > > > Comment: > > > > > > > Thank you for your work maintaining in > > > > > > > epel. > > > > > > > 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 .. When that is released, EPEL > > > > > > > automation > > > > > > > will > > > > > > > remove from epel. > > > > > > > > > > > > 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 > > > > > from > > > > > EPEL 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 > > > > > > h, 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: will be automatically retired from EPEL > when RHEL . is released > Comment: > This issue is purely informational, you do not need to take any > action. Thank you for your work maintaining in EPEL > . 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 .. > When that is released, EPEL automation will remove from > EPEL and close this bug. That looks great to me! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Fri, Mar 17, 2023 at 6:48 AM Patrick Riehecky 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 > > wrote: > > > On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote: > > > > > > > > > > > > On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi > > > > 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: will be automatically retired from > > > > > > epel > > > > > > when RHEL > > > > > > . is released > > > > > > > > > > > > Comment: > > > > > > Thank you for your work maintaining in > > > > > > epel. > > > > > > 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 .. When that is released, EPEL > > > > > > automation > > > > > > will > > > > > > remove from epel. > > > > > > > > > > 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 from > > > > EPEL 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 > > > h, 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: will be automatically retired from EPEL when RHEL . is released Comment: This issue is purely informational, you do not need to take any action. Thank you for your work maintaining in EPEL . 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 .. When that is released, EPEL automation will remove from EPEL and close this bug. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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 > wrote: > > On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote: > > > > > > > > > On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi > > > 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: will be automatically retired from > > > > > epel > > > > > when RHEL > > > > > . is released > > > > > > > > > > Comment: > > > > > Thank you for your work maintaining in > > > > > epel. > > > > > 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 .. When that is released, EPEL > > > > > automation > > > > > will > > > > > remove from epel. > > > > > > > > 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 from > > > EPEL 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 h, perhaps as sentence #1 then? Pat ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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 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: will be automatically retired from epel > > > > when RHEL > > > > . is released > > > > > > > > Comment: > > > > Thank you for your work maintaining in epel. > > > > 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 .. When that is released, EPEL automation > > > > will > > > > remove from epel. > > > > > > 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 from > > EPEL 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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote: > > > On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi 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: will be automatically retired from epel > > > when RHEL > > > . is released > > > > > > Comment: > > > Thank you for your work maintaining in epel. > > > 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 .. When that is released, EPEL automation > > > will > > > remove from epel. > > > > 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 from > EPEL 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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Thu, Mar 16, 2023 at 7:08 PM Troy Dawson wrote: > > On Thu, Mar 16, 2023 at 3:35 PM Neal Gompa wrote: >> >> On Thu, Mar 16, 2023 at 6:10 PM Troy Dawson wrote: >> > >> > On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson wrote: >> >> >> >> >> >> >> >> On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster >> >> wrote: >> >>> >> >>> On Mon, Sep 5, 2022 at 9:33 AM 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. >> >>> >> >>> 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: will be automatically retired from epel when RHEL >> > . is released >> > >> > Comment: >> > Thank you for your work maintaining in epel. 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 .. When that is released, EPEL automation >> > will remove from epel. >> > >> >> That is pretty well worded, though you can just use "EPEL " >> instead of "epel". >> > > 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: will be automatically retired from EPEL when RHEL > . is released > > Comment: > > Thank you for your work maintaining in EPEL . 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 .. When that is released, EPEL automation will remove > from EPEL and close this bug. > That looks great! -- 真実はいつも一つ！/ Always, there's only one truth! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Thu, Mar 16, 2023 at 3:35 PM Neal Gompa wrote: > On Thu, Mar 16, 2023 at 6:10 PM Troy Dawson wrote: > > > > On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson wrote: > >> > >> > >> > >> On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster < > gary.buhrmas...@gmail.com> wrote: > >>> > >>> On Mon, Sep 5, 2022 at 9:33 AM 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. > >>> > >>> 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: will be automatically retired from epel when > RHEL . is released > > > > Comment: > > Thank you for your work maintaining in epel. 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 .. When that is released, EPEL automation > will remove from epel. > > > > That is pretty well worded, though you can just use "EPEL " > instead of "epel". > > 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: will be automatically retired from EPEL when RHEL . is released Comment: Thank you for your work maintaining in EPEL . 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 .. When that is released, EPEL automation will remove from EPEL and close this bug. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi 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: will be automatically retired from epel when > RHEL > > . is released > > > > Comment: > > Thank you for your work maintaining in epel. 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 .. When that is released, EPEL automation will > > remove from epel. > > 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 from EPEL and close this bug. Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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: will be automatically retired from epel when RHEL > . is released > > Comment: > Thank you for your work maintaining in epel. 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 .. When that is released, EPEL automation will > remove from epel. 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 signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Thu, Mar 16, 2023 at 6:10 PM Troy Dawson wrote: > > On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson wrote: >> >> >> >> On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster >> wrote: >>> >>> On Mon, Sep 5, 2022 at 9:33 AM 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. >>> >>> 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: will be automatically retired from epel when RHEL > . is released > > Comment: > Thank you for your work maintaining in epel. 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 .. When that is released, EPEL automation will remove > from epel. > That is pretty well worded, though you can just use "EPEL " instead of "epel". -- 真実はいつも一つ！/ Always, there's only one truth! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson wrote: > > > On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster > wrote: > >> On Mon, Sep 5, 2022 at 9:33 AM 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. >> >> 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: will be automatically retired from epel when RHEL . is released Comment: Thank you for your work maintaining in epel. 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 .. When that is released, EPEL automation will remove from epel. Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Mon, Feb 20, 2023 at 6:45 AM Neal Gompa wrote: > On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson wrote: > > > > On Sun, Feb 19, 2023 at 4:34 PM Maxwell G 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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson wrote: > > On Sun, Feb 19, 2023 at 4:34 PM Maxwell G 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! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Sun, Feb 19, 2023 at 4:34 PM Maxwell G 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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster wrote: > On Mon, Sep 5, 2022 at 9:33 AM 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. > > 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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On Mon, Sep 5, 2022 at 9:33 AM 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. 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" ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
On 01. 11. 22 15:07, Troy Dawson wrote: Does this sound good to people? Yes please. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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 [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1998160 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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: > > > > 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. > > 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 -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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: > > 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. I really like this approach... :) kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?
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 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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@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.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
