Skip to content

[3.7] Remove unused imports in tests (GH-14518) #14522

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 1, 2019
Merged

[3.7] Remove unused imports in tests (GH-14518) #14522

merged 2 commits into from
Jul 1, 2019

Conversation

vstinner
Copy link
Member

@vstinner vstinner commented Jul 1, 2019

(cherry picked from commit 8f4ef3b)

@vstinner vstinner merged commit e34b5f4 into python:3.7 Jul 1, 2019
@vstinner vstinner deleted the remove_unused_imports37 branch July 1, 2019 18:02
@ned-deily
Copy link
Member

Why is this being backported into a maintenance branch? What bug is this fixing? What bugs are being introduced by it?

@vstinner
Copy link
Member Author

vstinner commented Jul 2, 2019

Why is this being backported into a maintenance branch? What bug is this fixing? What bugs are being introduced by it?

Oh sorry, I only explained it in the main PR (for master):
"I backported the change to Python 3.7 and 3.8 to reduce conflicts on backports."
#14518 (comment)

Otherwise, automated backports will more likely fail with a dummy conflict. I prefer when the bot is able to automatically backport changes to 3.7 and 3.8 ;-) I'm trying to backport all bugfixes to 2.7, 3.7 and 3.8: all maintained branches.

Note: I chose to not backport this change to 2.7, there are likely too many conflicts, and 2.7 is getting less and less changes.

@ned-deily
Copy link
Member

ned-deily commented Jul 2, 2019

I don't want to make a big deal out of this but, In general, reducing the potential for future backport conflicts is not an acceptable reason for changing a maintenance branch:

The only changes allowed to occur in a maintenance branch without debate are bug fixes.

To do otherwise is to jeopardize the stability and compatibility guarantees that we make to our downstream users (i.e. that they can upgrade from one micro release to any higher micro release without anything breaking), solely for our own convenience. Sure, there is not a hard and fast rule: factors like where a particular release is in its life cycle should be taken into account. So backporting such a change from master to a branch that is still in a pre-release phase (like 3.8 is at the moment) is one thing. But 3.7 has been released for a year and is halfway through its maintenance phase. We should not be planning to backport lots of changes to it at this point. And changes to tests are still changes to the codebase of a release. Changes to the tests can hide errors and make it more difficult to see regressions. What are the chances that some new bug has been introduced in the changes to over 40 files - for no functional benefit?

@vstinner
Copy link
Member Author

vstinner commented Jul 2, 2019

@ned-deily: Ok, I created PR #14555 to revert it. I will merge it as soon as the CI tests pass.

vstinner added a commit that referenced this pull request Jul 2, 2019
@vstinner
Copy link
Member Author

vstinner commented Jul 2, 2019

I reverted this change ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants