Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)

[Robbie Harwood]

Charalampos Stratakis <cstratak(a)redhat.com&gt; writes:

>  Well it seems so. I mean I would get it to an extend if this
> wasn't a
>  *PR*. But anyway yes a two-line diff apparently should be a patch and
>  not a sed.
>
>  Also according to the PR comments I'm "unwilling" to do that upstream.
That is not how that word is used - the full comment reads:

    - You have not made these changes in a way that is helpful to the
      ecosystem as a whole

    - Once you had to figure out what files needed changed, you could
      simply have submitted a patch - as is done normally. This would
      have enabled me to apply it upstream if you were unwilling to
      submit it yourself.

    Fixed the correct way in d269b84

This is a review of your code.  You have submitted code, and I, the
reviewer, have indicated how it could have been improved, and shown how
I would have preferred it by example.  This is normal open source stuff.

Are you unwilling to submit upstream?  I can't say, hence the
conditional.  What I can say (since upstream is me) is that you didn't.

>  I don't see how that behavior helps the ecosystem. 
So I see it like this:

Our goal is to land changes upstream.  This helps for two reasons: not
only is our maintenance burden lowered by not carrying things downstream
in Fedora unnecessarily, but also other users (including other distros!)
get to benefit from our work.

Broadly speaking, upstreams either want PRs on a github/pagure/gitlab
frontend, or patches on a mailing list.  In either case, the format
requirements are the same: something they can directly feed into git-am
or git-pull.  The more work a downstream maintainer has to do to
upstream something, the less likely they are to do it.

So, if you want a change to help the ecosystem as a whole, upstream
first.  Barring that, lowest barrier to upstreaming.

Thanks,
--Robbie