It's a little frustrating reading the reviews from prominent designers in the FOSS community. People seem to be quite upset that this was "an official release", loudly blaming Open Source for this one bug in Inkscape. (Are people really surprised that there are bugs in Inkscape at this point?)
This is not to excuse the fact that line height is messed up, but maybe something needs to be done about integrating the publicly blogging career artists into having a look at the pre-release well before the release actually happens, and providing useful feedback at that point, so we don't get blamed for the collective woes of FLOSS.
I'd like to thank everyone for the hard work, and the hurry. I got that the intent of this release was to provide new features some long standing bug fixes, and to get mesh gradients working to try and push them into the SVG spec before the world gives up entirely on making SVG better.
This is an insider view, however. Maybe it's time to bring more prominent FLOSS artists into the fold. I can help with outreach if necessary.
-C
On Sat, Jan 21, 2017 at 10:39 AM, Marc Jeanmougin <marc@...3062...> wrote:
On 01/21/2017 05:55 AM, Martin Owens wrote:
There's a couple of possibilities:
- The bug wasn't discovered in time
- The bug wasn't reported in time
- The reported bug wasn't triaged in time
- The bug wasn't prioritised as important
- There wasn't a way to communicate a major issue to the release
manager. 6. We just didn't have the resources to do the release properly and let things slide.
What information can Mc and su_v add about the issue? What can we fix to make the process better?
I'd say mostly 4+6. The bug was discovered in pre2, reported (several times) and triaged in pre3, but classified as "Medium"[0]
Medium is "moderately serious incorrect behavior that is likely to affect many users"[1]. The criteria for bug severity management might be a bit too subjective, I think: is "text lines are displaced" moderately serious ? very serious ? IMHO, anything that changes what the output of "inkscape $file.svg -e $file.png" for any file by more than a few pixels should be considered with "critical" priority: This means it can break any files created in the past.
The drawback of having "millions of users" but half a dozen devs is that the diversity of files "out there" created and managed with inkscape is probably far ahead of what we could possibly test and shipping a version with such a defect would feel like if there was a version of gcc that shipped, mostly fine but changed the semantics of some of my code.[4]
What affects "many" or "most" users is also subjective: If you don't use a feature at all (some people do not use LPE, some people do not use texts, no one uses 3d boxes), at the same time you'll be less likely to notice the regression, and to consider it as important. About this, I'd favour developing automated rendering tests after the git migration. A few files with all existing inkscape features used in them, ideally created with a variety of old templates, and automatically running inkscape on them when comitting + comparing to the normal rendering (I think it might be possible with git pre-receive hooks(?)). Wrt "blocker": [2] was proposed as a blocker (in november); and discussed quickly at the at the board meeting of dec 02 [3].
In hindsight, it might have been better to choose "delay the release" instead of "document the issue / start targeting it for .92.1". IIRC, there was some time pressure with a small timeframe to launch before a next debian or ubuntu feature freeze (Debian stretch Jan 5?), so that may count as "we did not have the resources to do the release properly" ? We were also, at the time, quite focused on wanting to spread the mesh functionality, fast, with as few bugs as possible, with it having only been tested in trunk and the last RC. That we managed to sort of do it is probably a feat, but it might have come with the cost of letting that regression slide, considering our limited manpower.
(tldr on suggestions: every rendering change of old files treated as critical; automating tests)
===== [0] https://bugs.launchpad.net/inkscape/+bug/1642133 [1] https://inkscape.org/en/develop/bug-management/#Bug_importance [2] https://bugs.launchpad.net/inkscape/+bug/1645016 ===[3]=== 22:54 < su_v> users of 0.92 will face trouble with (relative) line heights in "legacy" files (due to the changes in 0.92.x to base that on parent <text> style 22:54 < bryce> 3 weeks would give us a Christmas release, which might be nice 22:54 < su_v> ) 22:54 < bryce> otherwise we got holiday breaks and stuff, pushing us to like 1st or 2nd week of Jan 22:55 < su_v> will this be a FAQ (as in: redo the file in 0.92.x, or don't upgrade), or are there other options? 22:56 < Tavmjong> su_v: Can you give me some sample files that will have problems with line heights? 22:57 < bryce> su_v, at this point the options are document the issue, or postpone the release 22:57 < su_v> Tavmjong: I can give the steps to reproduce (it can be observed in 0.92x itself, too) 22:57 < su_v> Tavmjong: steps after the meeting 22:58 < jabiertxof> to me this line height problem could be a blocker https://bugs.launchpad.net/inkscape/+bug/1645016 22:58 < bryce> please no more blockers! :-) 22:59 < bryce> but 0.92.1 is certainly something we can start targeting with some of these more serious issues 22:59 < su_v> no one will dare to declare a bug as blocker anymore 23:00 < jabiertxof> jabiertxof block his block 23:00 < Tavmjong> jabiertxof: I can have a look next week after the mesh/dpi stuff is done. ====== [4] I don't think that comparison is exagerated : Imagemagick's "convert" uses inkscape if found, so right now, anyone upgrading inkscape and using convert in scripts, will have grave regressions when automatically rendering svg that contain text, e.g. on web servers (I'm thinking about mediawiki here:https://www.mediawiki.org/wiki/Manual:$wgSVGConverters ). Just to insist, if it's installed there, that update might do no less than break every diagram,map,etc on wikipedia.
-- Marc
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel