Bug fixing energy seems to be dwindling. To me this means it is release time. I'd like to get input from others on a few topics.
1) Translation status. Translation is an eternal project. I don't know how to quantify what is good enough for release. Arpad, Matiphas, how are we doing? I think it is time to get serious about this hard freeze and turn to patches, but I want to make sure you are ready.
2) Quality assurance. I looked through the bug tracker. We have some new issues. The font selector crash [1501150] is easy to reproduce, but also quite easy to avoid. Jon was looking into [1501156] last I heard. I've been waiting to hear from bbyak about the snapping bugs [1429049]. I think we are going to hear about [1497837] libgc-6.7 a lot but there seems to be a solution. Are we release quality? If not, I think we are very close. What do others think?
3) Stable branch. We're switching things up a bit this time. We have had a slightly warmed over freeze. And we plan to maintain a stable branch for 0.44. Could we perhaps tie up loose ends and tighten down our committing habits tomorrow, Thursday June 8th? Then in the evening US Central time, I will branch 0.44 we can begin the absolute freeze on that branch, all fixes going into the tracker, and reopen HEAD for those eager to wreak havoc. If all goes well cut the release from the branch on Tuesday. Sound like a plan?
Speak up now. :-)
Aaron Spike
On Wed, Jun 07, 2006 at 10:52:45PM -0500, Aaron Spike wrote:
- Translation status.
- Quality assurance. I looked through the bug tracker. We have some new
issues. The font selector crash [1501150] is easy to reproduce, but also quite easy to avoid.
I know we had a number of font related crashes reported the past couple weeks - did this get investigated and worked out? If not, is the plan to disable font rendering in the selector?
Jon was looking into [1501156] last I heard. I've
This is sort of a "cross your legs, blink three times, and sneeze" type of bug - it is definitely recreatable and should be fixed, but the steps to trigger it are odd enough that I suspect most people won't encounter it. In fact, I'd wager that it's been in there for quite a while with no one noticing it.
been waiting to hear from bbyak about the snapping bugs [1429049]. I think we are going to hear about [1497837] libgc-6.7 a lot but there seems to be a solution. Are we release quality? If not, I think we are very close. What do others think?
I'd like to see the default sensitivity for snapping increased (from 0.4 to, say, 10 or 20). Presently, due to one of the bugs in snapping that's not likely to get fixed before release, the default sensitivity is so low that it essentially does not snap. Increasing the default sensitivity will provide an adequate workaround I think.
I've uploaded a patch that sets the sensitivity to 10. I think this will hide the issue until someone can come up with a better fix for the underlying issue.
http://sourceforge.net/tracker/index.php?func=detail&aid=1502674&gro...
- Stable branch. We're switching things up a bit this time. We have had
a slightly warmed over freeze. And we plan to maintain a stable branch for 0.44. Could we perhaps tie up loose ends and tighten down our committing habits tomorrow, Thursday June 8th? Then in the evening US Central time, I will branch 0.44 we can begin the absolute freeze on that branch, all fixes going into the tracker, and reopen HEAD for those eager to wreak havoc. If all goes well cut the release from the branch on Tuesday. Sound like a plan?
Speak up now. :-)
Sounds great!
Bryce
On 6/8/06, Bryce Harrington <bryce@...961...> wrote:
I'd like to see the default sensitivity for snapping increased (from 0.4 to, say, 10 or 20). Presently, due to one of the bugs in snapping that's not likely to get fixed before release, the default sensitivity is so low that it essentially does not snap. Increasing the default sensitivity will provide an adequate workaround I think.
This would make it easier for the first-time user to notice that snapping works, without zooming in. But I don't know how usrful it would be for those who work at non-default zooms. Wouldn't it be too annoying if it snaps you away across half the screen?
Anyway, I propose to go with the opinion of users on this. I don't use snapping, so I'd like to hear from those who does. What default absolute units sensitivity you would propose, given that the "sensitivity in screen pixels" is not implemented for 0.44?
On Thu, Jun 08, 2006 at 11:09:41AM -0400, bulia byak wrote:
On 6/8/06, Bryce Harrington <bryce@...961...> wrote:
I'd like to see the default sensitivity for snapping increased (from 0.4 to, say, 10 or 20). Presently, due to one of the bugs in snapping that's not likely to get fixed before release, the default sensitivity is so low that it essentially does not snap. Increasing the default sensitivity will provide an adequate workaround I think.
This would make it easier for the first-time user to notice that snapping works, without zooming in. But I don't know how usrful it would be for those who work at non-default zooms. Wouldn't it be too annoying if it snaps you away across half the screen?
Of course, anyone can change the snap sensitivity - if they know to do so. In the first case, the new user who tries snapping with a sensitivity too low, will logically conclude that snapping is simply broken in Inkscape, and not explore further (or will ask on IRC as so many have). In the second case, the user realizes immediately that snapping is "too strong", and thus will have no doubt that snapping works, and will seek out the setting.
The question boils down to whether we have more users that turn on snapping when zoomed in or out, which of course we have no way of knowing. However, when starting a new document, the default zoom is the full page, and this suggests we should set other defaults - like snapping sensitivity - to be consistent with that default, because ALL users will start from there.
Obviously, if there are a significant number of users working at the zoomed in level, then this suggests a preference setting for initial snap sensitivity is in order. I'd favor this; in fact I'd also favor including preferences for whether grid is initially on, and all the grid settings. I have a routine I follow *every* time I start a new document in inkscape, where I set the grid spacing, snap sensitivity, turn on the grid and snapping, switch from snap-to-bounding-box to snap-to-nodes (snap-to-bounding-box as a default is extremely annoying btw), and so on. I would absolutely love it if I could set these as my document defaults. I'd love it even more if when creating a new document I could choose whether to use settings for "technical drawing" or "artistic drawing".
Of course, this whole discourse may end up being irrelevant anyway, once snapping gets more development attention. I don't know.
Anyway, I propose to go with the opinion of users on this. I don't use snapping, so I'd like to hear from those who does. What default absolute units sensitivity you would propose, given that the "sensitivity in screen pixels" is not implemented for 0.44?
As someone who hardly ever uses Inkscape *without* snapping turned on, I would favor it set between 10 and 20.
Bryce
On 6/8/06, Bryce Harrington <bryce@...961...> wrote:
I know we had a number of font related crashes reported the past couple weeks - did this get investigated and worked out? If not, is the plan to disable font rendering in the selector?
The one I could reproduce is fixed. Others I cannot reproduce on XP.
Disabling font previews really won't fix it - most likely it will still crash if you try to use the font which crashes the preview.
On 6/8/06, bulia byak wrote:
On 6/8/06, Bryce Harrington <bryce@...961...> wrote:
I know we had a number of font related crashes reported the past couple weeks - did this get investigated and worked out? If not, is the plan to disable font rendering in the selector?
The one I could reproduce is fixed. Others I cannot reproduce on XP.
Disabling font previews really won't fix it - most likely it will still crash if you try to use the font which crashes the preview.
So, Inkscape doesn't check for broken fonts and bypass found ones on startup?
Alexandre
On 6/8/06, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
So, Inkscape doesn't check for broken fonts and bypass found ones on startup?
No, why should it? It's crearly the responsibility of font libraries, not us.
On Jun 7, 2006, at 10:42 PM, Bryce Harrington wrote:
Jon was looking into [1501156] last I heard. I've
This is sort of a "cross your legs, blink three times, and sneeze" type of bug - it is definitely recreatable and should be fixed, but the steps to trigger it are odd enough that I suspect most people won't encounter it. In fact, I'd wager that it's been in there for quite a while with no one noticing it.
Well...
Actually that was to get things to crash. To get a warning assertion to come up there was a lot less to it. And it was one of those warnings that indicated an internal corruption. Let them go and then later on you'll get strange, hard to reproduce side-effects. The crash steps == odd. The initial corruption == much easier to see.
So the lesson here, boys and girls? Don't ignore warnings. They are there for a reason, and you'll have much strange pain and suffering if you ignore them. Much easier to just fix problems at their root.
Oh, and bug 1501156 is fixed.
Hi,
- Translation status. Translation is an eternal project. I don't
know how to quantify what is good enough for release. Arpad, Matiphas, how are we doing? I think it is time to get serious about this hard freeze and turn to patches, but I want to make sure you are ready.
I know of one translator who hasn't committed yet but said he wanted to. I will contact him about this.
Because of the localization bugs (unlocalizable stuff, need for disambiguation and translator comments) we should probably have a 0.44.1 and, of course, it would be nice to have it before popular distros have their next releases (Mandriva and Fedora comes to mind -- it's probably too late for SLED 10).
Arpad Biro
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Thu, Jun 08, 2006 at 01:50:47AM -0700, Arpad Biro wrote:
Hi,
- Translation status. Translation is an eternal project. I don't
know how to quantify what is good enough for release. Arpad, Matiphas, how are we doing? I think it is time to get serious about this hard freeze and turn to patches, but I want to make sure you are ready.
I know of one translator who hasn't committed yet but said he wanted to. I will contact him about this.
Because of the localization bugs (unlocalizable stuff, need for disambiguation and translator comments) we should probably have a 0.44.1...
Then we will need to have at least one translator (preferrably two) to volunteer to serve on the maintenance team for 0.44.x, to handle coordinating patches and working with the other maintenance people. Volunteers?
Bryce
Hi,
Because of the localization bugs (unlocalizable stuff, need for disambiguation and translator comments) we should probably have a 0.44.1...
Then we will need to have at least one translator (preferrably two) to volunteer to serve on the maintenance team for 0.44.x, to handle coordinating patches and working with the other maintenance people. Volunteers?
OK count me in.
Arpad Biro
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Aaron Spike <aaron@...749...> writes:
- Translation status. Translation is an eternal project. I don't know
how to quantify what is good enough for release. Arpad, Matiphas, how are we doing? I think it is time to get serious about this hard freeze and turn to patches, but I want to make sure you are ready.
I, for my part, would like to read over an SVG version of the translated tutorials (ScislaC?) - it's much easier to spot errors there than in the XML source (or po strings).
I'd also say that the open translation patches in the tracker should be checked in, for the same reason - stuff that's integrated early gets used more and thus gets fixed quicker.
Cheers, Colin
Le mercredi 07 juin 2006 à 22:52 -0500, Aaron Spike a écrit :
Bug fixing energy seems to be dwindling. To me this means it is release time. I'd like to get input from others on a few topics.
- Translation status. Translation is an eternal project. I don't know
how to quantify what is good enough for release. Arpad, Matiphas, how are we doing? I think it is time to get serious about this hard freeze and turn to patches, but I want to make sure you are ready.
Translations have been quite improved : Total number of PO files: 38 Significantly translated locales: (12 with a mean translation ratio of 98%) ca cs de es fr hu it lt ru sl zh_CN zh_TW Global average translation ratio has raised from 49% to 55%
The remaining patches dealing withfor translation are : 1502925 Catalan translation for installer 1502695 czech translation of tutorials 1500157 Tutorials translation to pt_BR 1500058 Catalan default template 1495666 updated keys.fr 1493182 updated French calligraphy tutorial 1459716 translation of Tracing tutorial into Russian
and i'd strongly recommand they get accepted/commited as soon as possible.
Regards,
matiphas
On Thu, Jun 08, 2006 at 08:31:58PM +0200, Matiphas wrote:
Le mercredi 07 juin 2006 ?? 22:52 -0500, Aaron Spike a ??crit :
Bug fixing energy seems to be dwindling. To me this means it is release time. I'd like to get input from others on a few topics.
- Translation status. Translation is an eternal project. I don't know
how to quantify what is good enough for release. Arpad, Matiphas, how are we doing? I think it is time to get serious about this hard freeze and turn to patches, but I want to make sure you are ready.
Translations have been quite improved : Total number of PO files: 38 Significantly translated locales: (12 with a mean translation ratio of 98%) ca cs de es fr hu it lt ru sl zh_CN zh_TW Global average translation ratio has raised from 49% to 55%
The remaining patches dealing withfor translation are : 1502925 Catalan translation for installer 1502695 czech translation of tutorials 1500157 Tutorials translation to pt_BR 1500058 Catalan default template 1495666 updated keys.fr 1493182 updated French calligraphy tutorial 1459716 translation of Tracing tutorial into Russian
Thanks for the update, and congrats to the whole translation team for making such an improvement!
Are there any issues regarding integration of these patches?
Bryce
The remaining patches dealing withfor translation are : 1502925 Catalan translation for installer 1502695 czech translation of tutorials 1500157 Tutorials translation to pt_BR 1500058 Catalan default template 1495666 updated keys.fr 1493182 updated French calligraphy tutorial 1459716 translation of Tracing tutorial into Russian
Are there any issues regarding integration of these patches?
As far as I've understood, it's up to the release wardens to decide.
(Btw 2 new interesting patches : 1503209 tips tutorial in Russian 1503205 calligraphy tutorial in Russian )
The tutorial patches need a little work before installation : generate svg/html from the xml (submitted with the patches) with saxon. Scislac would be able to provide more details than me on this point.
All the others are 100% ready
Regards,
matiphas
Aaron Spike wrote:
Bug fixing energy seems to be dwindling. To me this means it is release time. I'd like to get input from others on a few topics.
<snip>
Speak up now. :-)
Well, I don't think anyone has mentioned any reall show stoppers. But I didn't hear many people screaming for immediate release either. I'm going to hold off for another few days before I branch.
What will the naming convention be for the branch and the inkscape versions it contains?
Aaron Spike
On Sat, Jun 10, 2006 at 07:41:29AM -0500, Aaron Spike wrote:
Aaron Spike wrote:
Bug fixing energy seems to be dwindling. To me this means it is release time. I'd like to get input from others on a few topics.
<snip> > > Speak up now. :-)
Well, I don't think anyone has mentioned any reall show stoppers. But I didn't hear many people screaming for immediate release either. I'm going to hold off for another few days before I branch.
Ishmal voiced strong interest in a branch (I think he's itching to get back to development). I'm also anxious to see the branch happen, as I also have some marker work locally that I'd like to check in.
What will the naming convention be for the branch and the inkscape versions it contains?
According to http://wiki.inkscape.org/wiki/index.php/CreatingDists, it will be:
RELEASE_0_44_BRANCH
For reference, here are the branches present in Inkscape right now:
10649 mental Jan 15 18:44 AST/ 10650 mental Jan 15 18:44 BOOLEAN_FRED/ 10651 mental Jan 15 18:45 BORKEN/ 10652 mental Jan 15 18:45 CXXIFICATION_VIEW_AND_WIDGET/ 10653 mental Jan 15 18:46 ECMA/ 12299 dwyip Jun 10 03:06 INKBOARD_PEDRO/ 10658 mental Jan 15 18:48 RELEASE_0_36_0/ 10659 mental Jan 15 18:48 RELEASE_0_37-branch/ 10660 mental Jan 15 18:49 RELEASE_0_38_BRANCH/ 10661 mental Jan 15 18:49 RELEASE_0_39_BRANCH/ 10662 mental Jan 15 18:50 RELEASE_0_40_BRANCH/ 10663 mental Jan 15 18:50 RELEASE_0_41_BRANCH/ 10664 mental Jan 15 18:51 RELEASE_0_42_BRANCH/ 10665 mental Jan 15 18:51 RELEASE_0_43_BRANCH/ 10667 mental Jan 15 18:52 inkscape/ 12303 bryce Jun 10 11:04 inkscape-portland/ 10672 mental Jan 15 18:54 inkview_slideshow/ 11469 acspike Apr 29 17:46 live-effects/ 12019 mental May 27 14:03 memory-optimization/ 12260 kiirala Jun 08 10:49 svg-filters/
Here are the tags:
10675 mental Jan 15 18:59 BORKEN_MERGE/ 10676 mental Jan 15 19:00 BORKEN_MERGE2/ 10677 mental Jan 15 19:00 BORKEN_START/ 10678 mental Jan 15 19:01 ECMA_START/ 10679 mental Jan 15 19:01 GOOD_LIVAROT_0/ 10683 mental Jan 15 19:03 RELEASE_0_35_0/ 10761 gouldtj Jan 20 08:29 RELEASE_0_36_0/ 10684 mental Jan 15 19:04 RELEASE_0_37_0/ 10685 mental Jan 15 19:04 RELEASE_0_38_0/ 10686 mental Jan 15 19:04 RELEASE_0_38_0_BACKUP/ 10687 mental Jan 15 19:05 RELEASE_0_38_1/ 10688 mental Jan 15 19:05 RELEASE_0_39/ 10689 mental Jan 15 19:06 RELEASE_0_39_PRE_1/ 10690 mental Jan 15 19:06 RELEASE_0_39_PRE_2/ 10760 gouldtj Jan 20 08:27 RELEASE_0_39_PRE_3/ 10759 gouldtj Jan 20 08:26 RELEASE_0_39_PRE_4/ 10691 mental Jan 15 19:07 RELEASE_0_40_0/ 10692 mental Jan 15 19:07 RELEASE_0_41/ 10693 mental Jan 15 19:08 RELEASE_0_41_1/ 10694 mental Jan 15 19:08 RELEASE_0_41_PRE_1/ 10695 mental Jan 15 19:09 RELEASE_0_41_PRE_2/ 10696 mental Jan 15 19:09 RELEASE_0_41_PRE_3/ 10697 mental Jan 15 19:10 RELEASE_0_41_PRE_4/ 10698 mental Jan 15 19:10 RELEASE_0_42_0/ 10699 mental Jan 15 19:10 RELEASE_0_42_0_PRE0/ 10700 mental Jan 15 19:11 RELEASE_0_42_0_PRE1/ 10701 mental Jan 15 19:11 RELEASE_0_42_0_PRE2/ 10702 mental Jan 15 19:12 RELEASE_0_42_0_PRE3/ 10703 mental Jan 15 19:12 RELEASE_0_42_1/ 10704 mental Jan 15 19:13 RELEASE_0_42_2/ 10705 mental Jan 15 19:13 RELEASE_0_42_3/ 10706 mental Jan 15 19:14 RELEASE_0_43_0/ 10707 mental Jan 15 19:14 RELEASE_0_43_PRE0/ 10708 mental Jan 15 19:15 RELEASE_0_43_PRE1/ 10709 mental Jan 15 19:15 RELEASE_0_43_PRE2/ 10710 mental Jan 15 19:16 RELEASE_0_43_PRE3/ 11992 acspike May 25 13:19 RELEASE_0_44_PRE0/ 12091 acspike May 30 07:53 RELEASE_0_44_PRE1/ 12179 acspike Jun 03 08:16 RELEASE_0_44_PRE2/ 12241 acspike Jun 06 19:05 RELEASE_0_44_PRE3/ 10711 mental Jan 15 19:16 g++-conversion/ 10712 mental Jan 15 19:16 inkview_slideshow_START/ 10713 mental Jan 15 19:17 mergefrom_CXXIFICATION_VIEW_AND_WIDGET_08Nov05/ 10714 mental Jan 15 19:17 mergeto_trunk_08Nov05/ 10724 mental Jan 15 19:22 start/
Bryce
Bryce Harrington wrote:
Ishmal voiced strong interest in a branch (I think he's itching to get back to development). I'm also anxious to see the branch happen, as I also have some marker work locally that I'd like to check in.
Sorry, I guess I'll have to go back and read the archive. I don't remember seeing your mail, Bob. But I won't be able to do anything until Tuesday now.
What will the naming convention be for the branch and the inkscape versions it contains?
According to http://wiki.inkscape.org/wiki/index.php/CreatingDists, it will be:
RELEASE_0_44_BRANCH
Yeah. I was wondering if a stable maintained branch was different. And the in my mind a bigger question was the versioning. It will start go to 0.44 when we tag the release, but what do we do before and after that? 0.44+devel will be on HEAD.
Aaron Spike
On Sat, Jun 10, 2006 at 07:41:29AM -0500, Aaron Spike wrote:
Aaron Spike wrote:
Bug fixing energy seems to be dwindling. To me this means it is release time. I'd like to get input from others on a few topics.
<snip> > > Speak up now. :-)
Well, I don't think anyone has mentioned any reall show stoppers. But I didn't hear many people screaming for immediate release either. I'm going to hold off for another few days before I branch.
Well, a bug which needs some attention IMHO is the crash with libgc 6.7 (1497837). Since it is present in 0.43 it's not a showstopper, but it is not useable on debian unstable ATM. We should at least know if it is a bug in how inkscape uses libgc or in libgc itself. There have been some bugreports on debian on this issue recently and I'll update the mentioned bug report in the tracker with information extracted out of them ASAP. There are different backtraces arriving here, so this might in fact indicate that it is libgc's bug.
With best wishes,
Wolfi
What will the naming convention be for the branch and the inkscape versions it contains?
Aaron Spike
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Jun 10, 2006, at 2:12 PM, Wolfram Quester wrote:
Well, a bug which needs some attention IMHO is the crash with libgc 6.7 (1497837). Since it is present in 0.43 it's not a showstopper, but it is not useable on debian unstable ATM.
I've asked a few times for help from anyone able to reproduce it.
Since no one who's actually been able to experience the bug has come forward, we are on track to just ignore it and move ahead. There is nothing straightforward we can do to correct it blindly, and just guessing is as likely to do nothing as it is to fix and/or warn for things.
Hm,
On Sat, Jun 10, 2006 at 04:33:39PM -0700, Jon A. Cruz wrote:
On Jun 10, 2006, at 2:12 PM, Wolfram Quester wrote:
Well, a bug which needs some attention IMHO is the crash with libgc 6.7 (1497837). Since it is present in 0.43 it's not a showstopper, but it is not useable on debian unstable ATM.
I've asked a few times for help from anyone able to reproduce it.
Since no one who's actually been able to experience the bug has come forward, we are on track to just ignore it and move ahead. There is nothing straightforward we can do to correct it blindly, and just guessing is as likely to do nothing as it is to fix and/or warn for things.
perhaps the people using debian unstable show up in debian's BTS, not here or in SF's tracker. I won't be able to update the tracker until tomorrow however. Is debian sid the only more or less widespread distro using libgc 6.7 ATM? Wasn't Ralf using SuSE able to reproduce the crash?
See you tomorrow,
Wolfi
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (10)
-
unknown＠example.com -
Aaron Spike -
Alexandre Prokoudine -
Arpad Biro -
Bryce Harrington -
bulia byak -
Colin Marquardt -
Jon A. Cruz -
Matiphas -
Wolfram Quester