On Wed, 2019-04-03 at 00:26 +0200, Maren Hachmann wrote:

Added the eqtexsvg info to the release notes. Do we know how many people were depending on it for their LaTeX typesetting? Could we maybe ask for external testing, if testing via CI isn't possible?

That's a part of the question. Can we ship extensions that don't work by default? I think that's what the inx is designed to allow but it doesn't do much for our sanity.

This would be made better by the future extensions manager, as such extensions could be held outside of inkscape's dist until the users needs them and asks for them.

Would we be willing to wait for that for these extensions?

Martin,

Am 03.04.19 um 00:37 schrieb doctormo@...400...:

On Wed, 2019-04-03 at 00:26 +0200, Maren Hachmann wrote:

...

Added the eqtexsvg info to the release notes. Do we know how many people were depending on it for their LaTeX typesetting? Could we maybe ask for external testing, if testing via CI isn't possible?

That's a part of the question. Can we ship extensions that don't work by default? I think that's what the inx is designed to allow but it doesn't do much for our sanity.

- Aren't there some that are specific to the operating system already?

There are a lot of those that depend on other programs, that show up in the error log. Like Gimp export, if you don't have gimp installed, etc.

Not sure what's special about LaTeX, compared with Gimp, or Xfig, or Dia...? It's used by a different set of people, but aside from that?

This would be made better by the future extensions manager, as such extensions could be held outside of inkscape's dist until the users needs them and asks for them.

Would we be willing to wait for that for these extensions?

- Not really. I think it would be a mistake to drop LaTeX support - just like the dropped plt export is an issue for those who depend on it. People who need these will likely be quite angry with us if they updated and can't find the functionality anymore ... There aren't as many of them, of course, as the last time, when we broke text.

I'm worried about the project looking like every major version has some major issue, that makes it useless for a specific user group.

You could try recruiting testers on the user mailing list or on the chat.

Maren

Martin,

Thanks Bryc

On Mon, 2019-04-08 at 09:46 -0700, Bryce Harrington wrote:

On Mon, Apr 01, 2019 at 10:15:24PM -0400, doctormo@...400... wrote:

...

Extensions 1.0 - 2019-03-24 to 2019-04-01

I've completed a very exausting slog through all of our extensions for the Inkscape 1.0 release. Below is a detailed report on where we currently stand with our extensions repository.

Thanks for putting this list together.

Am I adding things up correctly, that there are 149 total dependencies, of which 95 (64%) are in perfect shape?

Of the remaining 56, then, half work but produce different output, and the other half we either don't know how to test it or the extension has other troubles.

The work that's gone into the extension repository so far has been long needed. We've accepted extensions with a wide diversity of coding standards (including a lot of messy cut-and-paste coding), so this effort ups our game in a big way here. We've never required extensions to include testing, so establishing testability at any level is a huge advance. This effort will make our core extensions much more maintainable through the future.

It would be nice to get all of these old extensions to 100% perfect in our new processes, however that may be too unrealistic in a practical timeframe. "Perfect is the enemy of the good". So, what if we did a bit of triage on this list? Some extensions may not be that important to users and could be moved to branches (with corresponding bug reports so we don't forget about them.)

Perhaps a the goal of 95% working with perfect test matches could be set for us to start the beta release? That would be a significant improvement over 64%, but still leave breathing room for problematic extensions. That number could be reached by:

a) Writing and improving tests for important extensions b) Fixing extensions with bad test results c) Dropping unimportant extensions with bad or no tests d) Bringing in some new extensions (boosting the denominator)

...

There are some decisions to make wrt how we support dependancies, how we test extensions that call out to outside programs and how we fix the remaining issues.

Extensions that rely on external programs do sound like they'll be particularly tricky to test. On the other hand, my guess is that many of these enable interoperability with other applications, or do file format conversion, both of which are going to be of high importance to chunks of our userbase.

So, while difficult, figuring out an effective way to do testing of these would be hugely valuable.

...

== Overview ==

• 23 Extensions without comparison tests

• 119 Added Comparison Tests

• 0 Causing an Error (all fixed)
• 95 Working extensions with perfect matches
• 24 Failed to match (output is different)

• 7 Missing, Removed or untestable extensions

• 1 Delayed fix because of Merge Request
• 1 None Inkex based python extension
• 4 Removed extensions
• 1 Windows extension

=== Failed Extensions ===

Large number of differences or just borked:

• perspective, pixelsnap

Large number of differences or format is not svg:

• dpiswitcher, extrude, dxf_outlines, hpgl_output

Guessing these extensions are important for plotting/engraving?

...

Medium number of differences related to path transformatons:

• foldablebox, polyhedron_3d, summersnight

These sound fairly specialized? Maybe not as crucial?

...

Medium number of differences, various attributes missing from output:

