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

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/DeprecatePythonMock


== Summary ==
The {{package|python-mock}} ({{package|python3-mock}}) package will be
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-pac...
deprecated] in [[Releases/34|Fedora 34]]. The package is a standard
library backport for older Pythons, Fedora packages should use
`unittest.mock` instead. Many still depend on `mock`, so we cannot
remove it yet. Packagers are encouraged to work with upstream to
switch to `unittest.mock` when available. A simple `sed` can be
applied in `%prep` as a temporary (or even permanent) downstream
solution.

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhroncok(a)redhat.com


== Detailed Description ==
The {{package|python-mock}} package is the
[https://pypi.org/project/mock/ 3rd party backport of the standard
library `unittest.mock` module].

>  mock is now part of the Python standard library, available as
> [https://docs.python.org/dev/library/unittest.mock.html unittest.mock] in Python 3.3
> onwards.
>  This package contains a rolling backport of the standard library mock code compatible
> with Python 3.6 and up. 
Fedora has recent enough versions of Python, hence using a library
backport is redundant. Many packages only use it out of habit. We'd
like to encourage both downstream packages and upstreams to switch to
[https://docs.python.org/dev/library/unittest.mock.html unittest.mock]
instead. Eventually, we'd like to drop {{package|python-mock}} from
Fedora entirely, if possible. Before we attempt to remove the package,
we need to stop new packages to (Build)Require
{{package|python3-mock}}, hence we want to have it
[https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-pac...
deprecated].

Note that the change owner does not currently officially maintain
{{package|python-mock}} but the Python Maintenance team maintains the
package in RHEL and contributes to the Fedora package when needed. The
Fedora package maintainers have been contacted without response.

=== How to migrate to unittest.mock ===

In most cases, performing the following replacement should be enough:

 s/^(\s*)import mock/\1from unittest import mock/
 s/^(\s*)from mock import /\1from unittest.mock import /

If upstream really needs to support Python versions without
`unittest.mock`, we recommend using a `try-import` mechanism, such as:

 try:
     from unittest import mock
 except ImportError:
     import mock

If dual support for `unittest.mock` and `mock` is required, and the
`mock` package is required in the metadata (such as in the testing
''extras''), conditionalize it, with:

 mock;python_version<"3.3"

== Feedback ==
In the past, we've managed to migrate some packages away from
python-mock, without a push back:

* https://src.fedoraproject.org/rpms/python-urllib3/pull-request/13
* https://src.fedoraproject.org/rpms/python-freezegun/pull-request/10
* https://src.fedoraproject.org/rpms/python-hypothesis/c/65a4191709

== Benefit to Fedora ==
Eventually, we might be able to no longer maintain a standard library
backport in a separate package.

== Scope ==
* Proposal owners: Deprecate {{package|python3-mock}} and update the
package description. Provide help migrating to `unittest.mock` to
other packagers who ask for it.

* Other developers: No action needed. Don't add new dependencies on
{{package|python3-mock}}. If interested, migrate existing packages to
`unittest.mock` (feel free to ask for help)
* Release engineering: no impact on Release Engineering is anticipated
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:  N/A (not needed for this Change)


== Upgrade/compatibility impact ==
The package will remain available. Only new packages cannot depend on it.
Once retired (in distant future), we don't plan to obsolete/provide
<code>python3-mock</code> from {{package|python3-libs}}, because it
cannot work as drop-in replacement (the import name is different). The
package will eventually be obsoleted by
{{package|fedora-obsolete-packages}} once Python is updated to 3.N+1
after the removal to avoid broken upgrades.

== How To Test ==
 $ repoquery --repo=rawhide --provides python3-mock
 ...
 deprecated()
 ...

== User Experience ==
No changes.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Robbie Harwood]

Ben Cotton <bcotton(a)redhat.com&gt; writes:

>  A simple `sed` can be applied in `%prep` as a temporary (or even
>  permanent) downstream solution.
>
>  In most cases, performing the following replacement should be enough:
>
>   s/^(\s*)import mock/\1from unittest import mock/
>   s/^(\s*)from mock import /\1from unittest.mock import /
>
>  * Other developers: No action needed. Don't add new dependencies on
>  {{package|python3-mock}}. If interested, migrate existing packages to
>  `unittest.mock` (feel free to ask for help) 
Those three snippets together suggest to me that the way this migration
will be performed is that you're going to ProvenPackager in a couple
lines of sed to all (affected) specfiles.  I hope I have misunderstood,
because that has no mechanism to get the changes back into upstreams.
Could you clarify what you intend to do?

>  == Dependencies ==
>  N/A (not a System Wide Change) 
You're proposing changing many packages, so I don't think this qualifies
as a self-contained change.  The actual removal would be, but not
dependency patching.

Speaking of dependencies, though, I'm not seeing a list of packages that
are affected.  Could you provide one?

Thanks,
--Robbie

[Neal Gompa]

On Tue, Jan 19, 2021 at 10:43 AM Robbie Harwood <rharwood(a)redhat.com&gt; wrote:
>  Ben Cotton <bcotton(a)redhat.com&gt; writes:
>
>  > A simple `sed` can be applied in `%prep` as a temporary (or even
>  > permanent) downstream solution.
>  >
>  > In most cases, performing the following replacement should be enough:
>  >
>  >  s/^(\s*)import mock/\1from unittest import mock/
>  >  s/^(\s*)from mock import /\1from unittest.mock import /
>  >
>  > * Other developers: No action needed. Don't add new dependencies on
>  > {{package|python3-mock}}. If interested, migrate existing packages to
>  > `unittest.mock` (feel free to ask for help)
>
>  Those three snippets together suggest to me that the way this migration
>  will be performed is that you're going to ProvenPackager in a couple
>  lines of sed to all (affected) specfiles.  I hope I have misunderstood,
>  because that has no mechanism to get the changes back into upstreams.
>  Could you clarify what you intend to do?
>
>  > == Dependencies ==
>  > N/A (not a System Wide Change)
>
>  You're proposing changing many packages, so I don't think this qualifies
>  as a self-contained change.  The actual removal would be, but not
>  dependency patching.
>
>  Speaking of dependencies, though, I'm not seeing a list of packages that
>  are affected.  Could you provide one?
>  
The way this change is worded, nothing is actually *happening* other
than a policy change that new packages cannot use this dependency
without a FESCo exception (standard deprecated package policy). If
*existing* packages want to change, this Change document describes the
expected effort required to remove it as a dependency to use the
built-in one in Python.

Thus, it makes sense as a Self-Contained Change.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Miro Hrončok]

