Hi Bryce,
tl;dr: Let's split modularization work over a few releases so we don't create dependency nightmares for downstream users.
Thanks for this. I wonder whether it would make sense to bring some of the modularisation from 1.1 forward to 0.93 (e.g., libcroco should be fairly easy, as soon as the upstream GNOME devs finally accept our changes!) I'd be a bit concerned about having so much in one milestone. Conversely, we can't drop our fork of libgdl until we migrate to Gtk+ 3, so that will have to be pushed back to a later date. Finally, I believe that our forks of libavoid, libcola and libvpsc are in fact part of the upstream "adaptagrams" project [1], although last time I looked, there seemed to be a very large delta, and the library isn't packaged for many distros.
Furthermore, we should probably note that our "switch to regular dependency" tasks are non-trivial processes, since we need to establish a dependency pathway between our upstream library dependencies and downstream users... basically something like this: 1. Rebase our (ancient) forks of external libraries on the latest upstream release. 2. Forward all remaining changes to the libraries to upstream devs and request a new upstream release. 3. Sync our fork of the library with an appropriate upstream version and forbid any more in-trunk edits. 4. Update build tools to use upstream library by default (maintain fallback to embedded version). Maybe display a warning in the build log to inform the user that they should be using the upstream lib from now on. 5. Delete embedded library (update build tools accordingly)
As such, it might be prudent to cut a release of Inkscape after item 4, so that downstream distros have time to catch the new upstream library dependencies... some of them, like Adaptagrams, are pretty poorly represented in distros, so they'll need time to find a package maintainer etc. In other words, if we suddenly announce a vast number of new dependencies (some fairly obscure) at once, we'll effectively make Inkscape 1.1 unusable for many users.
Best wishes,
Alex
[1] http://www.adaptagrams.org/documentation/index.html
On 8 April 2015 at 22:18, Martin Owens <doctormo@...400...> wrote:
On Wed, 2015-04-08 at 14:07 -0700, Bryce Harrington wrote:
Thanks Krzysztof, Martin, and Alex for providing feedback on the roadmap sketch I posted earlier.
I've fleshed out the following roadmap draft using this feedback, and extended it for another 5 releases. This assumes roughly 3 months per release.
http://wiki.inkscape.org/wiki/index.php/Roadmap
If anything, I think I've squeezed too much; I'd been hoping to have no more than maybe 3 major items per release. If you see items that could be put off or that would be too difficult to achieve in the near term, let me know so we can bump them down the list. Particularly for 0.92 and 0.93.
Even after squeezing all that stuff in, I've found quite a laundry list of feature requests left. If there are features that you think *must* go in pre-1.0, and you're planning on working on them yourself, please let me know and I'll shuffle things around to ensure it fits.
Beyond that... any and all feedback is welcomed! Come throw some darts!
Bryce,
This looks amazing, thanks for working on getting this list in order. It's so easy to see what needs to be worked on first with this.
I'm happy with the priority and the content of these steps.
Martin,
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel