On Mon, 2013-09-09 at 16:45 -0700, Josh Andler wrote:
Most of the blockers have got some age on them... it's not worth freezing until we're less at less than 5 and it's obvious that they're being actively worked on. I would love to see a release before the end of year holidays... but that would be the quickest wind down to a dev cycle we've had in years. Also, it would be good to know the status of packaging on OSX and if there has been any progress on 64-bit windows lib work and the msi installer that was being tested at one point.
Cheers, Josh
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!)
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.
On Mon, Sep 9, 2013 at 4:32 PM, Martin Owens <doctormo@...400...> wrote:
On Mon, 2013-09-09 at 15:46 -0700, Josh Andler wrote:
In addition too that, we will need to bring a copy of cairo and pixman in-tree for a while to ensure the new renderer will work everywhere.
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).
So bug #804162 is solvable by bringing cairo and pixman into tree. That brings us down to 10 bugs.
Probably best to put us into a freeze, to deal with these bugs (and probably some others). Is there a reason to not plan for this kind of release process after GSoC has ended?
Definitely need to wait for GSoC to end... and the a little bit longer.
Tav
Because I always have to search for it: blocker list: https://bugs.launchpad.net/inkscape/+bugs?field.searchtext=&orderby=-imp...