This does make me sad, as at my day job I have no choice but to use osx. And I prefer Inkscape to the Adobe options, though I have ready access to them. I do understand both sides of this debate, though. The x11 or Quartz version leaves a lot to be desired as compared to native GTK on *nix. The osxmenu project version was great... But if there is a dearth of developers for this work, understood. It would be better to focus on what can be done on the supported platforms. FLOSS supporters on osx know we have to give up many preferred apps that just aren't available. I wish I could help out here, but apart from a guided compile, I couldn't really contribute to packaging. Maybe it's finally time to run a virtual xubuntu on osx to get the tools I miss...
JF ------ Original message------From: Lyndsy SimonDate: Thu, Jan 5, 2017 12:27 PMTo: Martin Owens;Bryce Harrington;inkscape-devel@...6...;Cc: Subject:Re: [Inkscape-devel] Retrospective on 0.92 release
……
Based on the feedback I'm seeing, it looks like we made a very good choice to retire our OSX packaging. I admit I was a little worried, but suv's judgment was 100% right, and as anticipated our deliberately *not* providing it is stimulating others to step in and fill the void. With 0.93 on Gtk3 it sounds like we'll have opportunities for even better OSX packages.
We made a good call there. It's hard to say no to an entire platform, but we really couldn't support it reasonably and people that use MacOSX have the worst opinion of Inkscape imaginable. Look at some of the comments about the release.
I also think it was a good call, but not because macOS users "have the worst opinion of Inkscape imaginable". You're seeing a very small segment of that community; most Inkscape users on macOS aren't going to engage in a flamewar because a new version doesn't have a download link for their platform on the day of its release.
If the existing dev team can't support the platform (which seems to be the case), then dropping it was absolutely the right move. If there is enough demand out there to justify packaging it in the future, let the people who want it to happen supply the resources to make it happen. On Thu, Jan 5, 2017 at 9:48 AM Martin Owens <doctormo@...400...> wrote: Firstly,
Three cheers for Bryce, without whom we would have no release at all.
Let me add some thoughts to your postpartum below...
Overall I think it went quite well. Switching build systems was a big change, and getting two year's worth of feature work stabilized is quite an achievement.
Yes, it's quite the achievement. Each release build is a way for us a programmers to say "Users matter and this is a thing we think users should have" and it shows the project is not just a collection of self interested coders, but also selfless volunteers that can get a lot of these tasks done even if we don't benefit in a direct way.
Releases are perhaps the most primary target for paid work, where the money comes from users. Especially given it's laborious, managerial (pointy haired boss eh bryce ;-)) and could do with more attention.
Perhaps we could have a fund raising just for the next release, we'd be setting ourselves some harder deadlines and if successful, we'd have the money to pay for say a person or two to work on bugs and management aspects.
Based on the feedback I'm seeing, it looks like we made a very good choice to retire our OSX packaging. I admit I was a little worried, but suv's judgment was 100% right, and as anticipated our deliberately *not* providing it is stimulating others to step in and fill the void. With 0.93 on Gtk3 it sounds like we'll have opportunities for even better OSX packages.
We made a good call there. It's hard to say no to an entire platform, but we really couldn't support it reasonably and people that use MacOSX have the worst opinion of Inkscape imaginable. Look at some of the comments about the release.
Another big part of the delay was blocker bugs. I found this very hard to get my hands around; the issues are legitimately troublesome problems that should be resolved, but finding people able and available to work on them was tough. Unfortunately bugs are inevitable, and I worry the shift to Gtk3, C++11, and so on are destined to give rise to more. Does anyone have ideas on how we can handle things better so there are fewer blockers? Or ways to get the blockers resolved more quickly?
I see tackling bugs to be a big part of the problem. We may have to have a talk about what it means to be an "Inkscape Developer" capital I, capital D. Our requirements right now are two commits to trunk ever in the past. There's no long term plan for members to retire and no bug fixing requirement to keep an active Developer status.
We don't even specify in the about screen which members were active in the last ten years of development. Anyone ever is in that list. Which is good for voting, things like the board voting should be open to all alumni. But for the kinds of attribution that is rewarding to see, we don't really pay much attention and can't offer anything to bug fixers.
a more timely fashion. Does anyone have suggestions or observations that could help us improve this?
A service that does timed and shared task management might be an improvement. I noticed there was a lot of manual work with regard to task management.
huge positive impact Inkscape has made in people's lives and careers, and the 0.92 release you've created is going to enable a lot of people to do some really great things.
Inkscape is one of those things in the world that provides millions of dollars worth of economic and social value but which takes very little money. Something Open Source projects can always be proud of.
But there's space to think about having our different user groups (cnc, artists, animators, web designers, tracers etc etc) involved in sorting out the major issues they have with their respective workflows. I noticed that while a laser cutter problem is critical to workshops and school use of inkscape, it was wishlist or low priority for the project as a whole. That presents us with a problem where Inkscape is great for 90% of the work, but has critical failures for 90% of workflows at the same time.
I'll keep thinking about this and I'd be happy to talk on IRC at our next meeting.
Thanks again Bryce!
Best Regards, Martin Owens
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's