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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Thu, Feb 17, 2022 at 6:03 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
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, 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



_______________________________________________
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

[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux