9:18 p.m.
Hi All,
Just wondering if there are plans to freeze development yet? I think
we're getting close to having a working CMake build... are there any
"must have" features that are not yet fully implemented in 0.92, or
can we push on with fixing-up the remaining bugs and releasing?
I'm quite eager to make the switch to a hard C++11 requirement and
default to Gtk+ 3, so the sooner we can get 0.92 out, the better :)
Best wishes,
Alex
9:27 p.m.
On Wed, 2016-05-04 at 13:18 +0100, Alex Valavanis wrote:
Hi All,
Just wondering if there are plans to freeze development yet? I think
we're getting close to having a working CMake build... are there any
"must have" features that are not yet fully implemented in 0.92, or
can we push on with fixing-up the remaining bugs and releasing?
I'm quite eager to make the switch to a hard C++11 requirement and
default to Gtk+ 3, so the sooner we can get 0.92 out, the better :)
We should discuss this on Friday's IRC meeting.
Tav
9:49 p.m.
Hi,
Could it be possible to discuss this bug before 0.92 release
https://bugs.launchpad.net/inkscape/+bug/1429591
It's evidently linked to changes in the units area after 0.91.
Fortunately a workaround exists (it's described inside), but without any info users
could be very disappointed when applying filters linked to units.
Thanks a lot in advance,ivan
Le Mercredi 4 mai 2016 14h28, Tavmjong Bah <tavmjong@...8...> a écrit :
On Wed, 2016-05-04 at 13:18 +0100, Alex Valavanis wrote:
Hi All,
Just wondering if there are plans to freeze development yet? I think
we're getting close to having a working CMake build... are there any
"must have" features that are not yet fully implemented in 0.92, or
can we push on with fixing-up the remaining bugs and releasing?
I'm quite eager to make the switch to a hard C++11 requirement and
default to Gtk+ 3, so the sooner we can get 0.92 out, the better :)
We should discuss this on Friday's IRC meeting.
Tav
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
10:17 p.m.
On Wed, 2016-05-04 at 12:49 +0000, Ivan Louette wrote:
Hi,
Could it be possible to discuss this bug before 0.92 release
https://bugs.launchpad.net/inkscape/+bug/1429591
It's evidently linked to changes in the units area after 0.91.
This is more due to changing the units inside the template files.
Setting the "user unit" to 1mm in metric based templates and 1in in
inch based templates seemed like a good idea but I am wondering if it
would be better to keep the "user unit" set to 96 per "physical"
inch.
It would be very difficult to make all the "built-in" filters give the
same behavior with different values for the "user unit" (all the
relevant filter primitives would need to be adjusted).
Fortunately a workaround exists (it's described inside), but
without
any info users could be very disappointed when applying filters
linked to units.
Thanks a lot in advance,
ivan
10:46 p.m.
I don't have anything against the changes :-)
For me the question is how could we help the user with some info about how remediate to
the results of these changes onto the filters behaviour. Perhaps the manual could be a
good place to tell that something has changed after the 0.91 release and to explain the
workaround (how to change the templates). Personnally I learned a lot of interesting
things about filters in the manual, like the numeral settings in color matrix to simulate
greyscale.
But that cannot avoid that new users of the future releases could be discouraged by the
apparent lack of precision of many filters which include numerical inputs based on units.
ivan
Le Mercredi 4 mai 2016 15h17, Tavmjong Bah <tavmjong@...8...> a écrit :
On Wed, 2016-05-04 at 12:49 +0000, Ivan Louette wrote:
Hi,
Could it be possible to discuss this bug before 0.92 release
https://bugs.launchpad.net/inkscape/+bug/1429591
It's evidently linked to changes in the units area after 0.91.
This is more due to changing the units inside the template files.
Setting the "user unit" to 1mm in metric based templates and 1in in
inch based templates seemed like a good idea but I am wondering if it
would be better to keep the "user unit" set to 96 per "physical"
inch.
It would be very difficult to make all the "built-in" filters give the
same behavior with different values for the "user unit" (all the
relevant filter primitives would need to be adjusted).
Fortunately a workaround exists (it's described inside), but
without
any info users could be very disappointed when applying filters
linked to units.
Thanks a lot in advance,
ivan
11:30 p.m.
I asked me if (in the future) implementing properly FilterRes to filters and giving a
default filter resolution to filter effects could solve the units problem. At some point I
introduced in the list a filter called Filter Resolution (or something like that). It
didn't contain any primitive, however applying it before other filters gave a default
filter resolution based on FilterRes to the combined filters. Unfortunately the FilterRes
implementation was buggy and afterwards this filter was removed from the list.
ivan
Le Mercredi 4 mai 2016 15h17, Tavmjong Bah <tavmjong@...8...> a écrit :
On Wed, 2016-05-04 at 12:49 +0000, Ivan Louette wrote:
Hi,
Could it be possible to discuss this bug before 0.92 release
https://bugs.launchpad.net/inkscape/+bug/1429591
It's evidently linked to changes in the units area after 0.91.
This is more due to changing the units inside the template files.
Setting the "user unit" to 1mm in metric based templates and 1in in
inch based templates seemed like a good idea but I am wondering if it
would be better to keep the "user unit" set to 96 per "physical"
inch.
It would be very difficult to make all the "built-in" filters give the
same behavior with different values for the "user unit" (all the
relevant filter primitives would need to be adjusted).
Fortunately a workaround exists (it's described inside), but
without
any info users could be very disappointed when applying filters
linked to units.
Thanks a lot in advance,
ivan
10:04 p.m.
On Wed, 2016-05-04 at 14:27 +0200, Tavmjong Bah wrote:
We should discuss this on Friday's IRC meeting.
Friday's meeting is a board meeting isn't it? I thought developer
decisions like releases were more developer consensus on mailing list
type things and less board responsibility.
(or is this just convenient discussion space?)
Martin,
10:57 p.m.
On Wed, 2016-05-04 at 09:04 -0400, Martin Owens wrote:
On Wed, 2016-05-04 at 14:27 +0200, Tavmjong Bah wrote:
>
> We should discuss this on Friday's IRC meeting.
Friday's meeting is a board meeting isn't it? I thought developer
decisions like releases were more developer consensus on mailing list
type things and less board responsibility.
(or is this just convenient discussion space?)
Yes, it is not the board's duty to make developer decisions. But I
think the board does have the responsibility to aid (and prod) the
developers to make decisions when needed as well as to support the
execution of those decisions (e.g. fund a dedicated hackfest).
(it is also a convenient discussion space)
Tav
Martin,
1:07 p.m.
On Wed, May 04, 2016 at 03:57:51PM +0200, Tavmjong Bah wrote:
On Wed, 2016-05-04 at 09:04 -0400, Martin Owens wrote:
> On Wed, 2016-05-04 at 14:27 +0200, Tavmjong Bah wrote:
> >
> > We should discuss this on Friday's IRC meeting.
> Friday's meeting is a board meeting isn't it? I thought developer
> decisions like releases were more developer consensus on mailing list
> type things and less board responsibility.
>
> (or is this just convenient discussion space?)
Yes, it is not the board's duty to make developer decisions. But I
think the board does have the responsibility to aid (and prod) the
developers to make decisions when needed as well as to support the
execution of those decisions (e.g. fund a dedicated hackfest).
(it is also a convenient discussion space)
You're both right, and I do agree that having a meeting to get things
going with the release is a great idea.
Traditionally we've often encouraged non-board-specific technical
discussions to happen immediately following the board meeting. What if
we had a short board meeting for say 20-30 min, and then a second
followup meeting specifically to focus on release coordination
discussions?
Sounds like we've crested the hill on the cmake work (we still need to
do a comparison between the automake-generated dist and the cmake dist,
to see if we're missing anything important). Once we're comfortable
with what's in the dist, I can cut an alpha release - possibly as early
as this weekend. I'm prepared to do a series of (bi-weekly?)
pre-releases as we work towards the final release. Next step would be
to start gathering a list of release blockers and recruit owners for
getting those items examined; I would love it if someone could volunteer
to coordinate/manage the release blocker bugfixing work.
Bryce
3:59 p.m.
I've worked with SUV for the past half dozen years or so on figuring out
release blocker stuff. I'm willing to take it on even if there is no
interest on SUV's end to help determine such things. I will draft a release
plan tomorrow morning (as I had previously offered to) and send it to you
Bryce for your review and edits and I will begin reviewing for blocker bugs
in the tracker after that.
Cheers,
Josh
On May 4, 2016 9:08 PM, "Bryce Harrington" <bryce@...961...>
wrote:
On Wed, May 04, 2016 at 03:57:51PM +0200, Tavmjong Bah wrote:
> On Wed, 2016-05-04 at 09:04 -0400, Martin Owens wrote:
> > On Wed, 2016-05-04 at 14:27 +0200, Tavmjong Bah wrote:
> > >
> > > We should discuss this on Friday's IRC meeting.
> > Friday's meeting is a board meeting isn't it? I thought developer
> > decisions like releases were more developer consensus on mailing list
> > type things and less board responsibility.
> >
> > (or is this just convenient discussion space?)
>
> Yes, it is not the board's duty to make developer decisions. But I
> think the board does have the responsibility to aid (and prod) the
> developers to make decisions when needed as well as to support the
> execution of those decisions (e.g. fund a dedicated hackfest).
>
> (it is also a convenient discussion space)
You're both right, and I do agree that having a meeting to get things
going with the release is a great idea.
Traditionally we've often encouraged non-board-specific technical
discussions to happen immediately following the board meeting. What if
we had a short board meeting for say 20-30 min, and then a second
followup meeting specifically to focus on release coordination
discussions?
Sounds like we've crested the hill on the cmake work (we still need to
do a comparison between the automake-generated dist and the cmake dist,
to see if we're missing anything important). Once we're comfortable
with what's in the dist, I can cut an alpha release - possibly as early
as this weekend. I'm prepared to do a series of (bi-weekly?)
pre-releases as we work towards the final release. Next step would be
to start gathering a list of release blockers and recruit owners for
getting those items examined; I would love it if someone could volunteer
to coordinate/manage the release blocker bugfixing work.
Bryce
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications
Manager
Applications Manager provides deep performance insights into multiple
tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
4:15 p.m.
OK, this all sounds very promising. Unfortunately, I won't be
available to join in the IRC meeting tomorrow, but by the sounds of
things, we're not awaiting any new urgent feature additions. Can I
suggest, therefore, that we move into Feature Freeze as soon as
possible, and concentrate on bug fixing ready for release? As in
previous cycles, we could start an experimental branch for features
that can wait until after 0.92.
AV
On 5 May 2016 at 07:59, Josh Andler <scislac@...400...> wrote:
I've worked with SUV for the past half dozen years or so on
figuring out
release blocker stuff. I'm willing to take it on even if there is no
interest on SUV's end to help determine such things. I will draft a release
plan tomorrow morning (as I had previously offered to) and send it to you
Bryce for your review and edits and I will begin reviewing for blocker bugs
in the tracker after that.
Cheers,
Josh
On May 4, 2016 9:08 PM, "Bryce Harrington" <bryce@...961...>
wrote:
>
> On Wed, May 04, 2016 at 03:57:51PM +0200, Tavmjong Bah wrote:
> > On Wed, 2016-05-04 at 09:04 -0400, Martin Owens wrote:
> > > On Wed, 2016-05-04 at 14:27 +0200, Tavmjong Bah wrote:
> > > >
> > > > We should discuss this on Friday's IRC meeting.
> > > Friday's meeting is a board meeting isn't it? I thought developer
> > > decisions like releases were more developer consensus on mailing list
> > > type things and less board responsibility.
> > >
> > > (or is this just convenient discussion space?)
> >
> > Yes, it is not the board's duty to make developer decisions. But I
> > think the board does have the responsibility to aid (and prod) the
> > developers to make decisions when needed as well as to support the
> > execution of those decisions (e.g. fund a dedicated hackfest).
> >
> > (it is also a convenient discussion space)
>
> You're both right, and I do agree that having a meeting to get things
> going with the release is a great idea.
>
> Traditionally we've often encouraged non-board-specific technical
> discussions to happen immediately following the board meeting. What if
> we had a short board meeting for say 20-30 min, and then a second
> followup meeting specifically to focus on release coordination
> discussions?
>
> Sounds like we've crested the hill on the cmake work (we still need to
> do a comparison between the automake-generated dist and the cmake dist,
> to see if we're missing anything important). Once we're comfortable
> with what's in the dist, I can cut an alpha release - possibly as early
> as this weekend. I'm prepared to do a series of (bi-weekly?)
> pre-releases as we work towards the final release. Next step would be
> to start gathering a list of release blockers and recruit owners for
> getting those items examined; I would love it if someone could volunteer
> to coordinate/manage the release blocker bugfixing work.
>
> Bryce
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers
of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
12:19 a.m.
We have 2 blockers atm... https://bugs.launchpad.net/inkscape/+bug/1416674
might be the trickier one because we have fewer Windows devs. However, I
think it only requires someone to figure out the issue of what the path
that font managers use is (my Google skills have failed so far).
Unfortunately a number of our users don't even use 0.91 because of this. Oh
and this is the other blocker:
https://bugs.launchpad.net/inkscape/+bug/1389723
Cheers,
Josh
On Wed, May 4, 2016 at 5:18 AM, Alex Valavanis <valavanisalex@...400...>
wrote:
Hi All,
Just wondering if there are plans to freeze development yet? I think
we're getting close to having a working CMake build... are there any
"must have" features that are not yet fully implemented in 0.92, or
can we push on with fixing-up the remaining bugs and releasing?
I'm quite eager to make the switch to a hard C++11 requirement and
default to Gtk+ 3, so the sooner we can get 0.92 out, the better :)
Best wishes,
Alex
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications
Manager
Applications Manager provides deep performance insights into multiple
tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2:04 a.m.
One more blocker: https://bugs.launchpad.net/inkscape/+bug/1571192
Some "High" importance bugs with the "regression" tag could be
considered blockers too...
--
Nicolas
5:59 a.m.
On Wed, May 04, 2016 at 01:18:23PM +0100, Alex Valavanis wrote:
Hi All,
Just wondering if there are plans to freeze development yet? I think
we're getting close to having a working CMake build... are there any
"must have" features that are not yet fully implemented in 0.92, or
can we push on with fixing-up the remaining bugs and releasing?
I'm quite eager to make the switch to a hard C++11 requirement and
default to Gtk+ 3, so the sooner we can get 0.92 out, the better :)
Best wishes,
We had a quite productive meeting this morning. I'll be posting various
followup bits through the weekend, but wanted to float a couple items we
felt were worth proposing:
1. How do folks feel about a feature freeze in, say, a week? Are there
any WIP's that would get disrupted if we did that?
2. Regardless of when we feature freeze officially, I'd strongly
suggest any currently underway development be wrapped up asap, and
anything that's been recently added (e.g. Gtk3 work was mentioned)
be brought to a releasable state. That could mean disabiling it by
default or even reverting the changes for now and save them for 0.93
worst case.
3. Josh is going to boil down a list of release blocking bugs. Send
him ones you think must be on the list, but please be extremely
selective, we don't want to get the release bogged down too much on
bugs.
4. Experimental branch - we're thinking we'll try to make the release
process go quick enough that we can avoid doing an experimental
branch this cycle, and just encourage folks to work on side branches
for now. We can always set one up later on if there's a demand for
it.
Comments welcomed on any of the above. I'll be posting a release plan
either today or this weekend, and nail down the decisions for the above,
so if you've got input on any of the above, please share asap.
Bryce
6:33 p.m.
Sounds like a good plan. The recent GTK+ 3 work is just bug-fixing in the
experimental build, so shouldn't impact on the release schedule.
AV
On 6 May 2016 9:59 p.m., "Bryce Harrington" <bryce@...961...>
wrote:
On Wed, May 04, 2016 at 01:18:23PM +0100, Alex Valavanis wrote:
> Hi All,
>
> Just wondering if there are plans to freeze development yet? I think
> we're getting close to having a working CMake build... are there any
> "must have" features that are not yet fully implemented in 0.92, or
> can we push on with fixing-up the remaining bugs and releasing?
>
> I'm quite eager to make the switch to a hard C++11 requirement and
> default to Gtk+ 3, so the sooner we can get 0.92 out, the better :)
>
> Best wishes,
We had a quite productive meeting this morning. I'll be posting various
followup bits through the weekend, but wanted to float a couple items we
felt were worth proposing:
1. How do folks feel about a feature freeze in, say, a week? Are there
any WIP's that would get disrupted if we did that?
2. Regardless of when we feature freeze officially, I'd strongly
suggest any currently underway development be wrapped up asap, and
anything that's been recently added (e.g. Gtk3 work was mentioned)
be brought to a releasable state. That could mean disabiling it by
default or even reverting the changes for now and save them for 0.93
worst case.
3. Josh is going to boil down a list of release blocking bugs. Send
him ones you think must be on the list, but please be extremely
selective, we don't want to get the release bogged down too much on
bugs.
4. Experimental branch - we're thinking we'll try to make the release
process go quick enough that we can avoid doing an experimental
branch this cycle, and just encourage folks to work on side branches
for now. We can always set one up later on if there's a demand for
it.
Comments welcomed on any of the above. I'll be posting a release plan
either today or this weekend, and nail down the decisions for the above,
so if you've got input on any of the above, please share asap.
Bryce
9:42 p.m.
Dear Inkscape Team,
I wonder if someone had time to look at my two LPEs at
https://code.launchpad.net/~msoegtrop/inkscape/embroidery
The embroidery stitch LPE is a bit early for 0.92, but the bool LPE
seems to work reliably, might be interesting for many people and is not
that much code.
Best regards,
Michael
12:28 a.m.
I could try to review, Can you add a new branch with this LPE only? It
is cleaner and avoid mergin problems.
Cheers, Jabier.
El sáb, 07-05-2016 a las 14:42 +0200, Michael Soegtrop escribió:
Dear Inkscape Team,
I wonder if someone had time to look at my two LPEs at
https://code.launchpad.net/~msoegtrop/inkscape/embroidery
The embroidery stitch LPE is a bit early for 0.92, but the bool LPE
seems to work reliably, might be interesting for many people and is
not
that much code.
Best regards,
Michael
-------------------------------------------------------------------
-----------
Find and fix application performance issues faster with Applications
Manager
Applications Manager provides deep performance insights into multiple
tiers of
your business applications. It resolves application problems quickly
and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
6:44 p.m.
Dear Jabier,
I could try to review, Can you add a new branch with this LPE only?
It
is cleaner and avoid mergin problems.I created branch
https://code.launchpad.net/~msoegtrop/inkscape/lpe-bool
which just contains the bool LPE. Should I remove the bool LPE from the
embroidery branch?
I have some regression test / example files. I wonder what is the best
place to put these?
The effect of some slicing boolops is hard to visualize without another
LPE which makes intermediate control points visible like the embroidery
stitch LPE. But since such operations are also available from the menu,
I guess it is not to confusing to have them here as well.
One note: the difference between remove/keep inner slicing is that if a
path is sliced with a contour which has inner lines, the slicing is
either done just with the outer contour lines or also with the inner lines.
Best regards,
Michael
9:11 a.m.
On Sat, May 07, 2016 at 02:42:22PM +0200, Michael Soegtrop wrote:
Dear Inkscape Team,
I wonder if someone had time to look at my two LPEs at
https://code.launchpad.net/~msoegtrop/inkscape/embroidery
The embroidery stitch LPE is a bit early for 0.92, but the bool LPE
seems to work reliably, might be interesting for many people and is not
that much code.
LPE's are fairly low risk in terms of disrupting the release, so if
y'all feel that there's one that's solid and ready to go right now, then
please feel free to land it. But try and prioritize getting it landed
within the next week.
Our intent is for 0.93 to not take quite so long to get out (a release
some time after summer might be nice), so hopefully that means
postponing things to that release won't delay getting them to users too
badly.
Bryce
Best regards,
Michael
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
5:01 p.m.
El sáb, 07-05-2016 a las 17:11 -0700, Bryce Harrington escribió:
On Sat, May 07, 2016 at 02:42:22PM +0200, Michael Soegtrop wrote:
>
> Dear Inkscape Team,
>
> I wonder if someone had time to look at my two LPEs at
>
> https://code.launchpad.net/~msoegtrop/inkscape/embroidery
>
> The embroidery stitch LPE is a bit early for 0.92, but the bool LPE
> seems to work reliably, might be interesting for many people and is
> not
> that much code.
LPE's are fairly low risk in terms of disrupting the release, so if
y'all feel that there's one that's solid and ready to go right now,
then
please feel free to land it. But try and prioritize getting it
landed
within the next week.
I merge also mirror symetry LPE :)
Our intent is for 0.93 to not take quite so long to get out (a
release
some time after summer might be nice), so hopefully that means
postponing things to that release won't delay getting them to users
too
badly.
Bryce
>
> Best regards,
>
> Michael
>
> -----------------------------------------------------------------
> -------------
> Find and fix application performance issues faster with
> Applications Manager
> Applications Manager provides deep performance insights into
> multiple tiers of
> your business applications. It resolves application problems
> quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
-------------------------------------------------------------------
-----------
Find and fix application performance issues faster with Applications
Manager
Applications Manager provides deep performance insights into multiple
tiers of
your business applications. It resolves application problems quickly
and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
10 a.m.
My request would be for https://bugs.launchpad.net/inkscape/+bug/1575790
- Get the latest python 2.7 included in the 32 bit builds for windows.
64 bit reported as up-to-date.
The python code in some extensions fails due to being developed in 2.7
and not working in 2.6.5 (an example is in report)
7:08 a.m.
Am 06.05.2016 um 22:59 schrieb Bryce Harrington:
3. Josh is going to boil down a list of release blocking bugs.
Send
him ones you think must be on the list, but please be extremely
selective, we don't want to get the release bogged down too much on
bugs.
I just remembered we should definitely fix (or workaround as a last
resort) bug 1269698 [1] (Preferences, Undo, Redo and Revert stock icons
are missing) before making the release.
Although it's not affecting functionality it's a very embarrassing bug
that probably costs us a lot of credibility on Windows platforms.
Regards,
Eduard
[1] https://bugs.launchpad.net/inkscape/+bug/1269698
2502
days inactive
2522
days old
inkscape-devel@lists.inkscape.org
21 comments
11 participants
participants (11)
-
Alex Valavanis -
Bryce Harrington -
Eduard Braun -
Ivan Louette -
Jabiertxo Arraiza Cenoz -
Josh Andler -
Mark Schafer -
Martin Owens -
Michael Soegtrop -
Nicolas Dufour -
Tavmjong Bah