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(-)
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(-)
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
--
2.17.2
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. -- Eduardo
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
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?
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
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.
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
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. [...]
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.
© 2016 - 2024 Red Hat, Inc.