• grid_polar, grid_cartesian, lindenmayer, whirl

The first two are probably of more general usefulness than the latter two, but guessing all four would have some value in bringing up to date.

...

Tiny or single difference related to finding layer center:

• render_barcode, render_barcode_datamatrix,

render_barcode_qrcode, render_gear_rack, render_gears, spirograph, split, triangle, wireframe_sphere, grid_isometric, hershey

Sounds like these are the low hanging fruit of this list, and some of those we know are high importance.

...

=== Removed: External dependancy, shell script (not python) ===

• eqtexsvg, plt_output, sk1_output, wmf_output,

Are these the uniconverter based extensions? Are there any others?

A question is whether people are actively using these file formats.

...

=== Other ===

gcodetools - Held up because of merge request, cleanup is very large.

May be worth pushing through on this one.

...

dm2svg - None inkex python extension, could be converted

"import a DHW file from ACECAD DigiMemo". I'm not sure what that is so no idea on its importance, but looks like Thomas Holder did some work on it so presumably it's close?

...

print_win32_vector - Windows only (untestable) but also an infurating copy of dxf_outlines.py AND untestable because it requires access to printers to print things.

Looks like it hooks into winspool.drv and gdi32.dll, that may become hard to test even on windows going forward. Is it possible this is not used much? If so, then this might be a good candidate to move out of the main repo to a branch.

...

=== Extensions without comparison tests ===

color_randomize, dxf12_outlines, fractalize, frame, generate_voronoi, gimp_xcf, inkwebeffect, interp_attr_g, jitternodes, layout_nup, loren_ipsum, markers_strokepaint, measure, pathmodifier, pathscatter, prepare_file_save_as, print_win32_vector, render_alphabetsoup, rtree, rubberstretch, synfig_output, synfig_prepare, text_randomcase

Are color_randomize, fractilize, generate_voronoi, jitternodes, pathscatter, and text_randomcase problematic due to their use of randomness? Would adding support for fixed seeding help make testing them more tractable?

Several of the others are file format or external app interop extensions, so may be difficult to test for that reason (but still important to give attention to.)

Of the remainder, those sound like priorities for doing test work on, they may be reasonably straightforward to get off this list.

...

== Work Done ==

• Unit Tests: 149 files changed, 1311 insertions(+), 1462

deletions(-)

• Test Framework: 3 files changed, 308 insertions(+), 23

deletions(-)

• Extensions: 57 files changed, 862 insertions(+), 1185

deletions(-)

• Inkex API: 9 files changed, 216 insertions(+), 40 deletions(-)

Thanks again for this list, hoping progress continues strong so we can get this resolved and proceed with the release. Keep us updated, I'd like to keep track of what percentage of the extensions are considered perfect, so I have a feel for roughly when we'll be hitting 85, 90, and 95%.

Bryce

Ok, so with those improvements and triages, it's changed from 95/149 (64%) to 119/142 (84%)? That's very good progress.

From today's discussions, moving uniconvertor to a separate repository

sounds like it's the right move. And sounds like a good idea to leverage it for testing of the extensions manager.

Bryce

On Mon, Apr 08, 2019 at 11:58:52PM -0400, doctormo@...400... wrote:

Sorry for the incomplete messages, evolution decided to devolve.

---

Thanks Bryce,

I have an updated list. Currently tests are passing for python2 and python3 for all comparison tests.

• 23 Extensions without comparison tests
• 119 Added Comparison Tests

• 0 Causing an Error (all fixed)
• 119 Working extensions with perfect matches (some of our output was

actually better and more consistent than 0.92)

As you know bryce we've put the uniconvertor extensions into their own repository on GitLab and they're actually one of the trial packages for the new Inkscape Extensions Manager.

There was one extension that opens up a serial port to a piece of hardware... that's a bit of a bs to test.

But all other parts of the report are the same so far.

Best Regards, Martin Owens

On Mon, 2019-04-08 at 09:46 -0700, Bryce Harrington wrote:

...

On Mon, Apr 01, 2019 at 10:15:24PM -0400, doctormo@...400... wrote:

...

Extensions 1.0 - 2019-03-24 to 2019-04-01

I've completed a very exausting slog through all of our extensions for the Inkscape 1.0 release. Below is a detailed report on where we currently stand with our extensions repository.

Thanks for putting this list together.

Am I adding things up correctly, that there are 149 total dependencies, of which 95 (64%) are in perfect shape?

Of the remaining 56, then, half work but produce different output, and the other half we either don't know how to test it or the extension has other troubles.

The work that's gone into the extension repository so far has been long needed. We've accepted extensions with a wide diversity of coding standards (including a lot of messy cut-and-paste coding), so this effort ups our game in a big way here. We've never required extensions to include testing, so establishing testability at any level is a huge advance. This effort will make our core extensions much more maintainable through the future.

