On Tue, Nov 25, 2014 at 11:38 PM, Johan Engelen <jbc.engelen@...2592...> wrote:
We've collected a lot of deferred maintenance debt. 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.
+1
As an occasional contributor I'm still quite often overwhelmed by the complexity of the code base, even after all those years. I might be guilty of adding spaghetti too, can't tell for sure. But IMHO it's not just code readability, it's more that the bigger picture of inkscape that's important. It would help if we had better documentation of Inkscape 's architecture. Is this all we have today?
http://wiki.inkscape.org/wiki/index.php/Architectural_overview http://wiki.inkscape.org/wiki/index.php/SubsystemRearchitecture http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/download/head:/arch...
Regards,
Diederik
On Tue, Nov 25, 2014 at 11:38 PM, Johan Engelen <jbc.engelen@...2592...> 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. 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.
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); 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. 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. Although the results of work on these topics are not directly visible, I think the user /will/ notice it: all existing features will become more predictable, more stable, and more pleasant to work with.
If you agree that large maintenance overall is needed, read the attachment. Warning: put on your friendly smile hat!
- Johan
On 23-11-2014 8:45, Bryce Harrington wrote:
With 0.91 finally coming to a wrap soon, there are many different ideas on what to focus on next. One thing we all agree on is turning the next few releases out more rapidly, 0.92 especially.
To do this, we'll need to carefully select which new features to undertake each release; the more discriminating we are, the less risk of delay we'll face in these. The less we undertake in parallel, the more quickly we can perfect what we do tackle. The more we collaborate together as a team, the better the end result will be.
The Inkscape roadmap has proven instrumental in prioritizing and organizing our effort in the past. We can to use it again to help chart our course of development for the next several releases.
http://wiki.inkscape.org/wiki/index.php/RoadmapI'd like to tackle this in three steps: First, brainstorm and gather ideas into a big list. Second, filter the list down to our most pressing needs. And third, prioritize that list across the next half-dozen releases.
I figure we should strive for one primary objective each release, with one secondary and perhaps a few tertiary items. Of course, as we go we'll also have some surprises, early deliveries and the like; no need to turn those away. But the idea is to focus Inkscape on what we as a project want to achieve each release.
What do you think should be listed in our Roadmap?
Bryce
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel