On 17. 02. 22 13:52, Stephen John Smoogen wrote:
On Thu, 17 Feb 2022 at 07:11, Miro Hrončok <mhroncok@xxxxxxxxxx
<mailto:mhroncok@xxxxxxxxxx>> 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 Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
