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?

Marked Closed/Fixed.

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 with.

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 loop (sigc++).

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.

Closed/Fixed

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).

To recap:

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.

Bryce