Existing show-stoppers will take sufficient amount of time, and will involve sufficiently non-trivial bug fixes, that it is more productive to lift the hard freeze for the moment. However, the feature freeze remains.
Currently, our best plan for making a release soon involves backing out (or at least disabling) the following changes:
- SPDesktop C++ification. This transformation was too rushed; has introduced at least two show-stoppers. Clean-up changes are good, but should be done cautiously, e.g. by breaking into small changes that can each be verified with reasonable confidence. The SPDesktop change has demonstrated itself not to be safe, so we'll back it out.
- Connectors. Michael is now back from overseas and can work on this, but its current state (with crashes) isn't releasable.
- menus.xml. Introduces menu localization problem. It has been useful in allowing ppl to play with the menu layout, but there's no particular reason for the functionality to be in the released stable version: it is currently for experimenters rather than customizers, as the file format still doesn't handle when menu items get added or removed from the default menu layout (e.g. new or changed functionality).
Most remaining bugs are either not regressions (so don't present a reason not to replace 0.42.2); or are platform-specific (so I can't test whether they're regressions or not, and we could consider updating inkscape on other platforms in any case); or have a priority number lower than about 7 so I've assumed they aren't show-stoppers. (I forget whether I've looked at all priority-7 bugs or not.)
pjrm.
On Tue, Sep 27, 2005 at 05:17:36PM +1000, Peter Moulder wrote:
Existing show-stoppers will take sufficient amount of time, and will involve sufficiently non-trivial bug fixes, that it is more productive to lift the hard freeze for the moment. However, the feature freeze remains.
Currently, our best plan for making a release soon involves backing out (or at least disabling) the following changes:
- SPDesktop C++ification. This transformation was too rushed; has introduced at least two show-stoppers. Clean-up changes are good, but should be done cautiously, e.g. by breaking into small changes that can each be verified with reasonable confidence. The SPDesktop change has demonstrated itself not to be safe, so we'll back it out.
What are the two show stoppers?
- Connectors. Michael is now back from overseas and can work on this, but its current state (with crashes) isn't releasable.
Actually, having played with this a lot last weekend, I suspect once one or two crashes are fixed, most of the remaining issues are mostly cosmetic. I'd rather see efforts focused on solving that crash rather than into backing this out.
Bryce
pjrm:
- SPDesktop C++ification. This transformation was too rushed; has introduced at least two show-stoppers. Clean-up changes are good, but should be done cautiously, e.g. by breaking into small changes that can each be verified with reasonable confidence.
I started with small steps but they all involved recompiling a lot for cvs users. Grumbling started. What I blame myself for is not having branched then. OTOH, no one advised me to.
The SPDesktop change has demonstrated itself not to be safe, so we'll back it out.
And possibly introduce previous bugs that just didn't show.
So I guess the order of things is: you revert, then I'll branch. Right?
ralf
On Tue, Sep 27, 2005 at 11:00:02AM +0200, Ralf Stephan wrote:
I started with small steps [...]
Yes, sorry, I realize that it might not have been possible in this particular case, and I had in my mind to write so explicitly but somehow I didn't actually do so.
Bryce & I are just discussing the best approach to fixing the SPDesktop change at the moment on Jabber/IRC. Are you able to join?
pjrm.
On Tue, Sep 27, 2005 at 11:00:02AM +0200, Ralf Stephan wrote:
pjrm:
- SPDesktop C++ification. This transformation was too rushed; has introduced at least two show-stoppers. Clean-up changes are good, but should be done cautiously, e.g. by breaking into small changes that can each be verified with reasonable confidence.
I started with small steps but they all involved recompiling a lot for cvs users. Grumbling started. What I blame myself for is not having branched then. OTOH, no one advised me to.
Actually I thought about this when you and I talked about it earlier.
I myself had also attempted to do the SPDesktop conversion prior to you but had also run into a variety of problems. I had tried to do it in one big go, but ran into a lot of problems, and so chucked the whole thing and started trying to do it bit by bit.
So... please don't feel bad about having run into some trouble here. I think it's that the conversion work is just difficult and is going to be hard work to complete successfully.
I would advocate pressing on and trying to get it to a stable point rather than backing it out. I've been debating this a bit with pjrm tonight but am not sure if I managed to convince him.
I think the SPDesktop work you're doing is very important, and worth delaying the release in order to bring it to stability. I don't know the details about the bugs encountered, but if they're what I suspect they are, it's not that there are fundamental architectural flaws or bad implementation decisions, but rather just the usual assortment of incompatibilities that come with the ripping and tearing of transplanting code and rearchitecting things around.
I think it's the right approach to bump us out of hard freeze to get these fixed, but I don't think it's necessary to back the whole change out.
The SPDesktop change has demonstrated itself not to be safe, so we'll back it out.
And possibly introduce previous bugs that just didn't show.
So I guess the order of things is: you revert, then I'll branch. Right?
Before we go to this extreme, can we see a listing of exactly what bugs we're concerned about? Maybe it's not as bad as we think.
Bryce
On 9/27/05, Bryce Harrington <bryce@...961...> wrote:
Before we go to this extreme, can we see a listing of exactly what bugs we're concerned about? Maybe it's not as bad as we think.
At least this one:
https://sourceforge.net/tracker/index.php?func=detail&aid=1303842&gr...
I also suspect this bug has the same nature:
https://sourceforge.net/tracker/index.php?func=detail&aid=1291009&gr...
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Quoting bulia byak <buliabyak@...400...>:
https://sourceforge.net/tracker/index.php?func=detail&aid=1303842&gr...
I also suspect this bug has the same nature:
https://sourceforge.net/tracker/index.php?func=detail&aid=1291009&gr...
You're correct.
This is because, for garbage-collected objects, destructors (finalizers) are not called deterministically because memory is not freed deterministically. Time-critical code should be moved out of destructors.
If I remember correctly, SPDesktop's destructor is currently responsible for withdrawing its canvas items as a side-effect of being freed. There should instead be a method for the widget to tell the desktop to do this explicitly before discarding it.
In general switching classes to the garbage collector must involve switching from C++-like to Java-like cleanup idioms. C++ programmers moving to Java often get bitten by this issue in the same way, and the solution is the same.
-mental
mental:
Quoting bulia byak <buliabyak@...400...>:
https://sourceforge.net/tracker/index.php?func=detail&aid=1303842&gr...
I also suspect this bug has the same nature:
https://sourceforge.net/tracker/index.php?func=detail&aid=1291009&gr...
You're correct. [...] If I remember correctly, SPDesktop's destructor is currently responsible for withdrawing its canvas items as a side-effect of being freed. There should instead be a method for the widget to tell the desktop to do this explicitly before discarding it.
thanks. afaik it was helpful for #1291009.
ralf
Quoting Ralf Stephan <ralf@...748...>:
If I remember correctly, SPDesktop's destructor is currently responsible for withdrawing its canvas items as a side-effect
of
being freed. There should instead be a method for the widget
to
tell the desktop to do this explicitly before discarding it.
thanks. afaik it was helpful for #1291009.
Yeah, sort of ... I've since looked at the code and as far as withdrawing canvas items, it turns out that the calls to sp_item_invoke_show() and sp_item_invoke_hide() on the root element actually happen in one of SPDesktop's various "set document" methods -- SPDesktop::setDocument, I think... but the destructor was calling it indirectly...
[ note: this is from memory, function/method names may or may not be accurate ]
-mental
On 9/27/05, Ralf Stephan <ralf@...748...> wrote:
I started with small steps but they all involved recompiling a lot for cvs users. Grumbling started. What I blame myself for is not having branched then. OTOH, no one advised me to.
Branch would not be a solution. In the trunk, these issues were found only after some time, even though everyone was using and testing the trunk. This means that in the branch (that much fewer people would use (especially since it provides no exciting new functionality, just code tweaking)) they would likely never be found at all. They would be found after the branch is merged back, i.e. we would get the same situation only with a bigger delay.
So my opinion is that, even though the changes should have been researched better and perhaps applied earlier in the release cycle, at this time we should better spend some extra time fixing them than reverting. Reverting is admitting a defeat. I'd like to avoid that, it leaves bad feelings. Let's just delay the release until we properly review, test and fix these changes.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Tue, Sep 27, 2005 at 02:57:34PM -0300, bulia byak wrote:
On 9/27/05, Ralf Stephan <ralf@...748...> wrote:
I started with small steps but they all involved recompiling a lot for cvs users. Grumbling started. What I blame myself for is not having branched then. OTOH, no one advised me to.
Branch would not be a solution. In the trunk, these issues were found only after some time, even though everyone was using and testing the trunk. This means that in the branch (that much fewer people would use (especially since it provides no exciting new functionality, just code tweaking)) they would likely never be found at all. They would be found after the branch is merged back, i.e. we would get the same situation only with a bigger delay.
So my opinion is that, even though the changes should have been researched better and perhaps applied earlier in the release cycle, at this time we should better spend some extra time fixing them than reverting. Reverting is admitting a defeat. I'd like to avoid that, it leaves bad feelings. Let's just delay the release until we properly review, test and fix these changes.
Exactly my thoughts as well. The issues being discovered are corner cases that require going through what we're going through in order to locate and solve. Painful, but necessary.
Bryce
bulia:
On 9/27/05, Ralf Stephan <ralf@...748...> wrote:
I started with small steps but they all involved recompiling a lot for cvs users. Grumbling started. What I blame myself for is not having branched then. OTOH, no one advised me to.
Branch would not be a solution. In the trunk, these issues were found only after some time, even though everyone was using and testing the trunk. This means that in the branch (that much fewer people would use (especially since it provides no exciting new functionality, just code tweaking)) they would likely never be found at all. They would be found after the branch is merged back, i.e. we would get the same situation only with a bigger delay.
Don't be so black/white! :)
Obviously, the proper way to branch (and the cvs info pages do actually recommend it this way) is to make short branches with a definite goal. Your scenario is a good argument for it.
So, branching yes, but not for long. Simply demand a certain diff size when to merge back. Say 50kb.
ralf
Peter Moulder wrote:
- menus.xml. Introduces menu localization problem. It has been useful in allowing ppl to play with the menu layout, but there's no particular reason for the functionality to be in the released stable version: it is currently for experimenters rather than customizers, as the file format still doesn't handle when menu items get added or removed from the default menu layout (e.g. new or changed functionality).
Well, I think that the localization is the issue, the other has been solved as much as it needs to be.
--Ted
You wrote
Existing show-stoppers will take sufficient amount of time, and will involve sufficiently non-trivial bug fixes, that it is more productive to lift the hard freeze for the moment. However, the feature freeze remains.
Currently, our best plan for making a release soon involves backing out (or at least disabling) the following changes:
- SPDesktop C++ification.
All known bugs are fixed pending testing. Here is the list:
http://sourceforge.net/tracker/index.php?func=detail&aid=1303842&gro... (Revert no longer works)
http://sourceforge.net/tracker/index.php?func=detail&aid=1303619&gro... (Inkscape segfaults when scrolling through a list of...)
http://sourceforge.net/tracker/index.php?func=detail&aid=1291009&gro... (new view/file new messed up)
Half of this were my own oversights, half deficencies of the previous code that magically worked (is that called voodoo?)
ralf
Ralf Stephan schrieb: .... here is a defect fixed in this period [ 1245838 ] Win32: Problem building Inkscape 0.42
I sent the patch to the release warden who applied I tested and closed the bug.
theAdib. ---
participants (7)
-
unknown＠example.com -
Adib Taraben -
Bryce Harrington -
bulia byak -
Peter Moulder -
Ralf Stephan -
Ted Gould