Re: Extensions for the 1.0 release (report)

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