On 19. 01. 21 16:46, Neal Gompa wrote:
>  On Tue, Jan 19, 2021 at 10:43 AM Robbie Harwood
> <rharwood(a)redhat.com&gt; wrote:
> >
> > Ben Cotton <bcotton(a)redhat.com&gt; writes:
> >
> >> A simple `sed` can be applied in `%prep` as a temporary (or even
> >> permanent) downstream solution.
> >>
> >> In most cases, performing the following replacement should be enough:
> >>
> >>   s/^(\s*)import mock/\1from unittest import mock/
> >>   s/^(\s*)from mock import /\1from unittest.mock import /
> >>
> >> * Other developers: No action needed. Don't add new dependencies on
> >> {{package|python3-mock}}. If interested, migrate existing packages to
> >> `unittest.mock` (feel free to ask for help)
> >
> > Those three snippets together suggest to me that the way this migration
> > will be performed is that you're going to ProvenPackager in a couple
> > lines of sed to all (affected) specfiles.  I hope I have misunderstood,
> > because that has no mechanism to get the changes back into upstreams.
> > Could you clarify what you intend to do? 
I only intend to deprecate python3-mock.
By deprecation, I *do not* mean immediate removal.

I *do not* intent to mass modify packages that use it.
I intend to encourage packagers to do that whenever I will have an opportunity, 
but I will not spam them.

Once the package is only required by a handful of packages, I might go and send 
PRs to accelerate the actual removal but I don't expect to live long enough to 
see that happening.

When I'll work on some packages and I'll see that python3-mock is BuildRequired 
redundantly (= a leftover from the past), I intent to remove the BR (as I would 
do even before this change).

> >> == Dependencies ==
> >> N/A (not a System Wide Change)
> >
> > You're proposing changing many packages, so I don't think this qualifies
> > as a self-contained change.  The actual removal would be, but not
> > dependency patching.
> >
> > Speaking of dependencies, though, I'm not seeing a list of packages that
> > are affected.  Could you provide one?
> >
>  
>  The way this change is worded, nothing is actually *happening* other
>  than a policy change that new packages cannot use this dependency
>  without a FESCo exception (standard deprecated package policy). If
>  *existing* packages want to change, this Change document describes the
>  expected effort required to remove it as a dependency to use the
>  built-in one in Python.
>  
>  Thus, it makes sense as a Self-Contained Change. 
What Neal says. But if you are interested, you can run:

   $ repoquery --repo=rawhide{,-source} --whatrequires python3-mock

