![](https://secure.gravatar.com/avatar/8d5128b5b838ecedc34635fba7995f7f.jpg?s=120&d=mm&r=g)
On Tue, Jan 15, 2019 at 09:21:49PM +0100, Marc Jeanmougin wrote:
On 1/15/19 8:43 PM, Bryce Harrington wrote:
I also worry about seeing an unmanageable amount of bug reports coming in. Hopefully that doesn't happen soon.
We got 13 new bug reports just this weekend on *launchpad* (where it's harder to submit than in gitlab^^) :
1 support question ("I cannot see a dialog") 1 untestable macos issue 1 multi-duplicate of a (now fixed) cairo problem (btw, was cairo code updated in .92.4?)
Good question...
Autotools lists that it requires cairo 1.10 or newer in 0.92.4.
For cmake, I'm not spotting if we're setting a specific version requirement for Cairo, other than whatever gets pulled in by the poppler-cairo requirement.
It would probably make sense on trunk to at least require Cairo >= 1.14.0; it's been out plenty long enough so hopefully wouldn't cause much disruption, and many of the important bug fixes were backported to that series relatively recently. Cairo 1.16 is out with even more fixes, but I'm not sure that's widely propagated to distros yet.
1 about trunk, 1 translation, 1 bug on .92.3, 2 on .92.3 but does not say it (incl. one wishlist), 1 on the website, 2 probable wishlist/would-be-nice without mention of the version, 1 mailing list discussion on .92.3 (works for some, not for him), 1 visual bug
Thanks for the summary.
What will be interesting to see, is if we are able to keep on top of an influx of bug reports along these lines, since the sense has been that bug work will be easier to do on gitlab. My hope is that triager activity on gitlab will increase to match. (For reference, in gitlab we have 11 bugs reported now, with 5 closed and 6 opened - a good ratio I think, given that it's just recently been enabled.) It's still a worry for me, but I'm optimistic.
Bryce