[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

2023-03-17 Thread Patrick Riehecky via epel-devel
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?

2023-03-17 Thread Patrick Riehecky via epel-devel
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?

2023-03-16 Thread Patrick Riehecky via epel-devel
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: Thoughts: epel-release auto-enable crb repo

2022-06-17 Thread Patrick Riehecky via epel-devel
On Fri, 2022-06-17 at 06:33 -0700, Troy Dawson wrote:
> 
> 
> On Thu, Jun 16, 2022 at 10:22 PM Carl George  wrote:
> > On Wed, Jun 15, 2022 at 5:12 PM Troy Dawson 
> > wrote:
> > > 
> > > I'm totally top-posting, and I apologize for that.
> > > 
> > > For right now, I'm going to put my enable-crb script in epel-
> > > release, but not automatically run it in a %post script or
> > > anything.
> > > The debate about putting it in a post script, or a separate
> > > package, can go on independently of the script.
> > > 
> > > This does a few things.
> > > - give people a single, easy to remember way to enable crb
> > > -- Right now if you install anything but RHEL you might remember
> > > "dnf install epel-release" but then you forget what the dnf
> > > command is to enable a repo, and you might forget if it's crb or
> > > powertools.
> > > -- It will make scripting easier because you just have one
> > > command that will work across all RHEL compatibles.
> > > 
> > > - gives the script a chance to find all the corner cases
> > > -- It's worked on everything I've tried thus far, but I'm sure
> > > there are some corner cases or two where the script doesn't work.
> > > 
> > > I was thinking of it being
> > >    /usr/bin/enable-crb
> > >    /usr/bin/epel-enable-crb (a link to enable-crb)
> > > 
> > > Thoughts?
> > > 
> > > Troy
> > > 
> > I think it would be nice to be able to both enable and disable from
> > the same script.  This would come in handy when you are looking for
> > things that don't install when crb is disabled.  I don't see
> > anything
> > else in Fedora or RHEL that ships a command with the name crb, so
> > how
> > about that?
> > 
> > crb enable
> > crb disable
> > 
> 
> 
> That shouldn't be too hard.  I'm going to give it a shot.
> If that takes too long, I'll just push what I currently have for now.
> 
> I notice that you said crb-enable, crb-disable.
> Do you like having the name first, or the function first?
> 
> enable-crb vs crb-enable  ?
> 
> either way I want to have it by itself, as well as starting with epel
> 
> epel-enable-crb  vs epel-crb-enable  ?
> 
> Troy
> 
> 

I'd be tempted to go with something like:

epel-crb-repo $action

This way any extra ideas for actions can be added easily later on. 
Perhaps a "check" or "status" to see if CRB is enabled/disabled/not-
what-the-os-ships.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure


[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo

2022-06-06 Thread Patrick Riehecky via epel-devel
I realize this is a bit of a pipe dream, but is there "some way" to
ship a repo file from EPEL that points to the crb repo(s)?  Folks not
wanting it could block the package/not install weak deps.  Getting the
right repos is a bit tricky but I figured I'd voice the idea...


Pat

On Sat, 2022-06-04 at 13:52 -0700, Troy Dawson wrote:
> When I first created the EPEL issue to auto-enable crb repo[1] I was
> only thinking of CAN we do it.  I wasn't thinking SHOULD we do it.
> We've come to the point that we actually can do it.  But before we go
> down that road, I wanted to take a step back and ask, should we do
> it.
> 
> The more I think about it, the more I think we shouldn't auto-enable
> the crb repo for epel8 and epel9.  Here are my reasons why.
> 
> 1 - The need to auto-enable crb isn't as big as it was before.
> At the time that I wrote that issue, I was getting quite alot of bugs
> / pings / emails about  epel packages not being installable.  I think
> on average about 2 a month.
> With epel being in fedora-docs, and with Carl's re-write of how to
> enable epel, that number has dropped significantly.  I possibly still
> average one a month, but that's an average over a year, with most of
> them being last year.
> In short, I believe the documentation is better, and easier to find,
> allowing people to enable crb on their own, without automation.
> 
> 2 - crb isn't an epel repo
> We really shouldn't be messing with other repo's that we, epel, don't
> own.
> 
> 3 - We are taking the choice away from users
> After I stopped and thought about it, there are plenty of scenarios
> where people want epel for just one or two packages, which do not
> require crb.
> 
> 4 - All the many small side cases.
> auto-enabling crb will have bugs.  RHEL and it's clones are in too
> many odd places for us to not hit some odd use cases we didn't
> expect.  We'd have to keep fixing the scripts.
> 
> I could go into more explanation on each of those things, but in the
> end, I've talked myself out of wanting to auto-enable crb for epel8
> and epel9.
> But I also wanted to get others' thoughts before I close the bug and
> pull request.
> 
> What do others think?
> 
> Troy
> 
> 
> [1] - https://pagure.io/epel/issue/128
> ___
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-2Dconduct_&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza&s=d0B-lUzeMAZ-0S04uVby7ub-ORVZmAB6b5jp1yJRsuE&e=
>  
> List Guidelines:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza&s=KUWCI2iU_-iPDDRDPyScLagKSycsfAiarhiTHIQYPR0&e=
>  
> List Archives:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_epel-2Ddevel-40lists.fedoraproject.org&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza&s=P7pankG6ADB2aNPcSpD1QIXMv1ATMhIvP4ovYevs5rU&e=
>  
> Do not reply to spam on the list, report it:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Dinfrastructure&d=DwIGaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE&m=46SEe1P-KfUUtAfirZYHn5ATxfTJ_Q6spfT4LcmtWv44xjf03U3-eLIQq8CkFvza&s=_cTkF9KBrWUy7DX9w20wQNnBshQg2EbgcQKLRhis6qY&e=
>  

___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure