bug run

[Nikita Melnichenko]

Hi Krew,

I propose we spend some time cleaning up Krusader bug list. In my view, the ultimate goal is to revise all bugs that haven't been covered by the Feb bug run (i.e. haven't updated in Feb or later) or have the unconfirmed state. We have tons of bugs for kde4 version which are likely not relevant anymore (better check!) and could be closed with Resolved-Unmaintained state. Keep in mind that with v2.7 release we also dropped support for v2.5, however issues reported with this version may be still relevant.

After recent cleanups by Alex and myself, we have exactly 100 bugs open. We don't have to do it in a single approach but rather gradually revise the list when we have a few minutes. This way in a couple of months we can build a clean list. IMO, everyone will benefit from the cleaning — we will have a better picture and users will less likely file dup reports that we need to spend time replying.

Thanks in advance,
Nikita.

[Davide Gianforte]

In data martedì 15 maggio 2018 07:38:13 CEST, Nikita Melnichenko ha scritto:
> Hi Krew,
>
> I propose we spend some time cleaning up Krusader bug list. In my view,
> the ultimate goal is to revise all bugs that haven't been covered by the

> Feb bug run (i.e. haven't updated in Feb or later) *or* have the

> unconfirmed state. We have tons of bugs for kde4 version which are
> likely not relevant anymore (better check!) and could be closed with
> Resolved-Unmaintained state. Keep in mind that with v2.7 release we also
> dropped support for v2.5, however issues reported with this version may
> be still relevant.
>
> After recent cleanups by Alex and myself, we have exactly 100 bugs open

> <https://bugs.kde.org/buglist.cgi?bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&known_name=All%20Krusader%20bugs&list_id=1517265&product=krusader&query_based_on=All%20Krusader%20bugs&query_format=advanced>.

> We don't have to do it in a single approach but rather gradually revise
> the list when we have a few minutes. This way in a couple of months we
> can build a clean list. IMO, everyone will benefit from the cleaning —
> we will have a better picture and users will less likely file dup
> reports that we need to spend time replying.
>
> Thanks in advance,
> Nikita.

I agree with that, it should be a good way for 2.7.1 fixes and 2.8.0 features/bigger fixes.

Davide

[Martin Kotelnik]

I agree as well. Big thanks for all the cleaning which was already done by You guys! And also, I want to thank You, Nikita, for driving the new release to the successful finish-line :)

Martin

[Nikita Melnichenko]

Great! Thanks for supporting the clean-up and even starting to act on simple ones!

I tried to search for ways of marking the bugs we have revised. There are no much available fields in bugzilla we can play with. Ideally, it could be some special tag, however bugzilla supports only personal tags (custom but visible to one person only) and shared tags (called keywords) that come from a predefined list (defined by admin, I presume). IMO, the most relevant among existing is "triaged" keyword. I checked that we haven't used this keyword before, so we don't have to worry about initial state. I tagged a couple of bugs to give you a glimpse. This is a search for these bugs and we can make a similar for not-triaged. Please let me know what you think and if you have other suggestions.

Martin Kotelnik wrote:

And also, I want to thank You, Nikita, for driving the new release to the successful finish-line :)

It's my pleasure. Sorry it took longer than anticipated as I wanted to make it a solid release.

[Nikita Melnichenko]

Ok, since there are no objections, let's use the proposed way for the bug run and further. I'll go through the non-fixed bugs that I revised from Feb and mark them as triaged.

Things to do when you revise a bug:

1. Try to confirm it. If not repro, it may be fixed or it's a user specific issue — close with Resolved-Fixed or change to NeedsInfo-WaitingForInfo accordingly. If repro, change the state to Confirmed (if it's in Confirmed already, please write a short comment that you re-confirmed it and steps, if they are not clear).
2. If repro and Version is Git, change it to 2.7.0.
3. Adjust Importance if needed.
4. Add keyword 'triaged' and also 'reproducible' in case it's a clear repro.
   

Thanks!

[Nikita Melnichenko]

We went from 100 / 0 to 60 / 28 for non-triaged / triaged counts. Thanks
to everyone who helped around. Please review bugs whenever you have time.