1. Dec 02 13:23:40 <bryce> ============= Release Meeting ==============
  2. Dec 02 13:23:43 <tedg> Thanks folks!
  3. Dec 02 13:23:56 * tedg didn't mean to interrupt the release meeting, sorry!
  4. Dec 02 13:24:00 <tedg> :-)
  5. Dec 02 13:24:05 <bryce> like doctormon2 says I think we covered a bunch on the mailing list, and I need to digest and follow up on a few items there
  6. Dec 02 13:24:38 <bryce> so here we can have open discussion on whatever :-)
  7. Dec 02 13:24:48 <tedg> I'd love to know if anyone has tried the snaps besides me.
  8. Dec 02 13:24:49 <bryce> prkos, so: meshes?
  9. Dec 02 13:25:04 <doctormon2> we've got people more trained on uploading the packages. so I feel the web is ready for the release.
  10. Dec 02 13:25:07 <tedg> They work for me :-)
  11. Dec 02 13:25:27 <bryce> tedg, I make sure they build and launch but haven't spent much time doing actual testing
  12. Dec 02 13:25:55 <tedg> bryce: I was meaning snappy packages, not snapshots
  13. Dec 02 13:25:55 <prkos> I saw nodes are now colored differently from handles but will we also get an easy way to see which handels belong to which nodes?
  14. Dec 02 13:26:36 <tedg> bryce: Though, if you're building snappy packages I'd be impressed ;-)
  15. Dec 02 13:26:51 <Tavmjong> prkos: jabiertxof has a patch that is essentially ready. The handles for selected corners turn into triangles pointing towards the corner nodes.
  16. Dec 02 13:27:12 <prkos> in trunk?
  17. Dec 02 13:27:24 <bryce> tedg, ah, sorry
  18. Dec 02 13:27:28 <prkos> clever BTW
  19. Dec 02 13:27:29 <Tavmjong> Not yet in trunk... give it a couple of days.
  20. Dec 02 13:27:41 <prkos> thank you?
  21. Dec 02 13:27:47 <prkos> *!
  22. Dec 02 13:27:50 <bryce> :-)
  23. Dec 02 13:27:59 <Tavmjong> You can try the mesh_and_knot branch. (The work was done by jabiertxof )
  24. Dec 02 13:28:18 <prkos> k ty
  25. Dec 02 13:28:20 <su_v> https://code.launchpad.net/~inkscape.dev/inkscape/knot_improvements
  26. Dec 02 13:28:40 <bryce> Tavmjong, any changes to report on the SVG 2 folks willingness to include the feature?
  27. Dec 02 13:28:48 <jabiertxof> now are split in 2 branches
  28. Dec 02 13:28:49 <su_v> ^^ jabiertxof's branch for mesh handle knots
  29. Dec 02 13:28:54 <Tavmjong> Other than that, the mesh stuff is done. All the significant bugs reported have been squashed as well as a whole bunch of GUI improvements.
  30. Dec 02 13:29:15 <su_v> Tavmjong: no progress on the memleak?
  31. Dec 02 13:29:17 <jabiertxof> https://code.launchpad.net/~inkscape.dev/inkscape/mesh_improvements
  32. Dec 02 13:29:25 <Tavmjong> bryce: It's not the SVG 2 folks (they are behind it), it's the browser folks.
  33. Dec 02 13:29:38 <su_v> that's a major blocker for me to even play with bicubic smoothing
  34. Dec 02 13:29:53 <su_v> inkscape quickly requires over 1GB mem for the simplest file
  35. Dec 02 13:30:24 <Tavmjong> su_v: I can have another look. As far as I can tell, it's a leak with gradients in general which hits meshes harder than linear/radial gradients.
  36. Dec 02 13:30:46 <bryce> Tavmjong, ok noted. Are the browser folks aware yet that we'll be shipping the feature?
  37. Dec 02 13:30:46 <su_v> and it's also exposed with coons patches, though it takes much longer (or much larger meshes) to get there
  38. Dec 02 13:30:57 <jabiertxof> fist knot_improvements and next mesh_improvements
  39. Dec 02 13:31:24 <jabiertxof> mesh_improvements require knot_improvements
  40. Dec 02 13:31:27 <Tavmjong> bryce: No. But that won't have much of an impact at first. Adobe is looking at supporting it but we haven't heard back from them yet.
  41. Dec 02 13:31:45 <Tavmjong> If Adobe supports it then it will stay in SVG 2 for sure.
  42. Dec 02 13:32:12 <doctormon2> might be worth asking Firefox out of band. they should be available to listen at least.
  43. Dec 02 13:32:19 <Tavmjong> I still don't have a good feeling about the future of SVG 2.
  44. Dec 02 13:32:37 <Tavmjong> doctormon2: A couple of years ago there was someone at Firefox interested.
  45. Dec 02 13:33:12 <Tavmjong> But I don't think Firefox is pushing SVG at the moment.
  46. Dec 02 13:33:48 <doctormon2> sure, but if they can promise to support, it'll add weight
  47. Dec 02 13:34:14 <Tavmjong> We're suppose to get a list of features Firefox wants to support soonish.
  48. Dec 02 13:34:41 <su_v> Tavmjong: what perspective/choices/options do you see for inkscape's choice of file format? (if SVG2 is "doomed")
  49. Dec 02 13:34:44 <bryce> hrm, I wonder if maybe one day we'll have to consider doing our own file format
  50. Dec 02 13:34:58 <tweenk> bryce: let's not do that
  51. Dec 02 13:35:34 <tweenk> bryce: if it weren't for technical debt, we could easily any weird feature we want and store it with proper SVG fallback
  52. Dec 02 13:35:37 <Tavmjong> I think keeping compatibility with SVG is important. We can keep a lot of stuff in our namespace and/or provide polyfills for the features we really want.
  53. Dec 02 13:35:44 <doctormon2> even if we do svg+, compat is useful and important.
  54. Dec 02 13:36:10 <tweenk> If Inkscape ever abandoned SVG compatibility, it would quickly become irrelevant
  55. Dec 02 13:36:22 <bryce> well, discussion for some other day.
  56. Dec 02 13:36:24 <Tavmjong> I agree with tweenk on this.
  57. Dec 02 13:36:29 <tweenk> (at least that's my feeling)
  58. Dec 02 13:37:28 <doctormon2> I hope we can be more flexible with our format. so, rendering in browsers is important. but editing is not. adding multiple pages and visio connectors should be done our end
  59. Dec 02 13:37:33 <bryce> alright, so anything else on meshes?
  60. Dec 02 13:37:38 <Tavmjong> tweenk: How are you at hunting memory leaks?
  61. Dec 02 13:38:04 <bryce> thanks for the feedback on the dpi bug, I look forward to seeing that get resolved, thanks Tav for pitching in there
  62. Dec 02 13:38:44 <doctormon2> +1 on thanks to tav and Javier on recent improvements
  63. Dec 02 13:38:45 <Tavmjong> bryce: Meshes should be ready to go in the next few days... in a worse case scenario we could disable Bicubic patches for this release (if su_v think it is a real problem).
  64. Dec 02 13:38:54 <bryce> afaik the other 'blockers' are lower priority, if we can close that one I say we leave the others as known issues and finish off the release
  65. Dec 02 13:39:38 <Tavmjong> We should have the dpi patches in also in the next couple of days... (might be Monday or Tuesday as my weekend is busy).
  66. Dec 02 13:39:38 <bryce> Tavmjong, yes I am keeping a close eye on su_v's thumb :-)
  67. Dec 02 13:39:43 <su_v> bryce: do you care (as release manager) about consistency across the supported build systems shipped with the tarball?
  68. Dec 02 13:40:07 <bryce> su_v, that is a good question
  69. Dec 02 13:40:16 <Tavmjong> Note, the dpi patches will add strings that need translating.
  70. Dec 02 13:40:45 <su_v> bryce: there's also a requested patch (mentioned in that one blocker bug) which hasn't been reviewed (re preferences for broken layout option)
  71. Dec 02 13:41:15 <su_v> I did update the bug description with a recent state of all build systems
  72. Dec 02 13:41:17 <bryce> su_v, offhand, I wouldn't consider it a major worry if there were some discrepancies; I don't have expectations that things should be exactly apples-to-apples. But I do think the autoconf builds should be viable.
  73. Dec 02 13:41:30 <su_v> cmake is inconsistent in itself atm, and other build systems partially not insync
  74. Dec 02 13:41:56 <su_v> bryce: so you'd triage bug reports from distros which use autotools and have non-release stuff enabled?
  75. Dec 02 13:42:28 <bryce> Tavmjong, the string translations are unfortunate. If there's no way to avoid them, maybe just notify translators ASAP with apologies, and strive not to change them after?
  76. Dec 02 13:42:38 <su_v> I'm sure MacPorts isn't the only one not switching to cmake this time (they might, I don't know - just watching occasionally)
  77. Dec 02 13:43:28 <su_v> the default configure options are minor changes AFAICT - it just needs to be done in time (and tested)
  78. Dec 02 13:43:41 <bryce> su_v, I would insofar as the bugs were valid concerns worth considering for inclusion in a 0.92.1 point release
  79. Dec 02 13:43:45 <Tavmjong> bryce: Will have the strings locked down soon.
  80. Dec 02 13:43:50 <su_v> why for example is all SVG2 stuff disabled for btool builds?
  81. Dec 02 13:44:20 <bryce> su_v, but keep in mind autotools is legacy so we have to draw a high line on how much time we want to invest there. "ordinary" bugs that aren't relevant to trunk are unlikely to be worth triaging.
  82. Dec 02 13:44:24 <su_v> bryce: why expose users to troubles with broken LPEs which won't be supported in either a bug fix release or a future stable release?
  83. Dec 02 13:44:38 <su_v> or anyone building locally from tarball with other build system than cmake?
  84. Dec 02 13:44:50 <su_v> why then ship the release with those build systems in place?
  85. Dec 02 13:45:46 <bryce> su_v, you are so good at keeping us straight :-)
  86. Dec 02 13:46:10 <bryce> su_v, well, main reason to ship the build systems is so we're not pulling the rug out from under people for whom cmake might not be feasible
  87. Dec 02 13:46:25 <bryce> I can't imagine there being many such people, cmake is pretty mainstream, but shit happens :-)
  88. Dec 02 13:46:59 <bryce> but like I said, autotools and btool builds are legacy, and users of those should not be surprised if there are irregularities. They should be migrating to cmake.
  89. Dec 02 13:48:24 <bryce> su_v, I do think we should remove or hide broken functionality esp. stuff that's been added since the last release.
  90. Dec 02 13:49:34 <bryce> ok, final discussion item, non-technical :-)
  91. Dec 02 13:49:45 <bryce> press release writing and marketing efforts
  92. Dec 02 13:50:13 <prkos> what's the timeline?
  93. Dec 02 13:50:15 <bryce> in the past we've assembled a temporary team for tackling these items. We've got a fairly good wiki page set up from last time, it's almost paint by numbers
  94. Dec 02 13:50:33 <jabiertxof> We do a RC4?
  95. Dec 02 13:50:44 <bryce> prkos, sounds like we've got at least a couple weeks for the next RC, plus maybe a week or so after that before we could feasibly do a release
  96. Dec 02 13:50:52 <bryce> so minimum 3 weeks, maybe more?
  97. Dec 02 13:51:02 <prkos> so next year?
  98. Dec 02 13:51:21 <bryce> that sounds so far off...
  99. Dec 02 13:51:26 <su_v> bryce: probably you should have closed that report as 'Won't Fix' (in lack of 'No interest'), and removed the blocker tag right away. I'm not motivated to upload patches (assuming that they also will be ignored).
  100. Dec 02 13:51:35 <jabiertxof> In january debian launch stretch
  101. Dec 02 13:51:43 <Tavmjong> jabiertxof: We need to do RC4 after the your mesh and dpi changes are in.
  102. Dec 02 13:51:57 <prkos> Christmas release
  103. Dec 02 13:51:59 <jabiertxof> Great!
  104. Dec 02 13:53:21 <bryce> Tavmjong, would 1 week until RC4 be feasible?
  105. Dec 02 13:53:35 <Tavmjong> bryce: I think so.
  106. Dec 02 13:53:44 <bryce> I'd be more comfortable with 1 week RC4 + 2 week release than vice versa
  107. Dec 02 13:53:48 <Mc> might need a bit more time to translate dpi switch strings
  108. Dec 02 13:54:16 <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
  109. Dec 02 13:54:17 <bryce> 3 weeks would give us a Christmas release, which might be nice
  110. Dec 02 13:54:19 <su_v> )
  111. Dec 02 13:54:49 <Tavmjong> Mc: But translating strings isn't likely to break something so they could be patched after RC4.
  112. Dec 02 13:54:54 <Mc> sure
  113. Dec 02 13:54:59 <bryce> otherwise we got holiday breaks and stuff, pushing us to like 1st or 2nd week of Jan
  114. Dec 02 13:55:08 <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?
  115. Dec 02 13:56:07 <jabiertxof> https://wiki.debian.org/DebianStretch
  116. Dec 02 13:56:21 <jabiertxof> 01/05
  117. Dec 02 13:56:45 <jabiertxof> I think we need get into sooner
  118. Dec 02 13:56:49 <Tavmjong> su_v: Can you give me some sample files that will have problems with line heights?
  119. Dec 02 13:57:12 <bryce> su_v, at this point the options are document the issue, or postpone the release
  120. Dec 02 13:57:23 <su_v> Tavmjong: I can give the steps to reproduce (it can be observed in 0.92x itself, too)
  121. Dec 02 13:57:33 <su_v> Tavmjong: steps after the meeting
  122. Dec 02 13:58:23 <jabiertxof> to me this line height problem could be a blocker https://bugs.launchpad.net/inkscape/+bug/1645016
  123. Dec 02 13:58:49 <Tavmjong> BTW Fedora 25 already has 0.92pre2
  124. Dec 02 13:58:57 <bryce> please no more blockers! :-)
  125. Dec 02 13:59:11 <Mc> yeah, the guy doing the updates did came asking for help here
  126. Dec 02 13:59:22 <bryce> but 0.92.1 is certainly something we can start targeting with some of these more serious issues
  127. Dec 02 13:59:26 <su_v> no one will dare to declare a bug as blocker anymore
  128. Dec 02 13:59:37 <Mc> (had to add libpotrace and scour separetely)
  129. Dec 02 14:00:16 <jabiertxof> jabiertxof block his block
  130. Dec 02 14:00:52 <Tavmjong> jabiertxof: I can have a look next week after the mesh/dpi stuff is done.
  131. Dec 02 14:01:17 <jabiertxof> great
  132. Dec 02 14:01:27 <jabiertxof> thanks
  133. Dec 02 14:01:37 <bryce> alright, anything else to discuss?
  134. Dec 02 14:01:51 <Tavmjong> su_v: I need to go now. Ping me this weekend or Monday about the line height problem.
  135. Dec 02 14:02:50 <jabiertxof> Bye Tavmjong
  136. Dec 02 14:03:02 <Tavmjong> Goodnight (or Goodday) all.
  137. Dec 02 14:03:18 <bryce> alright, thanks all!
  138. Dec 02 14:03:24 <bryce> =========== EOM ==================
  139. Dec 02 14:03:33 <su_v> Tavmjong: example https://dl.dropboxusercontent.com/u/65084033/irc/drawing-091.svg (compare rendering in 0.91 and 0.92.x)
  140. Dec 02 14:03:36 <prkos> thank you jabiertxof and Tavmjong for your meshes work :-*
  141. Dec 02 14:04:00 <jabiertxof> you are welcome prkos
 
 

31

 

925

Release Meeting - December 2, 2016

-

PasteBin

Линии
141
Слова
2261
Размер:
13,2 КБ
Создан:
Тип:
text/x-irclog
Creative Commons Attribution Share-Alike 3.0 (CC-BY-SA 3.0)
Пожалуйста, войдитев систему, чтобы оставить комментарии!