You'll get the following (ridiculously long) list of source packages that BR it:

androguard
ansible
ansible-review
autoarchive
autojump
beaker
bodhi
bugzilla2fedmsg
buildbot
cloud-init
commissaire-client
compose-utils
conda
datagrepper
datanommer-commands
distgen
dlrn
dumb-init
enki
fedfind
fedmsg
fedora-messaging
fedpkg
fedscm-admin
flent
gnome-gmail
gtimelog
heat-cfntools
ibus-table
ibus-typing-booster
jpype
libabigail
limnoria
litecli
mailman3
matrix-synapse
mirrormanager2
mom
mycli
obs-service-tar_scm
odcs
oraculum
oscap-anaconda-addon
pdc-client
pgcli
pipenv
pre-commit
proselint
pungi
pycolumnize
pyee
pyosmium
pyproj
pytest
python-MDAnalysis
python-Traits
python-ZEO
python-agate
python-aiomqtt
python-aiounifi
python-alarmdecoder
python-alembic
python-amqp
python-ansi2html
python-ansible-runner
python-anykeystore
python-apprise
python-argh
python-arrow
python-authlib
python-autobahn
python-bashate
python-beaker
python-behave
python-bigsuds
python-billiard
python-bitmath
python-blessed
python-blockdiag
python-boto
python-botocore
python-carbon
python-cartopy
python-catkin_lint
python-catkin_pkg
python-catkin_tools
python-cfgv
python-check-manifest
python-cherrypy
python-cli-helpers
python-cliff
python-cloudpickle
python-clyent
python-colcon-core
python-colcon-ros-bundle
python-collectd_systemd
python-coloredlogs
python-copr
python-cornice
python-cornice-sphinx
python-daemon
python-dateparser
python-dcrpm
python-deepdiff
python-dictdiffer
python-diff-cover
python-digitalocean
python-django
python-django-auth-ldap
python-django-configurations
python-django-filter
python-django-helpdesk
python-django-pyscss
python-dns-lexicon
python-docker-squash
python-docx
python-dogpile-cache
python-doit
python-easyargs
python-elpy
python-engineio
python-etcd
python-eyed3
python-f5-icontrol-rest
python-f5-sdk
python-fastpurge
python-fedmsg-meta-fedora-infrastructure
python-fido2
python-firehose
python-fixtures
python-flake8
python-flake8-polyfill
python-flask-oidc
python-flask-restful
python-flask-sqlalchemy
python-fsleyes
python-fsleyes-props
python-fsleyes-widgets
python-fslpy
python-gabbi
python-geopy
python-gitlab
python-google-api-core
python-google-auth-oauthlib
python-graphviz
python-hamcrest
python-hdfs
python-html5lib
python-http-ece
python-httplib2
python-httpretty
python-humanize
python-hupper
python-ifcfg
python-invoke
python-ipdb
python-ipmi
python-isort
python-jenkins
python-jenkins-job-builder
python-jmespath
python-josepy
python-jsonrpc-server
python-jupyter-client
python-kdcproxy
python-keystoneauth1
python-keystoneclient
python-klusta
python-kombu
python-krbcontext
python-lacrosse
python-language-server
python-libarchive-c
python-lightblue
python-m2r
python-magic-wormhole
python-magic-wormhole-mailbox-server
python-magic-wormhole-transit-relay
python-magnumclient
python-mako
python-maxminddb
python-metaextract
python-moksha-common
python-moksha-hub
python-mpd2
python-music21
python-mwclient
python-nb2plots
python-nbconvert
python-network-runner
python-nibabel
python-nodeenv
python-nose2
python-nuheat
python-oauth2client
python-oauthlib
python-octaviaclient
python-okaara
python-opencensus
python-openqa_client
python-openstackclient
python-openstacksdk
python-opnsense
python-osc-lib
python-oslo-log
python-oslo-serialization
python-osrf-pycommon
python-paramiko
python-pelican
python-pep517
python-persist-queue
python-pika
python-pip
python-praw
python-prawcore
python-promise
python-psutil
python-pyarlo
python-pydenticon
python-pyelectro
python-pyface
python-pygraphviz
python-pykafka
python-pymemcache
python-pymochad
python-pysb
python-pystemd
python-pytest-shutil
python-pytest-spec
python-ratelimitingfilter
python-readme-renderer
python-readthedocs-sphinx-ext
python-redis
python-remoto
python-renderspec
python-requests-gssapi
python-requests-kerberos
python-requests-mock
python-requests-oauthlib
python-requests-toolbelt
python-responses
python-robosignatory
python-rosdep
python-rosinstall
python-rospkg
python-rows
python-ryu
python-saharaclient
python-schedule
python-schema
python-setuptools
python-shade
python-simplebayes
python-slacker
python-socketio
python-soco
python-sphinx-intl
python-sphinxcontrib-websupport
python-spyder-kernels
python-sqlalchemy
python-sqlalchemy-collectd
python-sqlalchemy-utils
python-sseclient
python-statsd
python-stestr
python-stevedore
python-streamlink
python-sure
python-swagger-spec-validator
python-tables
python-tackerclient
python-tinyrpc
python-transaction
python-troveclient
python-twilio
python-twitter
python-txaio
python-txtorcon
python-tzlocal
python-urllib3
python-vcrpy
python-vcstools
python-verboselogs
python-vine
python-virtualbmc
python-vitrageclient
python-waterfurnace
python-webassets
python-whisper
python-winrm
python-ws4py
python-wstool
python-wurlitzer
python-xlib
python-xvfbwrapper
python-yarg
python-zc-lockfile
python-zdaemon
python-zeep
pyutil
restview
resultsdb_conventions
rpkg
rpkg-util
salt
sshuttle
testcloud
thefuck
tmt
transifex-client
transtats-cli
ursa-major
vex
wad
waiverdb
wfuzz

