Skip to contentSkip to conversation

scripts: Remove unused python imports

PATCH In review Philippe Mathieu-Daudé 4 participants 9 messages Nov 8, 2018

lore
Share & tools
lore

Philippe Mathieu-Daudé

author
#0 lore raw

PATCH 1/1 scripts: Remove unused python imports

Reported-by LGTM code review
Signed-off-by Philippe Mathieu-Daudé <[email protected]>
---
 scripts/analyse-locks-simpletrace.py         | 1 -
 scripts/analyze-migration.py                 | 1 -
 scripts/device-crash-test                    | 1 -
 scripts/simpletrace.py                       | 1 -
 scripts/tracetool.py                         | 2 --
 scripts/tracetool/format/simpletrace_stap.py | 2 +-
 6 files changed, 1 insertion(+), 7 deletions(-)
scripts/analyse-locks-simpletrace.py +0 -1
index 30090bdfff..7d9b574300 100755
@@ -7,7 +7,6 @@
 #
 
 from __future__ import print_function
-import os
 import simpletrace
 import argparse
 import numpy as np
scripts/analyze-migration.py +0 -1
index 5c2010c917..e527eb168e 100755
@@ -23,7 +23,6 @@ import json
 import os
 import argparse
 import collections
-import pprint
 
 def mkdir_p(path):
     try:
scripts/device-crash-test +0 -1
index e93a7c0c84..f459d582be 100755
@@ -26,7 +26,6 @@ check for crashes and unexpected errors.
 from __future__ import print_function
 
 import sys
-import os
 import glob
 import logging
 import traceback
scripts/simpletrace.py +0 -1
index 4ad34f90cd..45485b864b 100755
@@ -11,7 +11,6 @@
 
 from __future__ import print_function
 import struct
-import re
 import inspect
 from tracetool import read_events, Event
 from tracetool.backend.simple import is_string
scripts/tracetool.py +0 -2
index fe2b0771f2..3beaa66bd8 100755
@@ -15,8 +15,6 @@ __email__      = "[email protected]"
 
 import sys
 import getopt
-import os.path
-import re
 
 from tracetool import error_write, out
 import tracetool.backend
scripts/tracetool/format/simpletrace_stap.py +1 -1
index e7e44842ca..57b04061cf 100644
@@ -14,7 +14,7 @@ __email__      = "[email protected]"
 
 
 from tracetool import out
-from tracetool.backend.dtrace import binary, probeprefix
+from tracetool.backend.dtrace import probeprefix
 from tracetool.backend.simple import is_string
 from tracetool.format.stap import stap_escape
Signature · 1 line
2.17.2
#2 lore raw
Quoted 5 lines · Eduardo Habkost
Quoted 2 lines · Philippe Mathieu-Daudé
Reported-by LGTM code review
Signed-off-by Philippe Mathieu-Daudé <[email protected]>

Queueing for 3.2, thanks.

Next release after 3.1 will be 4.0, by the way -- we're moving to "bump major version every year".

thanks
-- PMM

author
#3 lore raw
Quoted 9 lines · Peter Maydell
Quoted 5 lines · Eduardo Habkost
Quoted 2 lines · Philippe Mathieu-Daudé
Reported-by LGTM code review
Signed-off-by Philippe Mathieu-Daudé <[email protected]>

Queueing for 3.2, thanks.

Next release after 3.1 will be 4.0, by the way -- we're moving to "bump major version every year".

So major versions help to remember the 12th anniversary of QEMU?

Why not start at 19.0?

#4 lore raw
Quoted 6 lines · Philippe Mathieu-Daudé
Quoted 5 lines · Peter Maydell
Quoted 4 lines · Eduardo Habkost
Quoted 2 lines · Philippe Mathieu-Daudé
Reported-by LGTM code review
Signed-off-by Philippe Mathieu-Daudé <[email protected]>
Quoted 8 lines
Quoted 4 lines
Quoted 1 line

Queueing for 3.2, thanks.

Next release after 3.1 will be 4.0, by the way -- we're moving to "bump major version every year".

