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
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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
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
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,
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,
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
One more blocker: https://bugs.launchpad.net/inkscape/+bug/1571192
Some "High" importance bugs with the "regression" tag could be considered blockers too... -- Nicolas
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
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:
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?
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.
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.
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
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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)
Am 06.05.2016 um 22:59 schrieb Bryce Harrington:
- 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
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