And the following packages that require it on runtime, which I find even more 
perplexing:

limnoria
python3-MDAnalysis
python3-certbot-dns-cloudxns
python3-cliff-tests
python3-debianbts
python3-django-helpdesk
python3-hdfs
python3-keystoneclient-tests
python3-kubernetes-tests
python3-magnumclient-tests
python3-music21
python3-octaviaclient-tests
python3-odcs-common
python3-osc-lib-tests
python3-oslo-log-tests
python3-oslo-serialization-tests
python3-oslotest
python3-pytest-shutil
python3-pywbem
python3-sure
python3-tackerclient-tests-unit
python3-tinyrpc-tests
python3-transtats-cli
python3-urwidtrees
python3-vcrpy
waiverdb

Or, if you prefer their components:

limnoria
odcs
python-MDAnalysis
python-certbot-dns-cloudxns
python-cliff
python-debianbts
python-django-helpdesk
python-hdfs
python-keystoneclient
python-kubernetes
python-magnumclient
python-music21
python-octaviaclient
python-osc-lib
python-oslo-log
python-oslo-serialization
python-oslotest
python-pytest-shutil
python-sure
python-tackerclient
python-tinyrpc
python-urwidtrees
python-vcrpy
pywbem
transtats-cli
waiverdb


To repeat: *I do not plan any mass actions towards the listed packages* in 
Fedora, except the ones that I maintain myself, if any.

Disclaimer: The package is listed as unwanted in ELN (so the RHEL maintainers 
might get some internal spam about dropping the dependency). If they will be 
interested, I might end up sending a Fedora PR for such packages.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Robbie Harwood]

Robbie Harwood <rharwood(a)redhat.com&gt; writes:

>  Ben Cotton <bcotton(a)redhat.com&gt; writes:
>
> > A simple `sed` can be applied in `%prep` as a temporary (or even
> > permanent) downstream solution.
> >
> > In most cases, performing the following replacement should be enough:
> >
> >  s/^(\s*)import mock/\1from unittest import mock/
> >  s/^(\s*)from mock import /\1from unittest.mock import /
>
>  a couple lines of sed to all (affected) specfiles.  I hope I have
>  misunderstood, because that has no mechanism to get the changes back
>  into upstreams.  Could you clarify what you intend to do? 
Turns out this is indeed what they meant.  I would like to reiterate
my concern that this has no mechanism to get the changes back into
upstreams: it's just Fedora deviating further from the rest of the
world, not leading the charge.

Thanks,
--Robbie

[Miro Hrončok]

