From: Thomas Huth <thuth@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
"John Snow" <jsnow@redhat.com>,
"Cornelia Huck" <cohuck@redhat.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Alistair Francis" <alistair23@gmail.com>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: Migrating to the gitlab issue tracker
Date: Mon, 9 Nov 2020 09:04:29 +0100 [thread overview]
Message-ID: <bef46169-9fec-eaff-5606-18d355cde0d6@redhat.com> (raw)
In-Reply-To: <CAFEAcA_dT_RQ8Pmk_S=zCSu1tUbptuP0+rtrsS55tEg+XD=S2Q@mail.gmail.com>
On 08/11/2020 12.58, Peter Maydell wrote:
> On Sun, 8 Nov 2020 at 09:01, Thomas Huth <thuth@redhat.com> wrote:
>> I agree with Daniel. Please let's not clog the new bug tracker right from
>> the start with hundreds of bugs - that only makes it harder to focus on the
>> tickets that are really important. Let's use the migration instead to start
>> as clean as possible again.
>
> I really don't like doing this kind of thing. It basically
> tells bug reporters "we don't care about your reports".
But all those bugs that got stale and did not receive an answer within years
certainly give the same impression to the reporters.
> We ought to at least triage them. Certainly for arm a
> lot of the reports in LP are real bug reports which we
> shouldn't just drop on the floor.
Ok, then let's do it this way:
- Let's do *not* automatically close bugs directly
- Let's try to do at least some basic triage. If bugs are
obviously still present, there is no need to mark them
as incomplete. For all other bugs, let's ask whether they
are still important and mark them ask incomplete so that
they can expire if nobody cares anymore.
- Should I assign opened arm bugs that I find along the way
to you, Peter, so you can triage them?
- Let's not auto-migrate any bugs within the next weeks and
wait 'till the LP bug triage has been done.
- I think we could already update the links on the website
to the new bug tracker at gitlab to get some more experience
with the new bug tracker. That of course means that we would
be using two bug tracker during the next weeks or months,
but I think that's ok if we set a final date for the complete
switch (e.g. at the end of the LP bug expiration period, so
something like January 2021)
Sounds like a plan?
Thomas
next prev parent reply other threads:[~2020-11-09 8:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-29 16:01 Migrating to the gitlab issue tracker John Snow
2020-10-29 16:30 ` Daniel P. Berrangé
2020-10-29 16:41 ` Cornelia Huck
2020-10-29 16:49 ` Alistair Francis
2020-10-29 17:12 ` John Snow
2020-10-29 17:36 ` Kashyap Chamarthy
2020-10-29 19:55 ` Thomas Huth
2020-10-29 20:27 ` John Snow
2020-10-30 9:23 ` Daniel P. Berrangé
2020-10-30 10:03 ` Peter Maydell
2020-10-30 10:10 ` Daniel P. Berrangé
2020-10-30 10:57 ` Peter Maydell
2020-11-05 0:06 ` John Snow
2020-11-05 6:14 ` Thomas Huth
2020-11-05 9:54 ` Daniel P. Berrangé
2020-11-05 15:44 ` John Snow
2020-11-05 15:50 ` Daniel P. Berrangé
2020-11-08 9:00 ` Thomas Huth
2020-11-08 11:58 ` Peter Maydell
2020-11-09 8:04 ` Thomas Huth [this message]
2020-11-09 10:10 ` Daniel P. Berrangé
2020-11-09 10:14 ` Peter Maydell
2021-01-21 10:57 ` Thomas Huth
2021-01-21 16:20 ` John Snow
2020-10-30 10:26 ` Alex Bennée
2020-10-30 12:53 ` John Snow
2020-11-08 8:57 ` Thomas Huth
2020-10-29 18:04 ` John Snow
2020-10-29 20:33 ` Cornelia Huck
2020-10-30 9:16 ` Stefan Hajnoczi
2020-10-30 15:39 ` John Snow
2020-11-02 13:57 ` Laszlo Ersek
2020-11-02 14:26 ` Daniel P. Berrangé
2020-11-02 14:42 ` Eric Blake
2020-11-04 17:10 ` Laszlo Ersek
2020-11-04 17:03 ` Laszlo Ersek
2020-11-04 17:19 ` Daniel P. Berrangé
2020-11-06 15:37 ` Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bef46169-9fec-eaff-5606-18d355cde0d6@redhat.com \
--to=thuth@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=alistair23@gmail.com \
--cc=berrange@redhat.com \
--cc=cohuck@redhat.com \
--cc=jsnow@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).