Plea: Take a moment before you branch everything for EPEL 9

[Miro Hrončok]

Hello EPEL packagers.

I get it that you want as much as possible packages available in EPEL 9, but 
before you blindly branch all the dependencies of the packages you care about, 
could you maybe take a step back and consider for a few minutes if all the 
dependencies actually make sense?

The dependency might be a leftover from long time ago and might not be actually 
needed. Get rid of it in Fedora instead of keeping it that way on EPEL 9.

The dependency might be optional (e.g. it is only BuildRequired to test 
integration with that thing). Do you really need to add a package to EPEL 9 
just because your package tests that it can interact with it if it is present?

The package might be deprecated in Fedora and used just because nobody got the 
time to do a trivial removal of the dependency. Try removing it or poke the 
Fedora maintainer to do it, before you blindly include that tech debt to EPEL 
9. (E.g. I'd be happy to help you remove any python-mock or python-nose 
dependency.)

I realize that analyzing the dependencies is tedious and boring. But please do 
us all a favor and invest couple minutes of your time *before* you open that 
bugzilla EPEL 9 request or branch that package. If you are not able to donate 
couple minutes of your time to the package now, will you be able to take care 
of the dozens packages you've just imported in the next ten years?

Thanks for listening, I'll show myself out.

[Felix Schwarz]

+1

I'd like to highlight python3-nose and python3-mock. If your package depends on 
one of these you should really fix your package and/or code upstream.

Felix

[Stephen John Smoogen]

On Thu, 17 Feb 2022 at 07:11, Miro Hrončok  wrote:
> Hello EPEL packagers.
>
> I get it that you want as much as possible packages available in EPEL 9,
> but
> before you blindly branch all the dependencies of the packages you care
> about,
> could you maybe take a step back and consider for a few minutes if all the
> dependencies actually make sense?
>
> The dependency might be a leftover from long time ago and might not be
> actually
> needed. Get rid of it in Fedora instead of keeping it that way on EPEL 9.
>
> The dependency might be optional (e.g. it is only BuildRequired to test
> integration with that thing). Do you really need to add a package to EPEL
> 9
> just because your package tests that it can interact with it if it is
> present?

The working assumption has been that the Fedora package is already cleaned
up and dependencies are there because the main packager thought they were
needed. I and other EPEL packagers have spent enough time 'cleaning up' a
package and then getting yelled at by the main packager that I broke
something important and they wanted me to not touch their package anymore.
[Heck we have caused a couple of people to quit Fedora completely over the
years because of this.]

Due to that, we usually err on if the upstream SIG or packager has put the
package dependency in, they know what they are doing and we are just going
to cause another round of 'EPEL is breaking our distro' threads if we do
otherwise. Heck just getting the package into EPEL from many groups is on
the promise that WE DON'T MAKE CHANGES to their spec file. So while I
understand where you are coming from, we are also not in a position to know
when we can do this and when we can't.

Finally. There is NO PROMISE that we are putting these packages in for 10
years. We have said this over and over again for the last 4 years, but it
comes up like a bad penny. Packages that are not useful and are not to be
maintained CAN and WILL be retired. We just need guidance versus pissed off
emails.
> The package might be deprecated in Fedora and used just because nobody got
> the
> time to do a trivial removal of the dependency. Try removing it or poke
> the
> Fedora maintainer to do it, before you blindly include that tech debt to
> EPEL
> 9. (E.g. I'd be happy to help you remove any python-mock or python-nose
> dependency.)
>
> I realize that analyzing the dependencies is tedious and boring. But
> please do
> us all a favor and invest couple minutes of your time *before* you open
> that
> bugzilla EPEL 9 request or branch that package. If you are not able to
> donate
> couple minutes of your time to the package now, will you be able to take
> care
> of the dozens packages you've just imported in the next ten years?
>
> Thanks for listening, I'll show myself out.
>
> --
> Miro Hrončok
> --
> Phone: [phone]
> IRC: mhroncok
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

[Stephen John Smoogen]

