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:
> 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.

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