scripts: Remove unused python imports
diff mbox series

Message ID 20181108143422.15955-1-philmd@redhat.com
State New
Headers show
Series
  • scripts: Remove unused python imports
Related show

Commit Message

Philippe Mathieu-Daudé Nov. 8, 2018, 2:34 p.m. UTC
Reported-by: LGTM code review
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 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(-)

Comments

Eduardo Habkost Nov. 8, 2018, 5:17 p.m. UTC | #1
On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
> Reported-by: LGTM code review
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>

Queueing for 3.2, thanks.
Peter Maydell Nov. 8, 2018, 5:25 p.m. UTC | #2
On 8 November 2018 at 17:17, Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
>> Reported-by: LGTM code review
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>
> 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
Philippe Mathieu-Daudé Nov. 8, 2018, 5:41 p.m. UTC | #3
On Thu, Nov 8, 2018 at 6:25 PM Peter Maydell <peter.maydell@linaro.org> wrote:
> On 8 November 2018 at 17:17, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
> >> Reported-by: LGTM code review
> >> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> >
> > 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?
Peter Maydell Nov. 8, 2018, 6 p.m. UTC | #4
On 8 November 2018 at 17:41, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> On Thu, Nov 8, 2018 at 6:25 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 8 November 2018 at 17:17, Eduardo Habkost <ehabkost@redhat.com> wrote:
>> > On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
>> >> Reported-by: LGTM code review
>> >> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> >
>> > 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
Philippe Mathieu-Daudé Nov. 8, 2018, 6:08 p.m. UTC | #5
On 8/11/18 19:00, Peter Maydell wrote:
> On 8 November 2018 at 17:41, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>> On Thu, Nov 8, 2018 at 6:25 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 8 November 2018 at 17:17, Eduardo Habkost <ehabkost@redhat.com> wrote:
>>>> On Thu, Nov 08, 2018 at 03:34:22PM +0100, Philippe Mathieu-Daudé wrote:
>>>>> Reported-by: LGTM code review
>>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>>
>>>> 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.

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.
Peter Maydell Nov. 8, 2018, 6:18 p.m. UTC | #6
On 8 November 2018 at 18:08, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> 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...

> 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
Markus Armbruster Nov. 8, 2018, 6:42 p.m. UTC | #7
Peter Maydell <peter.maydell@linaro.org> writes:

> On 8 November 2018 at 18:08, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>> 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.

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

Yes, that's rude.

[...]
Philippe Mathieu-Daudé Nov. 8, 2018, 6:48 p.m. UTC | #8
On Thu, Nov 8, 2018 at 7:43 PM Markus Armbruster <armbru@redhat.com> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> > On 8 November 2018 at 18:08, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> >> 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.
>
> > 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.

Patch
diff mbox series

diff --git a/scripts/analyse-locks-simpletrace.py b/scripts/analyse-locks-simpletrace.py
index 30090bdfff..7d9b574300 100755
--- a/scripts/analyse-locks-simpletrace.py
+++ b/scripts/analyse-locks-simpletrace.py
@@ -7,7 +7,6 @@ 
 #
 
 from __future__ import print_function
-import os
 import simpletrace
 import argparse
 import numpy as np
diff --git a/scripts/analyze-migration.py b/scripts/analyze-migration.py
index 5c2010c917..e527eb168e 100755
--- a/scripts/analyze-migration.py
+++ b/scripts/analyze-migration.py
@@ -23,7 +23,6 @@  import json
 import os
 import argparse
 import collections
-import pprint
 
 def mkdir_p(path):
     try:
diff --git a/scripts/device-crash-test b/scripts/device-crash-test
index e93a7c0c84..f459d582be 100755
--- a/scripts/device-crash-test
+++ b/scripts/device-crash-test
@@ -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
diff --git a/scripts/simpletrace.py b/scripts/simpletrace.py
index 4ad34f90cd..45485b864b 100755
--- a/scripts/simpletrace.py
+++ b/scripts/simpletrace.py
@@ -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
diff --git a/scripts/tracetool.py b/scripts/tracetool.py
index fe2b0771f2..3beaa66bd8 100755
--- a/scripts/tracetool.py
+++ b/scripts/tracetool.py
@@ -15,8 +15,6 @@  __email__      = "stefanha@linux.vnet.ibm.com"
 
 import sys
 import getopt
-import os.path
-import re
 
 from tracetool import error_write, out
 import tracetool.backend
diff --git a/scripts/tracetool/format/simpletrace_stap.py b/scripts/tracetool/format/simpletrace_stap.py
index e7e44842ca..57b04061cf 100644
--- a/scripts/tracetool/format/simpletrace_stap.py
+++ b/scripts/tracetool/format/simpletrace_stap.py
@@ -14,7 +14,7 @@  __email__      = "stefanha@redhat.com"
 
 
 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