[EPEL-devel] Re: Plea: Take a moment before you branch everything for EPEL 9

[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
___
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: Plea: Take a moment before you branch everything for EPEL 9

[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  > > 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 

[EPEL-devel] Re: Plea: Take a moment before you branch everything for EPEL 9

[Miro Hrončok]

On 17. 02. 22 13:52, Stephen John Smoogen wrote:



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.


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 

[EPEL-devel] Re: Plea: Take a moment before you branch everything for EPEL 9

[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.
>
>

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Plea: Take a moment before you branch everything for EPEL 9

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


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Plea: Take a moment before you branch everything for EPEL 9

[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
___
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