And of course sending emails like this do not help make things better for
either party. My apologies and I am going to cut back on sending email
without a 24 hour "Did you really want to send this timeout?"

On Thu, 17 Feb 2022 at 07:52, Stephen John Smoogen  wrote:
> Finally. There is NO PROMISE that we are putting these packages in for 10
> years. We have said this over and over again for the last 4 years, but it
> comes up like a bad penny. Packages that are not useful and are not to be
> maintained CAN and WILL be retired. We just need guidance versus pissed off
> emails.

[Miro Hrončok]

On 17. 02. 22 13:52, Stephen John Smoogen wrote:
> On Thu, 17 Feb 2022 at 07:11, Miro Hrončok <[e-mail] 
> > wrote:
> Hello EPEL packagers.
>
> I get it that you want as much as possible packages available in EPEL 9, but
> before you blindly branch all the dependencies of the packages you care about,
> could you maybe take a step back and consider for a few minutes if all the
> dependencies actually make sense?
>
> The dependency might be a leftover from long time ago and might not be
> actually
> needed. Get rid of it in Fedora instead of keeping it that way on EPEL 9.
>
> The dependency might be optional (e.g. it is only BuildRequired to test
> integration with that thing). Do you really need to add a package to EPEL 9
> just because your package tests that it can interact with it if it is present?
>
>
> The working assumption has been that the Fedora package is already cleaned up 
> and dependencies are there because the main packager thought they were needed.

That is however not the reality. In reality, a Fedora package has an unknown 
quality. It has historical baggage. The miantainer who added that dependency 
has left 12 years ago. In my opinion, the EPEL packager should inspect the 
package they want to branch and improve both Fedora and EPEL by getting it in a 
better shape. I see now that you've been yelled at in the past for doing that 
(that is a new information to me) so I understand why you would not want to do 
that again. See my next replies.
> I and other EPEL packagers have spent enough time 'cleaning up' a package and 
> then getting yelled at by the main packager that I broke something important 
> and they wanted me to not touch their package anymore. [Heck we have caused a 
> couple of people to quit Fedora completely over the years because of this.]

In the past we didn't have pull requests. I don't propose the EPEL maintainers 
go and change Fedora packages freely. I propose they suggest changes. And if 
the Fedora maintainers are not interested, they can just make those changes in 
EPEL branches only.

Furthermore, some changes are not suitable for Fedora but might be suitable for 
EPEL. IMHO we must understand that some maintainers might not want an %if-%rhel 
conditional to be pushed to a Fedora branch by the EPEL maintainer. That 
however does not mean the change cannot be done in EPEL only to avoid an 
unwanted dependency.

See for example this PR:

https://src.fedoraproject.org/rpms/python-django/pull-request/24

The EPEL maintainer suggested to drop dependencies that are not needed.
It turned out that it would skip a bunch of tests that we don't want to skip in 
Fedora.

Had the EPEL maintainer pushed this change directly, the Fedora maintainers 
would be perfectly OK to tell them this was not OK.
Instead, they used a pull request, received feedback and only done the changes 
in EPEL. Everybody is happy.
> Due to that, we usually err on if the upstream SIG or packager has put the 
> package dependency in, they know what they are doing and we are just going to 
> cause another round of 'EPEL is breaking our distro' threads if we do 
> otherwise. Heck just getting the package into EPEL from many groups is on the 
> promise that WE DON'T MAKE CHANGES to their spec file. So while I understand 
> where you are coming from, we are also not in a position to know when we can do 
> this and when we can't.

My opinion? It is always OK to suggest changes. It is never OK to push 
nontrivial changes without giving Fedora maintainers chance for a review 
(unless we enjoy being yelled at).
> Finally. There is NO PROMISE that we are putting these packages in for 10 
> years. We have said this over and over again for the last 4 years, but it comes 
> up like a bad penny. Packages that are not useful and are not to be maintained 
> CAN and WILL be retired. We just need guidance versus pissed off emails.

But packages that are not useful are being imported, built and left to rot. Why 
bother retiring them later if we don't bother not adding them in the first 
place? In other words, retiring the packages requires somebody to do exactly 
what I am asking here: Taking a moment to reconsider a dependency. I'm just 
asking everybody to do it now because I know from experience, that it will 
probably not happen later. The packages will be in EPEL forever, despite not 
being useful.
> The package might be deprecated in Fedora and used just because nobody got the
> time to do a trivial removal of the dependency. Try removing it or poke the
> Fedora maintainer to do it, before you blindly include that tech debt to EPEL
> 9. (E.g. I'd be happy to help you remove any python-mock or python-nose
> dependency.)
>
> I realize that analyzing the dependencies is tedious and boring. But please do
> us all a favor and invest couple minutes of your time *before* you open that
> bugzilla EPEL 9 request or branch that package. If you are not able to donate
> couple minutes of your time to the package now, will you be able to take care
> of the dozens packages you've just imported in the next ten years?
>
> Thanks for listening, I'll show myself out.

[Troy Dawson]

On Thu, Feb 17, 2022 at 6:03 AM Miro Hrončok  wrote:
> On 17. 02. 22 13:52, Stephen John Smoogen wrote:
> > On Thu, 17 Feb 2022 at 07:11, Miro Hrončok <[e-mail]
> > > wrote:
> > Hello EPEL packagers.
> >
> > I get it that you want as much as possible packages available in
>
> EPEL 9, but
> > before you blindly branch all the dependencies of the packages you
>
> care about,
> > could you maybe take a step back and consider for a few minutes if
>
> all the
> > dependencies actually make sense?
> >
> > The dependency might be a leftover from long time ago and might not
>
> be
> > actually
> > needed. Get rid of it in Fedora instead of keeping it that way on
>
> EPEL 9.
> > The dependency might be optional (e.g. it is only BuildRequired to
>
> test
> > integration with that thing). Do you really need to add a package to
>
> EPEL 9
> > just because your package tests that it can interact with it if it
>
> is present?
> > The working assumption has been that the Fedora package is already
>
> cleaned up
> > and dependencies are there because the main packager thought they were
>
> needed.
>
> That is however not the reality. In reality, a Fedora package has an
> unknown
> quality. It has historical baggage. The miantainer who added that
> dependency
> has left 12 years ago. In my opinion, the EPEL packager should inspect the
> package they want to branch and improve both Fedora and EPEL by getting it
> in a
> better shape. I see now that you've been yelled at in the past for doing
> that
> (that is a new information to me) so I understand why you would not want
> to do
> that again. See my next replies.
> > I and other EPEL packagers have spent enough time 'cleaning up' a
>
> package and
> > then getting yelled at by the main packager that I broke something
>
> important
> > and they wanted me to not touch their package anymore. [Heck we have
>
> caused a
> > couple of people to quit Fedora completely over the years because of
>
> this.]
>
> In the past we didn't have pull requests. I don't propose the EPEL
> maintainers
> go and change Fedora packages freely. I propose they suggest changes. And
> if
> the Fedora maintainers are not interested, they can just make those
> changes in
> EPEL branches only.
>
> Furthermore, some changes are not suitable for Fedora but might be
> suitable for
> EPEL. IMHO we must understand that some maintainers might not want an
> %if-%rhel
> conditional to be pushed to a Fedora branch by the EPEL maintainer. That
> however does not mean the change cannot be done in EPEL only to avoid an
> unwanted dependency.
>
> See for example this PR:
>
> https://src.fedoraproject.org/rpms/python-django/pull-request/24
>
> The EPEL maintainer suggested to drop dependencies that are not needed.
> It turned out that it would skip a bunch of tests that we don't want to
> skip in
> Fedora.
>
> Had the EPEL maintainer pushed this change directly, the Fedora
> maintainers
> would be perfectly OK to tell them this was not OK.
> Instead, they used a pull request, received feedback and only done the
> changes
> in EPEL. Everybody is happy.
> > Due to that, we usually err on if the upstream SIG or packager has put
>
> the
> > package dependency in, they know what they are doing and we are just
>
> going to
> > cause another round of 'EPEL is breaking our distro' threads if we do
> > otherwise. Heck just getting the package into EPEL from many groups is
>
> on the
> > promise that WE DON'T MAKE CHANGES to their spec file. So while I
>
> understand
> > where you are coming from, we are also not in a position to know when we
>
> can do
> > this and when we can't.
>
> My opinion? It is always OK to suggest changes. It is never OK to push
> nontrivial changes without giving Fedora maintainers chance for a review
> (unless we enjoy being yelled at).
> > Finally. There is NO PROMISE that we are putting these packages in for
>
> 10
> > years. We have said this over and over again for the last 4 years, but
>
> it comes
> > up like a bad penny. Packages that are not useful and are not to be
>
> maintained
> > CAN and WILL be retired. We just need guidance versus pissed off emails.
>
> But packages that are not useful are being imported, built and left to
> rot. Why
> bother retiring them later if we don't bother not adding them in the first
> place? In other words, retiring the packages requires somebody to do
> exactly
> what I am asking here: Taking a moment to reconsider a dependency. I'm
> just
> asking everybody to do it now because I know from experience, that it will
> probably not happen later. The packages will be in EPEL forever, despite
> not
> being useful.
> > The package might be deprecated in Fedora and used just because
>
> nobody got the
> > time to do a trivial removal of the dependency. Try removing it or
>
> poke the
> > Fedora maintainer to do it, before you blindly include that tech
>
> debt to EPEL
> > 9. (E.g. I'd be happy to help you remove any python-mock or
>
> python-nose
> > dependency.)
> >
> > I realize that analyzing the dependencies is tedious and boring. But
>
> please do
> > us all a favor and invest couple minutes of your time *before* you
>
> open that
> > bugzilla EPEL 9 request or branch that package. If you are not able
>
> to donate
> > couple minutes of your time to the package now, will you be able to
>
> take care
> > of the dozens packages you've just imported in the next ten years?
> >
> > Thanks for listening, I'll show myself out.