It would be nice to get all of these old extensions to 100% perfect in our new processes, however that may be too unrealistic in a practical timeframe. "Perfect is the enemy of the good". So, what if we did a bit of triage on this list? Some extensions may not be that important to users and could be moved to branches (with corresponding bug reports so we don't forget about them.)

Perhaps a the goal of 95% working with perfect test matches could be set for us to start the beta release? That would be a significant improvement over 64%, but still leave breathing room for problematic extensions. That number could be reached by:

a) Writing and improving tests for important extensions b) Fixing extensions with bad test results c) Dropping unimportant extensions with bad or no tests d) Bringing in some new extensions (boosting the denominator)

...

There are some decisions to make wrt how we support dependancies, how we test extensions that call out to outside programs and how we fix the remaining issues.

Extensions that rely on external programs do sound like they'll be particularly tricky to test. On the other hand, my guess is that many of these enable interoperability with other applications, or do file format conversion, both of which are going to be of high importance to chunks of our userbase.

So, while difficult, figuring out an effective way to do testing of these would be hugely valuable.

...

== Overview ==

• 23 Extensions without comparison tests

• 119 Added Comparison Tests

• 0 Causing an Error (all fixed)
• 95 Working extensions with perfect matches
• 24 Failed to match (output is different)

• 7 Missing, Removed or untestable extensions

• 1 Delayed fix because of Merge Request
• 1 None Inkex based python extension
• 4 Removed extensions
• 1 Windows extension

=== Failed Extensions ===

Large number of differences or just borked:

• perspective, pixelsnap

Large number of differences or format is not svg:

• dpiswitcher, extrude, dxf_outlines, hpgl_output

Guessing these extensions are important for plotting/engraving?

...

Medium number of differences related to path transformatons:

• foldablebox, polyhedron_3d, summersnight

These sound fairly specialized? Maybe not as crucial?

...

Medium number of differences, various attributes missing from output:

• grid_polar, grid_cartesian, lindenmayer, whirl

The first two are probably of more general usefulness than the latter two, but guessing all four would have some value in bringing up to date.

...

Tiny or single difference related to finding layer center:

• render_barcode, render_barcode_datamatrix,

render_barcode_qrcode, render_gear_rack, render_gears, spirograph, split, triangle, wireframe_sphere, grid_isometric, hershey

Sounds like these are the low hanging fruit of this list, and some of those we know are high importance.

...

=== Removed: External dependancy, shell script (not python) ===

• eqtexsvg, plt_output, sk1_output, wmf_output,

Are these the uniconverter based extensions? Are there any others?

A question is whether people are actively using these file formats.

...

=== Other ===

gcodetools - Held up because of merge request, cleanup is very large.

May be worth pushing through on this one.

...

dm2svg - None inkex python extension, could be converted

"import a DHW file from ACECAD DigiMemo". I'm not sure what that is so no idea on its importance, but looks like Thomas Holder did some work on it so presumably it's close?

...

print_win32_vector - Windows only (untestable) but also an infurating copy of dxf_outlines.py AND untestable because it requires access to printers to print things.

Looks like it hooks into winspool.drv and gdi32.dll, that may become hard to test even on windows going forward. Is it possible this is not used much? If so, then this might be a good candidate to move out of the main repo to a branch.

...

=== Extensions without comparison tests ===

color_randomize, dxf12_outlines, fractalize, frame, generate_voronoi, gimp_xcf, inkwebeffect, interp_attr_g, jitternodes, layout_nup, loren_ipsum, markers_strokepaint, measure, pathmodifier, pathscatter, prepare_file_save_as, print_win32_vector, render_alphabetsoup, rtree, rubberstretch, synfig_output, synfig_prepare, text_randomcase

Are color_randomize, fractilize, generate_voronoi, jitternodes, pathscatter, and text_randomcase problematic due to their use of randomness? Would adding support for fixed seeding help make testing them more tractable?

Several of the others are file format or external app interop extensions, so may be difficult to test for that reason (but still important to give attention to.)

Of the remainder, those sound like priorities for doing test work on, they may be reasonably straightforward to get off this list.

...

== Work Done ==

• Unit Tests: 149 files changed, 1311 insertions(+), 1462

deletions(-)

• Test Framework: 3 files changed, 308 insertions(+), 23

deletions(-)

• Extensions: 57 files changed, 862 insertions(+), 1185

deletions(-)

• Inkex API: 9 files changed, 216 insertions(+), 40 deletions(-)

Thanks again for this list, hoping progress continues strong so we can get this resolved and proceed with the release. Keep us updated, I'd like to keep track of what percentage of the extensions are considered perfect, so I have a feel for roughly when we'll be hitting 85, 90, and 95%.

Bryce