Last modified: 2013-09-09 23:03:03 UTC
Our SVG renderer librsvg seems essentially unmaintained. The only commits for more than a year now were mainly build fixes and some minor code optimizations as you can see from GIT log [1]. No render bugs were fixed since a very long time. A decent amount of patches accumulated in the GNOME bugtracker [2], but nobody seem to be committing them. I tried to contact the developers by mail to ask if they could commit some patches but didn't receive an answer (see [3], which is a thread on GNOMES development mailing list I posted regarding the issue but didn't produce any really useful input either). Since we have a huge amount of librsvg bugs downstream [4] - some of them quite nasty - and none of them has the slightest chance of getting solved without librsvg development continuing - I hereby ask to find a solution for this problem. Since this actually blocks many bugs, I also adjusted the priority accordingly since I think this problem needs to be addressed as quickly as possible. I could think of three options right now (but maybe someone else has other ideas): 1) Get bug 38010 fixed (Re-evaluate librsvg as SVG renderer on Wikimedia wikis) 2) Recruit a WMF employee or a volunteer with commit rights to GNOME Git who maintains librsvg for us 3) Establish contact to the current maintainers (and hope they'll have some spare time to donate for the good of Wikipedia). [1] https://git.gnome.org/browse/librsvg/log/ [2] https://bugzilla.gnome.org/page.cgi?id=patchreport.html&product=librsvg&patch-status=none [3] https://mail.gnome.org/archives/desktop-devel-list/2013-April/msg00313.html [4] https://bugzilla.wikimedia.org/buglist.cgi?component=SVG rendering
Related: bug 38010.
This falls into the "upstream relationships category" - CC'ing Quim. > Since this actually blocks many bugs, Well, we can theoretically maintain downstream patches. Or convince the Debian/Ubuntu packagers to get them in. But of course, GNOME upstream would be the best. (In reply to comment #0) > 2) Recruit a WMF employee or a volunteer with commit rights to GNOME Git who > maintains librsvg for us "Find a person to take over project third-party upstream project X" feels like out of scope for handling in Wikimedia Bugzilla (though it can be a totally valid request). Do you have anybody in mind?
If librsvg is unmaintained and the GNOME project doesn't provide answers about it then I believe the answer is to start making noise about this and start looking for an upstream alternative, not to become upstream ourselves. Our core mission is well away from developing SVG rendering tools. I hope there are other open source stakeholders out there either willing to step in or working on alternatives. Then again this is a Platform discussion so I'm CCing Rob.
(In reply to comment #2) > Do you have anybody in mind? No sorry. I hoped that someone commenting on this bug might know somebody who's the right person for the job.
(In reply to comment #0) A decent amount of patches accumulated in the > GNOME bugtracker [2], but nobody seem to be committing them. That url is slightly misleading. by my count, only 11 out of the 22 patches listed there are actual patches that are waiting on someone to review them. Most of the others have either negative reviews, or aren't real patches. Obviously that doesn't change the fact that librsvg isn't exactly getting as much love as we would want it to.
