On Thu, Oct 16, 2014 at 02:55:42PM +0100, Alex Valavanis wrote:
This debate also raises the spectre of the old "Gtk+ 3" debate again... any system with Cairo 1.14 will also certainly have Gtk+ >= 3.2 available. Last time the issue was raised of switching to Gtk3 by default for inkscape >= 0.92, it was noted that it would write off users of LTS distros like RHEL, CentOS etc. If we set a hard Cairo >= 1.14 dependency, it will effectively do the same thing.
I think we really need a policy statement from the board about support periods...
Martin is correct that the board is not charterd to set technical direction for Inkscape.
I much prefer seeing technical decisions made via rough consensus. When we all are on the same page about something, the project as a whole is able to move forward much more decisively. When things are decided by voting or by a committee, there's always a risk that there's going to be a disgruntled minority.
That said, it's definitely true there are a number of issues - like this one - where we collectively need a single solution, but are currently of diverse opinions. My hope (and plan) is to work through this list one by one and really hash out them out together with some healthy debate, with the goal that we gain a rough consensus on each. You're probably right that documenting them as policy would be beneficial, so we're not just making decisions based on who touched the code last.
Now, obviously there are going to be some items that we're simply never going to all agree on. If we're down to just one or two nay's on an issue, that's probably fine. But the important thing is that dissenters feel their views are being fairly taken into consideration, and are willing to let the motion proceed without blocking it.
it's a major maintenance headache if we're aiming to support Inkscape on everything from RHEL 5 (stable release from 2007-2017) to distros like Arch Linux that pull in bleeding edge libraries. By the end of an RHEL support cycle, that would mean that we'd be supporting builds using a ten-year range of infrastructure. We already have literally hundreds off conditional build statements, and each of these represents a hazard... so something has to give somewhere!
Yes, this is a good point. It sucks being limited by a platform. I feel the same way when I think about having to support Windows and OSX, when I'm trying to get a release out and we're blocked on some Windows bug. More than a few times I've thought it'd make releases go so much smoother if we could just ignore their needs and focus on Linux, and let other people worry about porting issues. Those people should all be using Linux instead, in my opinion. So I can totally see the point of view here with respect to LTS users and their antique Linux systems.
But, as a project we're more successful if we can deliver on a diverse assortment of platforms. By that I mean we get more developers making more contributions, we get more recognition by the public, and we meet the needs of a wider range of the public.
Now, I wouldn't go so far as to say we need to support every possible bit of hardware and every release of every distro out there. We can set some reasonable boundaries. For instance, with LTS releases I think one ought to be sufficient - so we should support Ubuntu 14.04 but not worry as much about 12.04.
Of course, "support" can have a lot of meanings. It can mean that we actively test it and assure that the user will have a good experience. Or it can mean we'll begrudge bug reports, but aren't going out of our way to make smooth sailing for folks. Or it can mean that Inkscape will install and run and be usable but beyond that you're on your own.
Because we're an all-volunteer organization, the level of support we can give to any particular platform is really a function of the level of interest by volunteers. We could state as a project we're committed to giving strong support for Inkscape on ARM, but if no one is actually working on that platform, then de facto we don't actually support it.
So with all that said, I think "Tier C" support we should keep to be as broad as we possibly can, "Tier B" I think is sufficient for our LTS support, and "Tier A" should be limited to what individual developers are actively running and using.
How about something like this...
0.48.x: Continue to support as an Inkscape LTS release for another couple of years, but cap the API versions we'll support so we don't have to keep releasing a new 0.48.x whenever the private Poppler headers change! Security issues and simple/serious bug fixes only. 0.91: Set Cairo >= 1.14 dependency; release as scheduled... no backports to old distros. 0.92: Enable Gtk+ 3 by default (Gtk+ 2 kept as fallback) 0.93: Remove Gtk+ 2 support and GDL fork; migrate to upstream libcroco
I like this list, although I do agree with Josh here. Because of how much time has passed since 0.48 was released, I'd be more comfortable if we bump it down one release, so Cairo >= 1.14 in 0.92, and Gtk+ 3 in 0.93, etc. with the caveat that like Josh mentioned, we move to a much faster turnaround for releases.
I'll arrange a discussion around updating our Roadmap, and include consideration for timing of transitions like these.
Bryce
AV
On 16 October 2014 13:48, Krzysztof Kosiński <tweenk.pl@...400...> wrote:
2014-10-16 8:11 GMT+02:00 Bryce Harrington <bryce@...961...>:
So, I think a lot more flexibility is placed in the user's hands if we *don't* force the dependency version. Downscaling is an important feature but one that perhaps not everyone requires.
This 'flexibility' only allows the user to obtain a version of Inkscape which has a very high severity bug, and moreover one which is only apparent after you did all the work and are stuck with a completely useless render. It makes working with photos impossible.
If we want to make a version of Inkscape 0.91 that works with Cairo < 1.14, then we should simply disable the display of raster images (e.g. replace every image with a placeholder that says "you version of Cairo is too old, please upgrade", like we do for missing images).
Regards, Krzysztof