On 08. 02. 21 20:38, Robbie Harwood wrote:
>  Robbie Harwood <rharwood(a)redhat.com&gt; writes:
>  
> > Ben Cotton <bcotton(a)redhat.com&gt; writes:
> >
> >> A simple `sed` can be applied in `%prep` as a temporary (or even
> >> permanent) downstream solution.
> >>
> >> In most cases, performing the following replacement should be enough:
> >>
> >>   s/^(\s*)import mock/\1from unittest import mock/
> >>   s/^(\s*)from mock import /\1from unittest.mock import /
> >
> > a couple lines of sed to all (affected) specfiles.  I hope I have
> > misunderstood, because that has no mechanism to get the changes back
> > into upstreams.  Could you clarify what you intend to do?
>  
>  Turns out this is indeed what they meant.  I would like to reiterate
>  my concern that this has no mechanism to get the changes back into
>  upstreams: it's just Fedora deviating further from the rest of the
>  world, not leading the charge. 
Not sure who you mean by "them" in this case, but doing this downstream only was

never my intention. I am the change owner.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

On 08. 02. 21 22:43, Miro Hrončok wrote:
>  On 08. 02. 21 20:38, Robbie Harwood wrote:
> > Robbie Harwood <rharwood(a)redhat.com&gt; writes:
> >
> >> Ben Cotton <bcotton(a)redhat.com&gt; writes:
> >>
> >>> A simple `sed` can be applied in `%prep` as a temporary (or even
> >>> permanent) downstream solution.
> >>>
> >>> In most cases, performing the following replacement should be enough:
> >>>
> >>>   s/^(\s*)import mock/\1from unittest import mock/
> >>>   s/^(\s*)from mock import /\1from unittest.mock import /
> >>
> >> a couple lines of sed to all (affected) specfiles.  I hope I have
> >> misunderstood, because that has no mechanism to get the changes back
> >> into upstreams.  Could you clarify what you intend to do?
> >
> > Turns out this is indeed what they meant.  I would like to reiterate
> > my concern that this has no mechanism to get the changes back into
> > upstreams: it's just Fedora deviating further from the rest of the
> > world, not leading the charge.
>  
>  Not sure who you mean by "them" in this case, but doing this downstream only
> was 
>  never my intention. I am the change owner. 
Neither is a provenpackager adding the sed to all (affected) specfiles.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Robbie Harwood]

Miro Hrončok <mhroncok(a)redhat.com&gt; writes:

>  On 08. 02. 21 20:38, Robbie Harwood wrote:
> > Robbie Harwood <rharwood(a)redhat.com&gt; writes:
> > 
> >> Ben Cotton <bcotton(a)redhat.com&gt; writes:
> >>
> >>> A simple `sed` can be applied in `%prep` as a temporary (or even
> >>> permanent) downstream solution.
> >>>
> >>> In most cases, performing the following replacement should be enough:
> >>>
> >>>   s/^(\s*)import mock/\1from unittest import mock/
> >>>   s/^(\s*)from mock import /\1from unittest.mock import /
> >>
> >> a couple lines of sed to all (affected) specfiles.  I hope I have
> >> misunderstood, because that has no mechanism to get the changes back
> >> into upstreams.  Could you clarify what you intend to do?
> > 
> > Turns out this is indeed what they meant.  I would like to reiterate
> > my concern that this has no mechanism to get the changes back into
> > upstreams: it's just Fedora deviating further from the rest of the
> > world, not leading the charge.
>
>  Not sure who you mean by "them" in this case, 
Change authors.  So, you.

>  but doing this downstream only was never my intention. I am the
> change
>  owner. 
You have already replied to one of the PRs
https://src.fedoraproject.org/rpms/python-requests-gssapi/pull-request/1
to comment that it couldn't be merged.  It follows the downstream-only
sed approach, you'll note.

Thanks,
--Robbie

[Zbigniew Jędrzejewski-Szmek]

On Mon, Feb 08, 2021 at 07:54:00PM -0500, Robbie Harwood wrote:
>  Miro Hrončok <mhroncok(a)redhat.com&gt; writes:
>  
>  > On 08. 02. 21 20:38, Robbie Harwood wrote:
>  >> Robbie Harwood <rharwood(a)redhat.com&gt; writes:
>  >> 
>  >>> Ben Cotton <bcotton(a)redhat.com&gt; writes:
>  >>>
>  >>>> A simple `sed` can be applied in `%prep` as a temporary (or even
>  >>>> permanent) downstream solution.
>  >>>>
>  >>>> In most cases, performing the following replacement should be enough:
>  >>>>
>  >>>>   s/^(\s*)import mock/\1from unittest import mock/
>  >>>>   s/^(\s*)from mock import /\1from unittest.mock import /
>  >>>
>  >>> a couple lines of sed to all (affected) specfiles.  I hope I have
>  >>> misunderstood, because that has no mechanism to get the changes back
>  >>> into upstreams.  Could you clarify what you intend to do?
>  >> 
>  >> Turns out this is indeed what they meant.  I would like to reiterate
>  >> my concern that this has no mechanism to get the changes back into
>  >> upstreams: it's just Fedora deviating further from the rest of the
>  >> world, not leading the charge.
>  >
>  > Not sure who you mean by "them" in this case,
>  
>  Change authors.  So, you.
>  
>  > but doing this downstream only was never my intention. I am the change
>  > owner.
>  
>  You have already replied to one of the PRs
>  https://src.fedoraproject.org/rpms/python-requests-gssapi/pull-request/1
>  to comment that it couldn't be merged.  It follows the downstream-only
>  sed approach, you'll note. 
So... let me get this straight: the Change Owners found outdated code in your
package, created a page to describe the issue in detail, and opened a pull request
to tell you exactly how you can update the code. And now you are pissed that
they didn't provide the two line diff in the the format that you like.
That's really a way to show appreciation of other people helping with your packages.