So major versions help to remember the 12th anniversary of QEMU?

Why not start at 19.0?

We had this discussion when we agreed on the new version policy; I don't want to reopen it.

thanks
-- PMM

author
#5 lore raw
Quoted 12 lines · Peter Maydell
Quoted 11 lines · Philippe Mathieu-Daudé
Quoted 9 lines · Peter Maydell
Quoted 5 lines · Eduardo Habkost
Quoted 2 lines · Philippe Mathieu-Daudé
Reported-by LGTM code review
Signed-off-by Philippe Mathieu-Daudé <[email protected]>

Queueing for 3.2, thanks.

Next release after 3.1 will be 4.0, by the way -- we're moving to "bump major version every year".

Quoted 6 lines
Quoted 3 lines

So major versions help to remember the 12th anniversary of QEMU?

Why not start at 19.0?

We had this discussion when we agreed on the new version policy; I don't want to reopen it.

Sorry I missed it, I'll look in the archives.

Anyway there are no information about merge window in the wiki.
When I started it was not easy to understand it and why patches sent when 'merge window is close' fall under the crap and are unnoticed, thus it is better to wait before to send, or resend them. I'd appreciate if someone add this (Contribute/SubmitAPatch is probably the page to modify), also describing than some maintainers agree to take patches in their -next queue, even when merge window is closed Also you could add the expected dates for the next releases there.

Regards,

Phil.

#6 lore raw
Quoted 4 lines · Philippe Mathieu-Daudé

Anyway there are no information about merge window in the wiki. When I started it was not easy to understand it and why patches sent when 'merge window is close' fall under the crap and are unnoticed, thus it is better to wait before to send, or resend them.

The intention (not always something we succeed at) is that maintainers should respond to patches, do review, etc, at any point in our release cycle. During a release they might reply to say "I won't get to reviewing this for a little while" or "I'll take this patch once the trunk reopens for releases", but they shouldn't just leave patch submitters with no response at all...

Quoted 1 line

Also you could add the expected dates for the next releases there.

We only work out dates for the next release when we've got the previous one out. They're roughly April/August/December, though.

thanks
-- PMM

#7 lore raw
Quoted 11 lines · Peter Maydell
Quoted 4 lines · Philippe Mathieu-Daudé

Anyway there are no information about merge window in the wiki. When I started it was not easy to understand it and why patches sent when 'merge window is close' fall under the crap and are unnoticed, thus it is better to wait before to send, or resend them.

The intention (not always something we succeed at) is that maintainers should respond to patches, do review, etc, at any point in our release cycle. During a release they might reply to say "I won't get to reviewing this for a little while" or "I'll take this patch once the trunk reopens for releases",

In both cases, the maintainer remains responsible for tracking the patches.

I believe the sane thing to do is to review patches as usual, and to queue the ones that are ready to go into the next release on a separate branch.

Quoted 2 lines

but they shouldn't just leave patch submitters with no response at all...

Yes, that's rude.

[...]

author
#8 lore raw
Quoted 16 lines · Markus Armbruster
Quoted 11 lines · Peter Maydell
Quoted 4 lines · Philippe Mathieu-Daudé

Anyway there are no information about merge window in the wiki. When I started it was not easy to understand it and why patches sent when 'merge window is close' fall under the crap and are unnoticed, thus it is better to wait before to send, or resend them.

The intention (not always something we succeed at) is that maintainers should respond to patches, do review, etc, at any point in our release cycle. During a release they might reply to say "I won't get to reviewing this for a little while" or "I'll take this patch once the trunk reopens for releases",

In both cases, the maintainer remains responsible for tracking the patches.

Quoted 8 lines

I believe the sane thing to do is to review patches as usual, and to queue the ones that are ready to go into the next release on a separate branch.

Quoted 2 lines

but they shouldn't just leave patch submitters with no response at all...

Yes, that's rude.

Thanks both to clarify your maintainer view.
I added this thread to my TODO and if nobody write about this in the wiki I'll, but later.

Phil.