On Tue, Sep 10, 2013 at 2:08 AM, Tavmjong Bah <tavmjong@...8...> wrote:
But we should set a target date or there is no motivation to work on the bugs. (At least it helps me to get motivated!)
Dates don't seem to motivate anyone all that much. We could have released a while back if people really wanted it. People bring this up every couple of months and these damn bugs are brought up *every time*. Something like 2 or 3 of them have been closed in a year and a half. No real movement on them. All dates will do is piss off the users who read the devel list when we're past the date and not gearing up for release.
I guess this appears to be a chicken and egg problem... but given that proposed release plans have been thrown out a couple times in the past and those bugs didn't get worked on, it's not possible to set a date until people start knocking them down. When the list is at half of what it is it would be reasonable to put a release plan into action... but in the end, the blockers will still do just that... block a release from being possible.
Some of those blockers are really, really old.... While I would love to see them all fixed, I wouldn't block on them unless they are regressions.
All but 2 are regressions (sorry, one marked as fix committed got bumped back to confirmed as Krzysztof pointed out the proper solution as opposed to a filesize increasing workaround). So we have one that increases filesize when jpegs are embedded (unless they already had the least amount of compression possible). The other one that's not a regression: https://bugs.launchpad.net/inkscape/+bug/243729 is way too old and can really screw up people's workflow (and is panic inducing) if they're unaware of it. Either way, saving and reloading the document is an incredibly irritating workaround when you just need to be productive. I hit that bug numerous times working on marketing materials for the last SCaLE and since I was unaware of the bug, I lost at least 6 hours of time that I could have been productive because I had no clue what was going on.
I don't really like the idea of bringing cairo and pixman into the tree. For Windows and Mac, aren't they already included somehow? For Linux, by the time of release, the distros should already be up-to-date with the latest Cairo assuming that 1.14 is released in mid-October as planned (see cairo mailing list 5 Sept).
The 1.12 cairo release slipped over half a year from when it was originally proposed (not blaming or ragging or anything, we're WAY overdue). The only reason I have any hope that they can make it is because Bryce is now working on cairo upstream. I HATE the idea of us bringing more libs in-tree temporarily, but in this instance, it's actually Linux users/developers that would suffer if we don't.
Unless we change our policy, we can't release without bringing them in-tree until 2017. We have a policy to be developer friendly which means when the last expiration date here passes http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies#Distros we no longer would need to provide those libs in-tree.
Yes, we have had developers over the years who stick to LTS or just older releases for various reasons. Even bulia used to run a rather dated distro a while back, and there's no way we can block out any developers like that. Personally, it doesn't affect me because I have the option to update whenever I like. But sometimes people are working in a corporate environment where they are required to use LTS (or equivalent)... sometimes their old hardware can't run newer releases efficiently... sometimes there's just some seriously odd issue as I seem to recall was bulia's problem.
Definitely need to wait for GSoC to end... and the a little bit longer.
Yes, a little bit longer than after GSoC... GSoC work always needs to be refined and polished, it's just the nature of the program.
Cheers, Josh