Zbyszek

[Miro Hrončok]

On 09. 02. 21 1:54, Robbie Harwood wrote:
>  Miro Hrončok <mhroncok(a)redhat.com&gt; writes:
>  
> > On 08. 02. 21 20:38, Robbie Harwood wrote:
> >> Robbie Harwood <rharwood(a)redhat.com&gt; writes:
> >>
> >>> Ben Cotton <bcotton(a)redhat.com&gt; writes:
> >>>
> >>>> A simple `sed` can be applied in `%prep` as a temporary (or even
> >>>> permanent) downstream solution.
> >>>>
> >>>> In most cases, performing the following replacement should be enough:
> >>>>
> >>>>    s/^(\s*)import mock/\1from unittest import mock/
> >>>>    s/^(\s*)from mock import /\1from unittest.mock import /
> >>>
> >>> a couple lines of sed to all (affected) specfiles.  I hope I have
> >>> misunderstood, because that has no mechanism to get the changes back
> >>> into upstreams.  Could you clarify what you intend to do?
> >>
> >> Turns out this is indeed what they meant.  I would like to reiterate
> >> my concern that this has no mechanism to get the changes back into
> >> upstreams: it's just Fedora deviating further from the rest of the
> >> world, not leading the charge.
> >
> > Not sure who you mean by "them" in this case,
>  
>  Change authors.  So, you. 
I have not made any such changes. Except maybe in a couple of my packages I 
co-maintain.

> > but doing this downstream only was never my intention. I am the
> change
> > owner.
>  
>  You have already replied to one of the PRs
>  https://src.fedoraproject.org/rpms/python-requests-gssapi/pull-request/1
>  to comment that it couldn't be merged.  It follows the downstream-only
>  sed approach, you'll note. 
I have commented this PR but I have not even seen the diff yet.
If I've seen it, I'd ask whether it can be proposed upstream as well.
I'd ask that whether or not it is applied as a sed or patch (or any other way).

Also note that it is a Pull Request, not a provenpackager mass pushing changes.

The PR is actually driven by a RHEL 9 bugzilla because the python3-mock package 
is marked as unwanted in https://github.com/minimization/content-resolver-input

As I've already said in my first reply to you in January:

>  Disclaimer: The package is listed as unwanted in ELN (so the RHEL
> maintainers
>  might get some internal spam about dropping the dependency). If they will be
>  interested, I might end up sending a Fedora PR for such packages.  
Please stop accusing me of ill intention. I do what I say I do. I have no 
interest in tricking Fedora to approve a change only to do things differently 
once approved. My communication is and always has been as transparent as 
possible -- wrt this Change or anything else.

I strongly believe in the "upstream first" paradigm. Sometimes, time is the 
essence and things need to be done in downstream first, yet even then I 
encourage everybody to propose the change upstream.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Charalampos Stratakis]

