Re: Migrating to the gitlab issue tracker

[Thomas Huth]

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