Re: Extensions for the 1.0 release (report)

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, [email protected] 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