----- Original Message -----
>  From: "Zbigniew Jędrzejewski-Szmek"
> <zbyszek(a)in.waw.pl&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Cc: "Miro Hrončok" <mhroncok(a)redhat.com&gt;
>  Sent: Tuesday, February 9, 2021 8:58:36 AM
>  Subject: Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
>  
>  On Mon, Feb 08, 2021 at 07:54:00PM -0500, Robbie Harwood wrote:
>  > Miro Hrončok <mhroncok(a)redhat.com&gt; writes:
>  > 
>  > > On 08. 02. 21 20:38, Robbie Harwood wrote:
>  > >> Robbie Harwood <rharwood(a)redhat.com&gt; writes:
>  > >> 
>  > >>> Ben Cotton <bcotton(a)redhat.com&gt; writes:
>  > >>>
>  > >>>> A simple `sed` can be applied in `%prep` as a temporary (or even
>  > >>>> permanent) downstream solution.
>  > >>>>
>  > >>>> In most cases, performing the following replacement should be
> enough:
>  > >>>>
>  > >>>>   s/^(\s*)import mock/\1from unittest import mock/
>  > >>>>   s/^(\s*)from mock import /\1from unittest.mock import /
>  > >>>
>  > >>> a couple lines of sed to all (affected) specfiles.  I hope I have
>  > >>> misunderstood, because that has no mechanism to get the changes back
>  > >>> into upstreams.  Could you clarify what you intend to do?
>  > >> 
>  > >> Turns out this is indeed what they meant.  I would like to reiterate
>  > >> my concern that this has no mechanism to get the changes back into
>  > >> upstreams: it's just Fedora deviating further from the rest of the
>  > >> world, not leading the charge.
>  > >
>  > > Not sure who you mean by "them" in this case,
>  > 
>  > Change authors.  So, you.
>  > 
>  > > but doing this downstream only was never my intention. I am the change
>  > > owner.
>  > 
>  > You have already replied to one of the PRs
>  > https://src.fedoraproject.org/rpms/python-requests-gssapi/pull-request/1
>  > to comment that it couldn't be merged.  It follows the downstream-only
>  > sed approach, you'll note.
>  
>  So... let me get this straight: the Change Owners found outdated code in your
>  package, created a page to describe the issue in detail, and opened a pull
>  request
>  to tell you exactly how you can update the code. And now you are pissed that
>  they didn't provide the two line diff in the the format that you like.
>  That's really a way to show appreciation of other people helping with your
>  packages.
>  
>  Zbyszek
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>   
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.

I don't see how that behavior helps the ecosystem.

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat

[Robbie Harwood]

Miro Hrončok <mhroncok(a)redhat.com&gt; writes:

>  On 09. 02. 21 1:54, Robbie Harwood wrote:
> > Miro Hrončok <mhroncok(a)redhat.com&gt; writes:
> >> On 08. 02. 21 20:38, Robbie Harwood wrote:
> >>> Robbie Harwood <rharwood(a)redhat.com&gt; writes:
> >>>> Ben Cotton <bcotton(a)redhat.com&gt; writes:
> >>
> >> but doing this downstream only was never my intention. I am the
> >> change owner.
> > 
> > You have already replied to one of the PRs
> > https://src.fedoraproject.org/rpms/python-requests-gssapi/pull-request/1
> > to comment that it couldn't be merged.  It follows the
> > downstream-only sed approach, you'll note.
>
>  I have commented this PR but I have not even seen the diff yet.  If
>  I've seen it, I'd ask whether it can be proposed upstream as well.
>  I'd ask that whether or not it is applied as a sed or patch (or any
>  other way).
>
>  Also note that it is a Pull Request, not a provenpackager mass pushing
>  changes. 
Indeed, one step closer to doing this right :)

>  The PR is actually driven by a RHEL 9 bugzilla because the
> python3-mock package 
>  is marked as unwanted in https://github.com/minimization/content-resolver-input 
This continues to be Fedora, not RHEL.  I don't think python3-mock
should stay, but it's not justification *for Fedora*.

>  As I've already said in my first reply to you in January:
>
> > Disclaimer: The package is listed as unwanted in ELN (so the RHEL
> > maintainers might get some internal spam about dropping the
> > dependency). If they will be interested, I might end up sending a
> > Fedora PR for such packages.
>
>  Please stop accusing me of ill intention. 
To my knowledge, I have only stated facts.  To be clear, I do not
believe you have ill intention - I believe we disagree, and aren't
communicating well.

Thanks,
--Robbie

[Robbie Harwood]

Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; writes:

>  And now you are pissed that they didn't provide the two line diff
> in
>  the the format that you like. 
This belittling is uncalled for; your escalation here is not needed, nor
is it helpful to keeping the conversation on a technical track.

Thanks,
--Robbie

