Re: Extensions for the 1.0 release (report)

Thanks Bryc

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