| Message ID | 20181108143422.15955-1-philmd@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | scripts: Remove unused python imports | expand |
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.
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.
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
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(-)