[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

[Miro Hrončok]

On 09. 02. 21 17:17, Robbie Harwood wrote:
>  Miro Hrončok <mhroncok(a)redhat.com&gt; writes:
>  
> > On 09. 02. 21 1:54, Robbie Harwood wrote:
> >> Miro Hrončok <mhroncok(a)redhat.com&gt; writes:
> >>> On 08. 02. 21 20:38, Robbie Harwood wrote:
> >>>> Robbie Harwood <rharwood(a)redhat.com&gt; writes:
> >>>>> Ben Cotton <bcotton(a)redhat.com&gt; writes:
> >>>
> >>> but doing this downstream only was never my intention. I am the
> >>> change owner.
> >>
> >> You have already replied to one of the PRs
> >> https://src.fedoraproject.org/rpms/python-requests-gssapi/pull-request/1
> >> to comment that it couldn't be merged.  It follows the
> >> downstream-only sed approach, you'll note.
> >
> > I have commented this PR but I have not even seen the diff yet.  If
> > I've seen it, I'd ask whether it can be proposed upstream as well.
> > I'd ask that whether or not it is applied as a sed or patch (or any
> > other way).
> >
> > Also note that it is a Pull Request, not a provenpackager mass pushing
> > changes.
>  
>  Indeed, one step closer to doing this right :) 
To doing what right? If I am doing something wrong, tell me how exactly and what 
am I doing. So far you only accused me of doing something I am not doing.

> > The PR is actually driven by a RHEL 9 bugzilla because the
> python3-mock package
> > is marked as unwanted in https://github.com/minimization/content-resolver-input
>  
>  This continues to be Fedora, not RHEL.  I don't think python3-mock
>  should stay, but it's not justification *for Fedora*. 
Yes. And I've told you that my Fedora change has not caused the Pull Request 
you've seen.

> > As I've already said in my first reply to you in January:
> >
> >> Disclaimer: The package is listed as unwanted in ELN (so the RHEL
> >> maintainers might get some internal spam about dropping the
> >> dependency). If they will be interested, I might end up sending a
> >> Fedora PR for such packages.
> >
> > Please stop accusing me of ill intention.
>  
>  To my knowledge, I have only stated facts.  To be clear, I do not
>  believe you have ill intention - I believe we disagree, and aren't
>  communicating well. 
I believe we more or less agree about how things should be done.
I believe we don't agree about the reality thou. I don't know why.

You have stated speculations, not facts.

1) "you're going to ProvenPackager in a couple lines of sed to all (affected) 
specfiles"

I am not.

2) "You're proposing changing many packages"

I am not.

3) "Turns out this is indeed what they meant." (about (1) and possibly (2))

It is not.



Note that in your first email, the speculations seemed like a misunderstanding 
(there was even an "I hope I have misunderstood"). But recently you switched 
directly to false accusations. I don't know why you do this, or what have I done 
to deserve this treatment, but let me be absolutely clear:

I am not conducting the stuff you accuse me off. I realize that sometimes people 
make errors in judgement but I've already told you this once and you keep saying 
otherwise. Please stop.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Charalampos Stratakis]

----- Original Message -----
>  From: "Robbie Harwood" <rharwood(a)redhat.com&gt;
>  To: "Charalampos Stratakis" <cstratak(a)redhat.com&gt;, "Development
> discussions related to Fedora"
>  <devel(a)lists.fedoraproject.org&gt;
>  Cc: "Miro Hrončok" <mhroncok(a)redhat.com&gt;
>  Sent: Tuesday, February 9, 2021 5:30:45 PM
>  Subject: Re: Fedora 34 Change: Deprecate python-mock (Self-Contained change proposal)
>  
>  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:
>   
>  
>  
>      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.
>   
> >     - You have not made these changes in a way that is helpful to
> the
> >      ecosystem as a whole 
That comment is neither a code review nor an indication of your preferences. Telling me
that this PR doesn't help the ecosystem somehow is not helpful in addressing your
point. I suggest to used a better tone in your wording. Written communication can be
misinterpreted many times, but that's not an excuse for accusing others of ignorance
of your words. 

>  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.
>   
> >     - 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. 
You can't say, yet you suggested it. You could always ask me to send a PR upstream
which is the *normal* way of asking things. Also submitting a patch is normal and a sed is
not? If you'd like to keep this technical please refrain from using non-technical
wording then. I've changed PR's to adhere to maintainer's wishes but I always
prefer to have a civilized and not an accusatory discussion over it. 

>  > 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. 
I wholeheartedly agree to that. I still don't think that a 2-3 line change requires a
patch but that's up for debate. If you'd like you can make a case for the Fedora
packaging committee to ban the use of sed in the SPECs. Or you could ask in the PR.
Instead you provide comments like:

> > it's just Fedora deviating further from the rest of the
> > world, not leading the charge. 
I'm sorry but while I can see your point, your way of trying to frame it is really not
an optimal one.

>  
>  Thanks,
>  --Robbie
>   
-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat