- Inkscape Devel - Inkscape Mailman

RE: [Inkscape-devel] Test strategy
by Gazal, Geraud (MED) 19 Jul '04

19 Jul '04

> Either Wiki or CVS would be suitable places for storing it. There are > roughly equal pros and cons both ways. Wiki would be more widely > accessible to more people, but CVS would allow a little more > flexibility > for manipulating the document (e.g., grep, txt2pdf, etc.) -> workaround : HTML format ( portable, plus support usefull things such as images, links, tables...) maintained in the CVS and linked to a wiki page ? > It may be worthwhile if we have better ideas for the > categorization, to > alter the bug tracker to match. Those categories were decided when we > first started the project, and probably need updated to match what we > people actually support bugs about. If anyone has ideas for > improvements let me know and I'll apply them. Yup, this is directly linked to the test process. I'm preparing (70% done) it. > A subcategory of this is 'Compliance testing', which validates the > features against a spec - in our case the W3C SVG spec. There may be > other specs we can test compliance against, although some (like the > GNOME Human Interface Guidelines) will generally not be automatable. Ok, got it. Will take a look at Gnome HIG see what can be done there (not my #1 priority, but kept on the list) Already diving in SVG standards, plus test tool suite. > There is also performance testing, which can be done in a variety of > ways. For example, startup timing, function-level profiling, etc. > > Also, we should include memory error testing ala purify and valgrind. Already in mind for the categories. > > > Tests: > > Build > > Linux (Debian / Gentoo / Slackware / Mandrake / Fedora > / Suse / Others) > > Windows (98 / 2000 / XP) > > MacOS (X) > > BSD (Free / Open) > > Other Unices (Solaris / Irix) > > Note that an important condition for distros is what installation > options were used. For example, a pure-base SuSE > installation will not > include developer tools like gcc. Most distros also have installation > options which will end up lacking the -devel libs that > Inkscape needs to > compile. So each of these will require specification as to which > installation options must be used during setup. Argh, sounds complicated. The best thing, I suppose is to identify a maintainer by distro (ala Mandrake) and ask them to write down the specs for their respective distro > > Notice : should be automated (example see : > > http://public.kitware.com/Dart/HTML/Index.shtml) > > Interesting - have you used this system? Yes, that's why I was thinking about it :) But I'm trying to find even better and flexible > > - open Inkscape, launch reference editing sequence, > export result as > > bitmap and compare with a reference bitmap provided by a reference > > application on the same sequence (Inkscape itself for non > regression, Batik > > ?) > > Previous sequences can be combined in one in order to save > time, but then > > analysis of results can become more complex. > > Note, I developed a way using motion tracker software to calculate a > "percent similarity" rating given an Inkscape-generated png against a > Batik-generated png, that makes the analysis work easier. There's a > glitch that'll need to be worked out, in that the original > SVG's contain > the description in the image, which throws off the comparison. Simply separate analysis of pixels and metadata (I'm quite used to it : have worked on the dicom standard for 3 years) > > > Verification of robustness > > - testing memory leaks (not a specialist of this : I need help) > > This is an area where our work as testers is really cut out for us, > because there is a ton of memory issues in the codebase, and > we need to > be able to categorize in a way that makes them accessible to the > developers. Right now there's such an overwhelming number that > developers wouldn't know where to start, so if in testing we can > triage and prioritize the "top 10" or whatever, it would make > the fixup > work more tractable. Right. But in fact, as for unit tests, this part of the verification is hard to manage by testing team. It's mainly up to coders to operate this. Testing team can provide help (crash report, reproducibility of malicious scenarii...) but (for example in my case) are not code/design wizzards able to slalom in the memory/architecture maze. > > - provide a shaker tool (this tool would launch > Inkscape and then start > > a predefined number of pseudo-random commands -logging each > action). The > > goal is to detect crashes and analyse their conditions with the logs > > Another idea along these lines is to fire a variety of signals at it, > and detect if it behaves correctly. Just need a few precisions so that I understand better > Again, this plan looks very good, I'm looking forward to > this. I have a > feeling that since there is a *huge* amount of improvement we can gain > by taking a systematic approach to it like this. I think > it'll also be > very intriguing to figure out how to effectively meld systematized > testing with open source practices, and to see how much can be > accomplished in doing so. Ok, I'm pleased if you find the approach interesting. Regards, Matiphas

2 1

Re: Extension Proposal (First Draft)
by Gazal, Geraud (MED) 19 Jul '04

19 Jul '04

Hi Bryce, just need a small precision (paragraph 8.1) You mention plugins as loaded as dynamic objects (so/dll) ans thus being c/c++ (or somewhat compiled). I was wondering about let's say, something written in Python (because I appreciate this language, and because it is availabe on nearly all platforms). Python (or perl, ruby...) programs can nearly behave as dynamic objects. Would it be considered as a script or a plugin ? Main only concern is will it be possible writting plugins in interpreted languages (small memory print, easier to develop/maintain, often more portable...) Regards, Matiphas

2 1

ATTENTION: libgc dependency
by MenTaLguY 19 Jul '04

19 Jul '04

Please note that sometime in the next few weeks we'll be introducing a dependency on the Boehm garbage collector (libgc), and that said library must be compiled with C++ support enabled. I'd encourage all packagers/autobuilders to investigate whether there will be any problems for them. -mental

2 1

Report for 2004-07-18 18:00 GMT-0500
by unknown＠example.com 19 Jul '04

19 Jul '04

Hi. I have some bad news. Unfortunately, the last build attempt at compiling Inkscape CVS was very unsuccesful. I'm sorry, I really tried hard. Really. Here is the LOG file, and I hope that helps.

6 5

AW: [Inkscape-devel] Plain svg format?
by Taraben, Adib 19 Jul '04

19 Jul '04

>On Sun, 2004-07-18 at 20:01, bulia byak wrote: >> Yes, and I'm thinking about _why_ this may be needed, and can only >> think of the two reasons above. > >IMO, the most fundamental (if not most common) reason is to yield an SVG >document which will validate against the SVG DTD. > >Having elements in any non-SVG namespaces would (afaiK) prevent that. > >Of course, I'm not really sure most folks care about DTDs much anymore, >given they don't play well with namespaces in general. > >-mental I care. In my special purpose inkscape is not only a drawing program but a (_THE_) svg-editor. Adib.

2 1

ATTENTION: gtkmm upgrade
by MenTaLguY 19 Jul '04

19 Jul '04

I've just comitted Aubanel's gtkmm upgrade patch. You will need to rerun autogen.sh. >From now on, libgtk+ >= 2.4, libsigc++ >= 2.0 and libgtkmm >= 2.4 are required for Inkscape. I have tried to carefully test and build, but this did require some autofoo changes I do not fully understand. So be aware, and if you have any problems please help me track them down and fix them. -mental

5 9

Plain svg format?
by Øyvind Hvamstad 19 Jul '04

19 Jul '04

Hi, I just dig this app. Good work. However, I have some problems with the new rdf metadata tags when storing plain svg in 0.39. It seems that no namespace declarations are present for rdf, dc and cc. Adding them to the top fixes the problem, but it's really a hazzle when you have some 30 figures in a thesis. :) I added these: xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" You probably know this already, but if not.. Well.. Jimi needs valid xml! Inkscape rocks! (more than sodipodi :)) -- Øyvind Hvamstad <oyvind@...457...>

5 6

All tasks for 0.39 Milestone Completed
by Bryce Harrington 18 Jul '04

18 Jul '04

All of the tasks for milestone 5 "Inkscape 0.39" are now complete (the extension proposal was the last, oft-procrastinated item). I've moved all the completed Milestone 5 tasks to the PastMilestones page. Bryce

1 0

Proposal for Hard Freeze Process
by Bryce Harrington 18 Jul '04

18 Jul '04

As mentioned in the freeze process proposal for this release, we will have a new 'Hard Freeze' step to give us better quality control for the run-up to the Release Phase. During the Hard Freeze, we all refrain from committing to CVS. Instead, necessary changes should be posted to the patch tracker. A couple people -- the "Change Control Team" -- have the responsibility to vet and apply patches if they're absolutely necessary. For this release, I'd like to propose Mental and Bulia as the Change Control Team, and that we rotate who is on this team in future releases. Because the Inkscape developers are trustworthy, I think we can rely on the honor system, rather than turning off everyone's access. If there happened to be any abuse, it can be handled on a case-by-case basis. Here's how the process would work: === Hard Freeze Phase === 0. The Hard Freeze will be announced once all of the Must Fix bugs have been addressed and the codebase passes its distcheck and tests. Nobody except Change Control commits into the release tree after this point - only to the patch tracker. 1. The Change Control Team reviews the status of the application and of recent bug fixes. They request patches for abnormalities found. 2. Only patches for key bug fixes, documentation, packaging, and translations will be taken at this point. 3. Once the Change Control Team is satisfied, they announce that the codebase is Good For Release, and branch the release candidate. (See CreatingDists.) This marks the end of the Hard Freeze phase. === Release Phase === 4. The Release Team creates the distribution source tarball package, and posts the GPG-signed tarball(s). 5. Packagers begin creating the 0.XX.0-1 packages of this release for their platforms. 6. The Release Phase should be treated like a Feature Freeze; everyone can resume committing to CVS, but should limit themselves to bug fixing, in case there are serious issues that will require making a new point release. 7. If issues are discovered during this packaging process, the Change Control Team will review the changes and their fixes and choose: a) Ignore the issue for this release. b) Put up an optional package for packagers to use as needed. The packagers increment their patch-number (i.e. 0.XX.0-1) c) Declare a minor-rev increase (i.e. 0.XX.1). All packages must be regenerated in this case. 8. Once a suitable number of working, tested packages have been posted to the file tracker, the Release Team announces that the codebase is Released. 9. Finally, announcements about the release are made. This also marks the end of the Release Freeze. 10. Normal development resumes. Bryce

3 5

tab -> 4 spaces
by Kees Cook 18 Jul '04

18 Jul '04

Is anyone interested it doing this to the source code? I made a test CVS tree to see how much would be changed. The file count is 565. :) I only processed files in /src, but it would be a giant commit. I personally find in valuable, but worry it would really disrupt other folks. On the other hand, doing it after a release seems like the best time to do it. Thoughts? -- Kees Cook @outflux.net

2 3