
Am 21.01.2017 um 11:39 schrieb Marc Jeanmougin:
What affects "many" or "most" users is also subjective: If you don't use a feature at all (some people do not use LPE, some people do not use texts, no one uses 3d boxes), at the same time you'll be less likely to notice the regression, and to consider it as important. About this, I'd favour developing automated rendering tests after the git migration. A few files with all existing inkscape features used in them, ideally created with a variety of old templates, and automatically running inkscape on them when comitting + comparing to the normal rendering (I think it might be possible with git pre-receive hooks(?)).
I fully agree! Proper rendering tests is something Inkscape lacks the most. While working on Scour (which is really tiny compared to Inkscape) I learned proper tests are a lifesaver! Even tiny changes often break things one would have never thought of. By adding at least one test for every new feature and every bug fixed one can almost be sure that a change which does not break tests is save to commit.
This will be especially helpful for Inkscape as we're a very "friendly" community as mentioned before (I'd rephrase "friendly" a bit: As a developer you're basically free to do whatever you want no matter the consequences). While this works OK in most cases and motivates many great new features it is also the source of Inkscape's Achilles' heel: Regressions.
I'd very much like if we could introduce feature branches with the move to git: People work on their own branch and push changes exclusively to this branch. As soon as they think their changes are fit for inclusion into the Inkscape code base they create a pull request on which automated tests are run. As soon as those tests pass the PR can be merged. This achieves two things: 1) Developers get a direct feedback if their change breaks anything. Right now one can only do some manual check, commit, and hope for the best. 2) If a feature breaks anything, developers are still around and motivated to fix those issues to get their new functionality into Inkscape. This prevents also situations where a feature is added, has serious regressions and is therefore reverted at some point, but at that time the original author of those changes is not around any more / does not have time any more and the feature is lost.
Regards, Eduard