Remaining serious bugs:
- Some inkboard crashes, one of which may indicate a security issue. Inkboard isn't enabled by default, so I suggest we merely mention these in the release notes but not let them hold up the release.
- Various Windows issues. I'll let someone else comment on whether any of these should hold up the release.
- Connector crashes. One of these (out-of-date bboxes) may require significant change to fix properly. For the release, I suggest just changing it from a crash to a misbehaviour bug (choose an arbitrary point if !in_svg_plane(p); #include "libnr/in-svg-plane.h"). It's good to test in_svg_plane(p) before updating reprs even in absence of a crash, because inf and NaN can't be expressed in SVG.
I haven't yet changed anything in the newly-created branch like changing version numbers. See http://wiki.inkscape.org/cgi-bin/wiki.pl?CreatingDists for a list of things to change now that the branch has been created.
Release notes seem OK from a brief scan. There's an entry there marked `pjrm' which I'm just addressing now.
Still need to transcribe to NEWS, but this can wait until ReleaseNotes (http://wiki.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes) is quiescent. Bulia notes:
1 Ask everyone on jabber to read http://wiki.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes, copyedit, fill what is missing, spell-check.
2 Do
elinks -dump -no-numbering -no-references http://wiki.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes > NEWS
or in any other way convert it to plain text in the NEWS file.
3 Commit NEWS to CVS.
Screenshots: I'm not up-to-date on this yet. There has been some progress reported over the last couple of days, but I don't know where we stand.
Updated tutorials: Patch tracker items still open in places where HTML hasn't been put in inkscape_web/. One of the open patch tracker items is where we're waiting on the source XML file for an SVG version. (For the moment I haven't even put the generated SVG file into CVS, in case the XML file is changed in the meantime, but we could use the given SVG version if we don't get the XML file soon.)
pjrm.
On 11/8/05, Peter Moulder <Peter.Moulder@...38...> wrote:
Remaining serious bugs:
- Some inkboard crashes, one of which may indicate a security issue. Inkboard isn't enabled by default, so I suggest we merely mention these in the release notes but not let them hold up the release.
Yes, please mention them.
- Various Windows issues. I'll let someone else comment on whether any of these should hold up the release.
Do you have bug tracker links?
- Connector crashes.
I think we'll have to release with these. If they are fixable in the short term, we may consider 0.43.1.
I haven't yet changed anything in the newly-created branch like changing version numbers. See http://wiki.inkscape.org/cgi-bin/wiki.pl?CreatingDists for a list of things to change now that the branch has been created.
I think you can go ahead with that.
BTW what is the command to commit to that new branch? I'll need it later today to commit the edited ru.po.
Release notes seem OK from a brief scan. There's an entry there marked `pjrm' which I'm just addressing now.
One very important issue is whether we have Effects on by default or not. This must be mentioned. For me, too, Effects menu is visible after I delete preferences.xml, but Ted says it can't be so. Please try to figure out what's going on.
Still need to transcribe to NEWS, but this can wait until ReleaseNotes (http://wiki.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes) is quiescent. Bulia notes:
1 Ask everyone on jabber to read http://wiki.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes, copyedit, fill what is missing, spell-check.
2 Do
elinks -dump -no-numbering -no-references http://wiki.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes > NEWS
or in any other way convert it to plain text in the NEWS file.
3 Commit NEWS to CVS.
Just don't forget to commit it to the branch.
Screenshots: I'm not up-to-date on this yet. There has been some progress reported over the last couple of days, but I don't know where we stand.
All OK, lots of nice screenshots now.
Updated tutorials: Patch tracker items still open in places where HTML hasn't been put in inkscape_web/. One of the open patch tracker items is where we're waiting on the source XML file for an SVG version. (For the moment I haven't even put the generated SVG file into CVS, in case the XML file is changed in the meantime, but we could use the given SVG version if we don't get the XML file soon.)
And these will need to be committed both to the branch and to HEAD.
Please keep us posted on the progress.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
bulia byak wrote:
Release notes seem OK from a brief scan. There's an entry there marked `pjrm' which I'm just addressing now.
One very important issue is whether we have Effects on by default or not. This must be mentioned. For me, too, Effects menu is visible after I delete preferences.xml, but Ted says it can't be so. Please try to figure out what's going on.
Seeing what people are reporting here, there is probably a mistake in the menu code not honoring the preference setting. I'll fix it tonight when I have the code in front of me.
--Ted
On Tue, Nov 08, 2005 at 03:55:30PM -0400, bulia byak wrote:
On 11/8/05, Peter Moulder <Peter.Moulder@...38...> wrote:
Remaining serious bugs:
- Some inkboard crashes, one of which may indicate a security issue. Inkboard isn't enabled by default, so I suggest we merely mention these in the release notes but not let them hold up the release.
Yes, please mention them.
Last night I added some text after `must be enabled at compile time' in the detail section on inkboard.
- Various Windows issues. I'll let someone else comment on whether any of these should hold up the release.
Do you have bug tracker links?
Easiest is to view bug tracker (http://sourceforge.net/tracker/?group_id=93438&atid=604306) by descending Priority.
I haven't yet changed anything in the newly-created branch like changing version numbers. See http://wiki.inkscape.org/cgi-bin/wiki.pl?CreatingDists for a list of things to change now that the branch has been created.
I think you can go ahead with that.
BTW what is the command to commit to that new branch? I'll need it later today to commit the edited ru.po.
cvs -q up -Pd -r RELEASE_0_43_BRANCH
If, like me, you're in the habit of typing `cvs -q up -PAd' to get the latest version, then remember to break that habit when working on the branch :) . (`-A' means to switch to the HEAD version of each file, discarding any sticky tags.)
Release notes seem OK from a brief scan. There's an entry there marked `pjrm' which I'm just addressing now.
(Now addressed.)
pjrm.
- Various Windows issues. I'll let someone else comment on whether any of these should hold up the release.
Do you have bug tracker links?
Easiest is to view bug tracker (http://sourceforge.net/tracker/?group_id=93438&atid=604306) by descending Priority.
I have a patch in my local tree to switch from using the pango-ft2 backend to pango-win32 which should fix a large number of win32 bugs (1329863,1323437,1296310,1287763,1309726,1226656,1188530,1173133 and 1097049, I think. The same problem keeps getting reported in different ways because there are lots of places which use text). It's medium-sized (4 files) and cannot be rated as safe.
For those of you on Linux, the fundamental issue here is that Windows users do not, in general, have fontconfig caches ready-built, so the first time they use Inkscape it will do a scan of all fonts in the system. If you have any two of the three [slow processor,many fonts,on-access virus scanner] then this can take a significant amount of time (we're talking minutes). The problem is compounded by several issues:
- There is no feedback whatsoever as to what is going on. Not even an hourglass.
- There's a bug in the current fontconfig which will cause the cache to be written incorrectly if you have fonts in subdirectories, meaning that Inkscape will re-scan every time.
- The scan is done the first time Inkscape needs to render some text, which is all over the place: pressing the first key in the text tool, opening the text and font dialog, viewing one of the tutorials, or even using File|Open (there's text in the 'no preview' image).
Given all this, we would appear to have a few options:
1) What I was planning to do was let 0.43 go out still containing the problem. It's been in there for loads of releases already, what's one more?
2) Throw my patch in to the branch and hope it doesn't break anything. Yeah, right.
3) Put my patch in the branch and delay release for yet another week or so to get it tested.
4) Release Linux and MacOS now, put my patch in the branch, and test for another week before releasing Win32.
5) Create a 0.43.1 for it.
I realise this isn't the best time to be talking about this, but I only got round to fixing it yesterday.
Richard.
Quoting Richard Hughes <cyreve@...400...>:
- Release Linux and MacOS now, put my patch in the branch, and
test for another week before releasing Win32.
- Create a 0.43.1 for it.
These two would have to go together.
Anyone should be able to build from the 0.43[.0] source tarball and get the same application as the 0.43[.0] binary release for their platform.
We don't want to have a "special" 0.43[.0] just for Windows.
That said, I think it may be the best option. i.e. don't have a Win32 release for 0.43, but follow up with an 0.43.1 release for everybody.
-mental
On 11/8/05, Richard Hughes <cyreve@...400...> wrote:
I have a patch in my local tree to switch from using the pango-ft2 backend to pango-win32 which should fix a large number of win32 bugs (1329863,1323437,1296310,1287763,1309726,1226656,1188530,1173133 and 1097049, I think. The same problem keeps getting reported in different ways because there are lots of places which use text). It's medium-sized (4 files) and cannot be rated as safe.
That sounds impressive, but raises a few questions:
- how well maintained is the win32 backend? Better or worse than ft2?
- I vaguely remember that long ago, during sodipodi times or right after the fork, we have switched back from some win32 font code - was it the reverse of what you are planning to do now, or something different? Can anyone with a memory longer than mine throw some light?
- how much additional maintenance will be required to support the win32 backend in inkscape?
Overall, so far I'm rather in favor of doing this for 0.44.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
- how well maintained is the win32 backend? Better or worse than ft2?
The ft2 backend is only as good as its weakest link, which in this case is clearly fontconfig. Fixing that up so it no longer has all these bugs would be a big task which would, as far as I know, only get used and tested by us and Dia.
The win32 backend is used by gdk-win32 for such things as widget rendering, so it should stay functional. Inkscape uses a broader set of functions than are needed by gdk but it should be OK.
- how much additional maintenance will be required to support the
win32 backend in inkscape?
Some. The files in question have changed about once every three months during the past year, all of them fairly minor bug fixes. The fact that this is my area should make it more likely that it stays up to date. Incidentally, Mental will blow his top when he sees how many #ifdefs are used, but I wanted to keep the two code paths next to each other as much as possible so that it's easy to change one when the other changes.
Richard.
On Nov 8, 2005, at 4:47 PM, Richard Hughes wrote:
Incidentally, Mental will blow his top when he sees how many #ifdefs are used, but I wanted to keep the two code paths next to each other as much as possible so that it's easy to change one when the other changes.
#ifdef's ?!?!?!?1
EEEEEEEEEEEEEEEEEEEEEEeeeeeeeeeeeeekkkkkkkkkkkkkk!!!!!
;-)
Once it's in I'll see if there's any cleaning up we can do.
On Wed, 2005-11-09 at 00:47 +0000, Richard Hughes wrote:
I wanted to keep the two code paths next to each other as much as possible so that it's easy to change one when the other changes.
Are there forces preventing you from factoring out the common bits of the two codepaths into a common codepath? It sounds as if there is quite a lot of redundancy which would lend itself to factoring.
Incidentally, Mental will blow his top when he sees how many #ifdefs are used,
Edsger Dijkstra once wrote, "Years from now, if you are doing something quick and dirty, you imagine that I am looking over your shoulder and say to yourself, 'Dijkstra would not like this,' well that would be immortality for me."
-mental
Are there forces preventing you from factoring out the common bits of the two codepaths into a common codepath? It sounds as if there is quite a lot of redundancy which would lend itself to factoring.
It's because of the factoring that the #ifdefs are so dense:
...common code... #ifdef USE_PANGO_WIN32 pango_win32_foo() #else pango_ft2_bar() #endif ...common code...
That's an oversimplified example, of course. There are no functions with 1:1 equivalence because Pango has polymorphism so if there were it would already have been done.
BTW, the only reason I'm waiting before I commit is for Ralf's 'train wreck' (/me ducks) to calm down a bit.
Richard.
On 11/8/05, Peter Moulder <Peter.Moulder@...38...> wrote:
cvs -q up -Pd -r RELEASE_0_43_BRANCH
I can't seem to be able to do this. Perhaps because I need to update from that branch first. But I don't want to do this because I have lots of other uncommitted stuff. So I committed the newest ru.po to HEAD, revision 112. Can you please move it over to the release branch?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Tue, Nov 08, 2005 at 10:38:15PM -0400, bulia byak wrote:
On 11/8/05, Peter Moulder <Peter.Moulder@...38...> wrote:
cvs -q up -Pd -r RELEASE_0_43_BRANCH
I can't seem to be able to do this. Perhaps because I need to update from that branch first. But I don't want to do this because I have lots of other uncommitted stuff.
I suggest using separate working directories for the separate branches. Thus you might do a clean checkout:
cvs -Q checkout -r RELEASE_0_43_BRANCH -d inkscape-0.43-branch cd inkscae-0.43-branch
(Indeed, I'd suggest using separate working directories for separate changes, so long as you have enough disk space. I keep a directory of a clean inkscape head, and I cp -a that directory whenever I want to start a new change.)
So I committed the newest ru.po to HEAD, revision 112. Can you please move it over to the release branch?
Will do.
pjrm.
participants (7)
-
unknown＠example.com -
bulia byak -
Jon A. Cruz -
MenTaLguY -
Peter Moulder -
Richard Hughes -
Ted Gould