Anchoring bug reports

[Ilmari Lauhakangas]

Telesto kirjoitti 4.8.2020 klo 22.29:
> I have created quite an amount bug reports related to object/image 
> anchoring. They current value of those is 0, as they basically 
> demonstrate nothing new. It are simply different expressions/ examples/ 
> consternations/ showcases of the same underlying problem (as far I’m 
> able to tell).
> However the might become handy if someone some day decides to work on 
> this. It will give QA and they developer a number of test cases for 
> analysis and testing. And easier to running into them, compared to 
> creating them on demand; so more documentation of test cases.
> They other view is of course that i’m repeating myself, bloating the 
> bugtracker with useless reports/ samples wasting QA time (as the 
> currently got to formal conformation process) and ruining they QA stats 
> (UNCONFIRMED bugs).
> As bugtracker is servicingthe needs of Developers, it more or less based 
> on the desires of the developers.
> A) Are repeated reports (variants) of any use from developer point of 
> view (for specific this case)
> B) If so, how can those they best be processed. I like them 
> separateinstead of posting them in one bug report (unpracticalmess) or 
> stacking them up to a bug as duplicate (risk of getting lost). They 
> could be placed under separate meta within anchoring wrap meta. However 
> the meta is still reasonable sized, so that urgent from my point of view.
> C) Is there a new category needed for those examples, as numbers of they 
> bugtracker don’t represent they actual number of problems. Bugs being 
> set to NEW without being NEW in the sense of reporting anything new.
> Sidenote: I’m don’t intend to add more; as I think I covered they 
> terrain a pretty good (maybe even one or to duplicates)

As a minimum, if the issue is a regression, you could bibisect before 
creating a new report and do a search on all open or closed reports for 
the blamed commit hash in comments.

Ilmari