On Tue, Nov 25, 2014 at 11:38:45PM +0100, Johan Engelen wrote:
For me, the biggest area of "win" for us is becoming more stable and polishing things. At the GSoC Summit, a friendly guy told us that we don't have to think about what new features to add: "Inkscape is already awesome". A friendly warning for too much "feature gogoGOgO!".
We've collected a lot of deferred maintenance debt.
Right. Over the last several years we've accumulated a number of nice features (particularly some of the great annual GSoC work), at the cost of incurred maintenance and stability work. For 0.91 we deliberately focused on the stability work over general maintenance, and I think we have come a long way towards addressing that. So, yes, agreed your points below it's time to prioritize maintenance type stuff, and spit and polish existing features a bit.
I think it is time to repay that; we should work on disentangling the spaghetti, improve code readability, polish existing features to high satisfaction, etc. I think once we have done that, we are ready for more adventurous things on the roadmap. What I mean is: put maintenance in the near-future roadmap, and new features further out.
Yes, agreed, this is a good overall strategy to guide our prioritization when we get to that step.
To help with refactoring: reinvigorate unittests + rendertests. This is already started at jenkins.inkscape.org:8080, but we should have a larger effort in improving our testsuite (possibly move to other test framework, but at the very least move all unittests into a dedicated tree structure, separate from the src tree);
I've been involved in projects that keep unit tests in trunk, as well as a few where they lived in separate repositories. Universally the latter projects' test suites got ignored and quickly fell out of date. Indeed there got to be kind of a discrimination against test writing as a chore. Consequently the testsuites for those projects atrophied; and the more they atrophied the less seriously they got taken; and the less importance people placed on improving them.
Then there have been projects that not only kept the tests in trunk, but made them *the* priority when developing features. Launchpad was very gung ho on this. Cairo is too, to a lesser extent. The test suite actually ends up taking up an appreciable proportion of the codebase, and you may find yourself putting as much effort into writing the tests as on the feature itself (and maybe even more!) But the result is that when you make any arbitrary change to the codebase, and the testsuite still passes, you feel a very strong sense of confidence that your change is right and hasn't broken anything.
Anyway, this is all to say I feel strongly based on my experience that we should keep all tests that we want to actually work and be useful, IN-tree. And in fact in code reviews one of the first things we should check for is whether new or updated tests are being included.
and also in extending and improving our rendertestsuite; and possibly also create a UI testsuite or something of the kind (or a cmdline testsuite). In general: TESTING.
+1
Having more comprehensive tests, /and checking them every day/ for early discovery, I think will greatly reduce release-cycle times. Less bugs need to be squashed and hopefully less nasty block bugs too. It is pretty rewarding too to fix a bug measurably by creating a test, and be sure it will not ever fail again without us knowing.
Perhaps this does not sound as much fun as creating a completely new feature. But I think it can be, and I think it is necessary.
I wonder what we can do as a project to stimulate more test writing activity. More visible posting of test writing activity might help. Maybe posting howto's and tips & tricks on writing good tests.
Bryce