On Thu, 27 Jan 2005, bulia byak wrote:
> Here's my take on which bugs we must/should/ought to (try to) fix for
> the release, some of them because they're bad, some because they're
> relatively easy to fix or maybe already fixed. Those on Windows are
> marked correspondingly.
Here's my suggestion for triaging and of which bugs appear to be
acceptable as must-fix.
> WIN 1069560 - annoying and pretty frequent, does anyone has an idea of
> what's happening there?
This one should be postponed. There is no owner, no evidence of
progress in the comments, and the bug does not cause application crash
or loss of data.
> 1108667 & 1086769 - may be the same bug but may be not, I cannot check
> because I don't have these input methods installed
The latter bug has an owner (Jon) and a backtrace. If they are indeed
related that could boost their importance, but it is not clear that they
are related. Neither of these have had much progress, and they only
occur under specialized circumstances (Korean font, or 'uim-canna').
While important, I do not think they can be considered must-fix bugs.
> 1107922 - may be fixed by now, but I never could reproduce it anyway
This one includes a backtrace, has an owner, has had good recent
activity in comments, and in theory can be replicated on Linux. Bulia
and Mental indicate they feel it to be a Must-Fix bug. The difficulty
in reproducing it scores against it, but otherwise I think it looks
acceptable as a Must-Fix bug.
> WIN 1107305 - something's wrong with Windows paths after Kees changed
> them. Need more details.
This one includes error messages, looks reproduceable, has recent
activity in the comments, and has an owner. It requires someone to help
Kees with how to create an umlauted username, but otherwise looks
acceptable as a Must-Fix bug.
> 1102678 - need to force libxml to load external DTD (OK, I'll look at
> it once more, now that I have a newer libxml)
This does not have an owner, does not have much activity in the comment
log, does not cause a crash or data loss, and is only marked as a level
6. This does not look like it qualifies as a Must-Fix bug.
> WIN 1095300 - need more info from windows folks, is it still there?
> 1093060 - an easy-to-run-into freeze, I upped priority to 9, must be
> fixed (Mental?)
This has an owner, sounds pretty easy to replicate, and has a theory as
to why it occurs. Unfortunately, it sounds like it would take a
significant amount of time to fix. I think unless a simple kludge
work-around can be developed, this will have to be postponed.
> WIN 1050361 - still can't open svgz on windows (again!)? It used to
> work, does anyone know what happened?
Has lots of activity in the comments, has an owner (ishmal), sounds easy
to recreate, and is a regression (svgz worked in 0.40). I think this
qualifies as a Must-Fix, however Ishmal hasn't commented on this bug so
either it needs to be brought to his attention or someone else needs to
volunteer to work on it.
> 1055034 - do we now check for correct versions of libsigc? Can this be closed?
This can be closed, but not for the reasons stated in the bug. This is
actually a very common problem that I've helped half a dozen people
Between gcc 3.3.x and 3.4.x, the C++ linkage behavior appears to have
been changed. This means that if you have some C++ libraries (sigc++,
gtkmm, glibmm) compiled with gcc 3.3.x, and try to build Inkscape using
3.4.x, it may seem to compile and link correctly, but it will either
exhibit strange behaviors: It may work fine on the commandline but
crash or lock up when run with the gui (gtkmm problem), or it may always
fail to start (glibmm I think), or will seem to start but get stuck in a
The fix is always to compile those three libs and inkscape using the
same version of gcc (either 3.3.x or 3.4.x, but not a mix).
As you can imagine, this cropped up a lot for the gentoo Inkscape users. ;-)
> WIN 1070816 - I guess there's no progress on this one. Looks like
> we'll have to release with it again.
Agreed. Like 1093060, this one seems to qualify as a Must-Fix, but the
solution seems to be hard to attain.
> WIN 1073459 - This one frustrates me. It may be fixed but we can't
> figure out for sure yet. I asked about it before but got no definitive
> answer. Those who builds on Windows: Please check which version of
> libgc (boehm) you are using. If it is 6.4 AND you use latest CVS, see
> if you can reproduce this bug. If it's not 6.4, ask the person you got
> it from (Ishmal?) for this version. PLEASE LET'S CLOSE THIS ONE. It
> alone is worth a release.
> WIN 1076627 - Jon Cruz is working on that, is there chance it will be fixed?
I think this one should be postponed. This one has an owner, has decent
activity in the comments, and sounds bad enough, but it looks like there
isn't enough detail to replicate it.
> WIN 1068818 & 959352 - this may be the same bug or may be not.
These should be postponed. Both of these are a bit old, and it sounds
like developers are having trouble replicating them. There is some
activity in the comments but it does not look like progress is being
made recently (within the past couple months).
1107922 - Acceptable as Must-Fix [mental]
1107305 - Acceptable as Must-Fix [nemies] (WIN)
1050361 - Acceptable as Must-Fix [ishmal] (WIN svgz)
1069560 - POSTPONE (WIN warning msg)
1108667 - POSTPONE (input methods)
1086769 - POSTPONE (input methods)
1102678 - POSTPONE (libxml)
1093060 - POSTPONE (hard to fix)
1070816 - POSTPONE (hard to fix)
1076627 - POSTPONE (hard to replicate)
1068818 - POSTPONE (hard to replicate)
959352 - POSTPONE (hard to replicate)
1095300 - fixed
1055034 - fixed
1073459 - fixed
I think three Must-Fix bugs are reasonable to expect to be fixed by the
1st, so if the above triage is used we can proceed as planned.