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 _______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