Miro, thank you for bringing this up.
And Smooge, thank you for bringing up some of the pitfalls.

I totally agree with both of you actually.
Each new release of EPEL gives us a chance to go through all the packages
we maintain and see if we really need all those dependencies we're pulling
in.
During this time I've had plenty of Fedora maintainers let me know that the
package I'm requesting is deprecated, or going to be deprecated.  This is
the time to bring it up to the Fedora maintainers of the package I really
want.  (Or myself, if that's me)

Like Smooge, I've gotten my hand slapped several times because I've
overstepped.  Or sometimes I don't think I've overstepped, and the
maintainer is just having a bad day/week.
But, that is what makes the new pull request system so much better.  You
can do the requests, and that's what it is, a request.

Anyway, thanks for bringing it up.
And as Felix said, if you see
  python3-nose or python3-mock
help the Fedora maintainer by fixing them, and helping the Fedora
maintainer out with a pull request.

Troy

[Felix Schwarz]

Am 17.02.22 um 13:52 schrieb Stephen John Smoogen:
> The working assumption has been that the Fedora package is already cleaned up 
> and dependencies are there because the main packager thought they were needed. I 
> and other EPEL packagers have spent enough time 'cleaning up' a package and then 
> getting yelled at by the main packager that I broke something important and they 
> wanted me to not touch their package anymore. [Heck we have caused a couple of 
> people to quit Fedora completely over the years because of this.]

I'm sorry that you had that experience however mine has been quite different: 
When worked on getting certbot in EPEL 8 I had to branch quite a few (2-3 dozen) 
packages and while doing that I added test suites and gpg verification if possible.

I never got any angry responses - maybe that is because Python packagers in 
Fedora are pretty nice people (we have Miro after all ;-). The key I think is to 
submit pull requests first and wait for some time. I have to admit that I got 
frustrated more than once by inactive packagers but as far as I can see there is 
no better alternative. Pushing stuff with provenpackager powers without PR is 
certainly quite toxic.

Anyway: I hope you'll have a better experience with EPEL 9 :-)
Felix