On Fri, Apr 10, 2015 at 09:47:06AM +0100, Alex Valavanis wrote:
The Adaptagrams changes are mostly things from upstream that we haven't adopted yet, although there have been a few bug fixes in trunk. Actually, I think the rebasing should be fairly easy.
I think the main problem is that the project doesn't appear to have cut a release yet, so there's no easy way to test for versions if we use it as an external library. Perhaps it works be prudent to encourage them to start making release tarballs before we start rebasing.
Yes, even if it's just a 0.1, good point.
Bryce
AV On 10 Apr 2015 05:17, "Bryce Harrington" <bryce@...961...> wrote:
On Thu, Apr 09, 2015 at 04:39:11PM +0100, Alex Valavanis wrote:
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.
Very good points. I like your scheme for reorganizing the work, I'll update the roadmap to follow it.
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.
Good to know. We probably should plan how we're going to do the Gtk+3 transition before that, as I expect it may take more than one release. Probably a post-1.0 project.
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.
Ah, this is from Monash folks, I recognize the names. They were quite active in Inkscape some time back.
The latter is straightforward, just a packaging issue. As to the former, is the delta in the form of patches we've accumulated on top of their work, that hasn't gotten upstream yet? Or has it been sent upstream but the patches weren't landed?
If the upstream trees haven't been maintained and updated, then we may neet to consider having Inkscape take responsibility for their maintenance, either by formally adopting them (if we can contact the original developers and they're cool with that) or else worst case maybe fork them.
Anyway, probably a year or two before we need to get that sorted out.
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:
- 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.
Sure, this seems like a good migration strategy. I'm not _super_ worried about distros; these types of libraries tend not to be terribly complex to package. Even if we did several in one go, they can often cookie cutter the packaging for the set and do it pretty efficiently.
Bryce
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