© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
> On test plans, I see both this bug and the other one will be individually tested,
> but what's the plan to ensure that other behaviour in mutter isn't regressed?
Mutter and GNOME Shell are massive projects so the next bug is always somewhere you don't expect. I would not recommend focussing permanent test plans on any regressions that were found in 2023. Specifically addressing each one:
Bug 2026887: Caused by a narrow hardware/kernel combination. No more important than any other CPU model or kernel release.
Bug 2023759: Caused by a lack of testing remote desktop (upstream too). This could obviously be better tested but I argue the feature is too obscure to be a top-level test case we ask anyone to do on every update.
Bug 2023363: Caused by 16 milliseconds being too small a difference for most to notice.
Bug 2023766: Microstutters of a few milliseconds were a regression in 41.0 and went mostly unnoticed by everyone for several years because of how minor it is.
Bug 2017097: Caused by a combination of being too hard to notice for people who did test Raspi, and me being only one person too busy dealing with a rewrite of triple buffering caused by a last-minute upstream API redesign in 44.0.
Bug 2017137: Caused by a combination of being too hard to notice for people who did test Xorg, and me being only one person too busy dealing with a rewrite of triple buffering caused by a last-minute upstream API redesign in 44.0.
To find future regressions more effectively we need both more people testing proposed for longer, and more hardware/software combinations. Perhaps slower phasing too since such obscure bugs are so easy to miss by most people.
This isn't just a mutter issue. Almost every day I track obscure bugs back to the kernel caused by hardware combinations we simply can't expect to get tested exhaustively before every release.