It feels like things are getting close to being ready for a freeze, and to start preparing for the release. There's a lot of work still going on, and we don't want to interrupt things abruptly, so it may be worthwhile to settle on some loose target dates. How does the following plan sound?
1. 'Feature chill' - June 28. No new features should be started, work should be wrapping up on existing features and code cleanup. Unfinished features should be hidden. Focus should be on bug fixing.
2. 'Feature freeze' - Sometime in first week of July. Only bug fixing should occur after this point. Focus should be on closing critical bugs and bugs in new features.
3. 'Hard freeze' - When all major bugs have been closed that we intend to close, we go into a short hard freeze period for a few days where no changes are allowed except under strict change control. We do final QA, verify on as many platforms as possible, create the packages and verify they work well, and make sure no last minute bugs slipped in.
4. 'Release'
Bryce
This sounds good to me.
How about 0.39pre2 on the 28th?
The last things that I'd like to get in before 0.39 are the path handling in import and export. I think that both of those are very doable by then.
--Ted
On Sat, 2004-06-26 at 10:29, Bryce Harrington wrote:
It feels like things are getting close to being ready for a freeze, and to start preparing for the release. There's a lot of work still going on, and we don't want to interrupt things abruptly, so it may be worthwhile to settle on some loose target dates. How does the following plan sound?
'Feature chill' - June 28. No new features should be started, work should be wrapping up on existing features and code cleanup. Unfinished features should be hidden. Focus should be on bug fixing.
'Feature freeze' - Sometime in first week of July. Only bug fixing should occur after this point. Focus should be on closing critical bugs and bugs in new features.
'Hard freeze' - When all major bugs have been closed that we intend to close, we go into a short hard freeze period for a few days where no changes are allowed except under strict change control. We do final QA, verify on as many platforms as possible, create the packages and verify they work well, and make sure no last minute bugs slipped in.
'Release'
Bryce
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, Jun 26, 2004 at 10:29:42AM -0700, Bryce Harrington wrote:
'Feature chill' - June 28. No new features should be started, work should be wrapping up on existing features and code cleanup. Unfinished features should be hidden. Focus should be on bug fixing.
'Feature freeze' - Sometime in first week of July. Only bug fixing should occur after this point. Focus should be on closing critical bugs and bugs in new features.
Do I read this right to think that I've got from today until the first week of July to finish the metadata importing/exporting stuff to get it into the 0.39 release?
On Mon, 28 Jun 2004, Kees Cook wrote:
On Sat, Jun 26, 2004 at 10:29:42AM -0700, Bryce Harrington wrote:
'Feature chill' - June 28. No new features should be started, work should be wrapping up on existing features and code cleanup. Unfinished features should be hidden. Focus should be on bug fixing.
'Feature freeze' - Sometime in first week of July. Only bug fixing should occur after this point. Focus should be on closing critical bugs and bugs in new features.
Do I read this right to think that I've got from today until the first week of July to finish the metadata importing/exporting stuff to get it into the 0.39 release?
Yes.
Bryce
Hmm, since there was absolutely no response, either everyone agrees or thinks I'm a nut!
Brazenly assuming the former, I guess we can start the gradual freeze process, with today being the start of the 'feature chill'. Folks wishing to start new features can do so on branches, and plan to re-merge after the release, like we did last time.
Figure about a week for us to move to the next step; if you think we need more time or should move quicker, just shout.
Bryce
On Sat, 26 Jun 2004, Bryce Harrington wrote:
It feels like things are getting close to being ready for a freeze, and to start preparing for the release. There's a lot of work still going on, and we don't want to interrupt things abruptly, so it may be worthwhile to settle on some loose target dates. How does the following plan sound?
'Feature chill' - June 28. No new features should be started, work should be wrapping up on existing features and code cleanup. Unfinished features should be hidden. Focus should be on bug fixing.
'Feature freeze' - Sometime in first week of July. Only bug fixing should occur after this point. Focus should be on closing critical bugs and bugs in new features.
'Hard freeze' - When all major bugs have been closed that we intend to close, we go into a short hard freeze period for a few days where no changes are allowed except under strict change control. We do final QA, verify on as many platforms as possible, create the packages and verify they work well, and make sure no last minute bugs slipped in.
'Release'
Bryce
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
This sounds great Bryce...I agree. We need to get a release out...what shall we name this release? It is such a big release...almost to the point of a two point jump release...
Jon
On Mon, 2004-06-28 at 22:12, Bryce Harrington wrote:
Hmm, since there was absolutely no response, either everyone agrees or thinks I'm a nut!
Brazenly assuming the former, I guess we can start the gradual freeze process, with today being the start of the 'feature chill'. Folks wishing to start new features can do so on branches, and plan to re-merge after the release, like we did last time.
Figure about a week for us to move to the next step; if you think we need more time or should move quicker, just shout.
Bryce
On Sat, 26 Jun 2004, Bryce Harrington wrote:
It feels like things are getting close to being ready for a freeze, and to start preparing for the release. There's a lot of work still going on, and we don't want to interrupt things abruptly, so it may be worthwhile to settle on some loose target dates. How does the following plan sound?
'Feature chill' - June 28. No new features should be started, work should be wrapping up on existing features and code cleanup. Unfinished features should be hidden. Focus should be on bug fixing.
'Feature freeze' - Sometime in first week of July. Only bug fixing should occur after this point. Focus should be on closing critical bugs and bugs in new features.
'Hard freeze' - When all major bugs have been closed that we intend to close, we go into a short hard freeze period for a few days where no changes are allowed except under strict change control. We do final QA, verify on as many platforms as possible, create the packages and verify they work well, and make sure no last minute bugs slipped in.
'Release'
Bryce
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi all,
I think we are ready to move into the 'feature freeze' portion of the release cycle, as we had anticipated last week.
In this phase, the focus should be on bug fixing only, not on adding features, nor code cleanup or optimization. The length of this phase will be controlled by how quickly we can gain closure on enough of the critical bugs.
There's currently 85 bugs, with about 20 bugs at the critical priority level. I think a reasonable goal would be to reduce the critical bug count to 10 or fewer. It would also be nice to reduce our bug open/total percentage from its current 18% to 15%.
Bryce
On Sat, 26 Jun 2004, Bryce Harrington wrote:
It feels like things are getting close to being ready for a freeze, and to start preparing for the release. There's a lot of work still going on, and we don't want to interrupt things abruptly, so it may be worthwhile to settle on some loose target dates. How does the following plan sound?
'Feature chill' - June 28. No new features should be started, work should be wrapping up on existing features and code cleanup. Unfinished features should be hidden. Focus should be on bug fixing.
'Feature freeze' - Sometime in first week of July. Only bug fixing should occur after this point. Focus should be on closing critical bugs and bugs in new features.
'Hard freeze' - When all major bugs have been closed that we intend to close, we go into a short hard freeze period for a few days where no changes are allowed except under strict change control. We do final QA, verify on as many platforms as possible, create the packages and verify they work well, and make sure no last minute bugs slipped in.
'Release'
Bryce
Regarding the status of layers, it looks like the "edit group as layer" functionality is complete except for bugfixes.
I was hoping to reintroduce "inkscape:groupmode" before the code freeze, but that would also necessitate some additional UI work to accomodate the cases that would raise.
But I think "edit group as layer" is useful by itself, so I think we should keep the "layer selector" at the bottom, even given this limited functionality, because it makes it clear what is happening.
-mental
On Tue, Jul 06, 2004 at 09:22:42PM -0400, MenTaLguY wrote:
But I think "edit group as layer" is useful by itself, so I think we should keep the "layer selector" at the bottom, even given this limited functionality, because it makes it clear what is happening.
I see the layer selector, but how do I actually use the layers? I skipped the whole layer discussion figuring I'd wait until it was done before asking questions. :)
On Wed, 2004-07-07 at 03:47, Kees Cook wrote:
I see the layer selector, but how do I actually use the layers? I skipped the whole layer discussion figuring I'd wait until it was done before asking questions. :)
Well, we have layers implemented internally, but not really enough UI for them. What I did was take the layers UI we did have, trim off a few of the rough edges, and call it the "Edit group" feature.
Just right-click on a group, select "Edit group", and, until you leave it, you can draw within/select objects as if it were a layer.
To leave a group, either:
* select an object outside it
* select "Edit root" or "Edit parent group" from the context menu
* use the layer selector to select one of its ancestors instead
That's pretty much all there is to it right now.
-mental
We've met the numerical goal for our critical bug count for this release, so it is time to start thinking of entering our final stage of the release cycle.
In case there are still bugs people are working on, I think we should give it another day or two before entering the hard freeze phase. If anyone needs more time than that, let me know and we'll figure it out.
Also, I've re-reviewed all the bugs in the tracker, and it looks like we're pretty good. We've still got some odd crash bugs and quirky behaviors, and hopefully at least a few of those can be taken care of in the near future, but in general there don't appear to be any that should prevent us from proceeding into the hard freeze.
It would be a good idea at this time for folks to browse through the bug list and if you see anything that you feel *must* be fixed prior to the release, to indicate here who is working on it and specify why it needs to be fixed for this release.
Bryce
On Sat, 26 Jun 2004, Bryce Harrington wrote:
It feels like things are getting close to being ready for a freeze, and to start preparing for the release. There's a lot of work still going on, and we don't want to interrupt things abruptly, so it may be worthwhile to settle on some loose target dates. How does the following plan sound?
'Feature chill' - June 28. No new features should be started, work should be wrapping up on existing features and code cleanup. Unfinished features should be hidden. Focus should be on bug fixing.
'Feature freeze' - Sometime in first week of July. Only bug fixing should occur after this point. Focus should be on closing critical bugs and bugs in new features.
'Hard freeze' - When all major bugs have been closed that we intend to close, we go into a short hard freeze period for a few days where no changes are allowed except under strict change control. We do final QA, verify on as many platforms as possible, create the packages and verify they work well, and make sure no last minute bugs slipped in.
'Release'
Bryce
This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 9 Jul 2004, Bryce Harrington wrote:
We've met the numerical goal for our critical bug count for this release, so it is time to start thinking of entering our final stage of the release cycle.
In case there are still bugs people are working on, I think we should give it another day or two before entering the hard freeze phase. If anyone needs more time than that, let me know and we'll figure it out.
I'm having difficulty fixing all the snapping issues that are in a priority 9 bug on the tracker. Several of them would be hidden by removing the option to set the scale origin to the bounding box. Should I do this before the release (assuming I can't fix the bugs before the hard freeze) ?
Carl
I'm having difficulty fixing all the snapping issues that are in a priority 9 bug on the tracker. Several of them would be hidden by removing the option to set the scale origin to the bounding box. Should I do this before the release (assuming I can't fix the bugs before the hard freeze) ?
Yes, anything that is as good or better than what we had before will do, even if it's less than what was originally planned :)
I'm having difficulty fixing all the snapping issues that are in a priority 9 bug on the tracker. Several of them would be hidden by removing the option to set the scale origin to the bounding box. Should I do this before the release (assuming I can't fix the bugs before the hard freeze) ?
Carl,
Since the displacement-when-scaling bug is not yet fixed, could you please remove that option and restore the old behavior? In its present form, I condsider this a bad enough regression. On the other hand, I may misunderstand something, but the old behavior was exactly this - scale against the opposite side of the bounding box, and it worked (probably it also did not account for stroke width compensation, but your bug is worse than that, it drifts even before compensation is done). Why can't you just keep that code? The new mode that you added - scaling against the opposite node - seems to work OK and I would like to keep it.
On Sat, 10 Jul 2004, bulia byak wrote:
I'm having difficulty fixing all the snapping issues that are in a priority 9 bug on the tracker. Several of them would be hidden by removing the option to set the scale origin to the bounding box. Should I do this before the release (assuming I can't fix the bugs before the hard freeze) ?
Carl,
Since the displacement-when-scaling bug is not yet fixed, could you please remove that option and restore the old behavior? In its present form, I condsider this a bad enough regression. On the other hand, I may misunderstand something, but the old behavior was exactly this - scale against the opposite side of the bounding box, and it worked (probably it also did not account for stroke width compensation, but your bug is worse than that, it drifts even before compensation is done). Why can't you just keep that code? The new mode that you added
- scaling against the opposite node - seems to work OK and I would
like to keep it.
Why is there a regression wrt bounding box origins --- that's a good question. I'll look into it tomorrow and either remove the option or fix it.
Carl
Carl,
I just tried snapping and there are a few problems as well:
1 There are three options now, "snap to grid", "snap bboxes" and "snap points". The first one apparently has no effect and seems to be superceded by the other two. Why not remove it?
2 The # key turns on grid _and_ snapping to the grid, but it changes the obsolete option "snap to grid". Instead it should turn on the two new options (or only one of them, if you think this is a better default). Otherwise pressing # does not enable any snapping at all.
3 Snapping bboxes works when you drag or scale the object by the corner handle, but not when you scale it by a side handle. It must work there too.
Could you please try to fix these issues (especially 2) before the release?
On Sun, 11 Jul 2004, bulia byak wrote:
Carl,
I just tried snapping and there are a few problems as well:
1 There are three options now, "snap to grid", "snap bboxes" and "snap points". The first one apparently has no effect and seems to be superceded by the other two. Why not remove it?
2 The # key turns on grid _and_ snapping to the grid, but it changes the obsolete option "snap to grid". Instead it should turn on the two new options (or only one of them, if you think this is a better default). Otherwise pressing # does not enable any snapping at all.
3 Snapping bboxes works when you drag or scale the object by the corner handle, but not when you scale it by a side handle. It must work there too.
Could you please try to fix these issues (especially 2) before the release?
These three things are now fixed in CVS.
Carl
On Sat, 10 Jul 2004, bulia byak wrote:
I'm having difficulty fixing all the snapping issues that are in a priority 9 bug on the tracker. Several of them would be hidden by removing the option to set the scale origin to the bounding box. Should I do this before the release (assuming I can't fix the bugs before the hard freeze) ?
Carl,
Since the displacement-when-scaling bug is not yet fixed, could you please remove that option and restore the old behavior? In its present form, I condsider this a bad enough regression. On the other hand, I may misunderstand something, but the old behavior was exactly this - scale against the opposite side of the bounding box, and it worked (probably it also did not account for stroke width compensation, but your bug is worse than that, it drifts even before compensation is done). Why can't you just keep that code? The new mode that you added
- scaling against the opposite node - seems to work OK and I would
like to keep it.
Why is there a regression wrt bounding box origins --- that's a good question. I'll look into it tomorrow and either remove the option or fix it.
Well, I've just tried 0.38.1, and the scale-with-snap behaviour is really just as bad as it is now; the drift occurs, and also the jumping around in scale factor.
I don't think the current code is any worse than this; it seems to be a bug that's been there for a while.
Carl
It would be a good idea at this time for folks to browse through the bug list and if you see anything that you feel *must* be fixed prior to the release, to indicate here who is working on it and specify why it needs to be fixed for this release.
From my perspective, the showstopper is Ted's export dialog issues.
They're not in the tracker but he knows what they are. As soon as they are fixed I think we can release.
On Fri, 9 Jul 2004, bulia byak wrote:
It would be a good idea at this time for folks to browse through the bug list and if you see anything that you feel *must* be fixed prior to the release, to indicate here who is working on it and specify why it needs to be fixed for this release.
From my perspective, the showstopper is Ted's export dialog issues.
They're not in the tracker but he knows what they are. As soon as they are fixed I think we can release.
Okay, can you enter a ticket for these issues so we can track them? (And so folks can help if so-inclined.)
Thanks, Bryce
Bryce Harrington <bryce@...260...> writes:
We've met the numerical goal for our critical bug count for this release, so it is time to start thinking of entering our final stage of the release cycle.
This would also mean "string freeze", right? Maybe it's a good time now to ping recent translators to have them update their translations at "hard freeze".
Cheers, Colin
On Fri, 9 Jul 2004, Colin Marquardt wrote:
Bryce Harrington <bryce@...260...> writes:
We've met the numerical goal for our critical bug count for this release, so it is time to start thinking of entering our final stage of the release cycle.
This would also mean "string freeze", right? Maybe it's a good time now to ping recent translators to have them update their translations at "hard freeze".
Yes, that's a good idea.
Bryce
On Fri, Jul 09, 2004 at 01:15:49AM -0700, Bryce Harrington wrote:
In case there are still bugs people are working on, I think we should give it another day or two before entering the hard freeze phase. If anyone needs more time than that, let me know and we'll figure it out.
I'd like to see 984902 fixed before we release: it's not a "corner case", it can show up just from someone clicking around examining a dialog. I intend to continue looking at it this evening (if no one else gets a chance to).
Kees Cook wrote:
On Fri, Jul 09, 2004 at 01:15:49AM -0700, Bryce Harrington wrote:
In case there are still bugs people are working on, I think we should give it another day or two before entering the hard freeze phase. If anyone needs more time than that, let me know and we'll figure it out.
I'd like to see 984902 fixed before we release: it's not a "corner case", it can show up just from someone clicking around examining a dialog. I intend to continue looking at it this evening (if no one else gets a chance to).
I also looked at it for a while in Gdb and Valgrind, to no avail. There were too many warnings from Valgrind about other things in Inkscape ( oops ;) to zero-in on the proper thing. Gdb showed the stacktrace below.
Now, if that line is really where the prog dies, and an auto-constructor is coredumping, then I would suspect a memory out-of-bounds problem, or some other new/delete or malloc/free thing happening -before- that line is called, thus screwing up the heap or stack.
I hope you have better luck with this.
===== SNIP ======
782 Inkscape::SVGOStringStream osalpha; (gdb) where #0 0x00dd5bac in g_type_check_instance_cast () at dialogs/fill-style.cpp:782 #1 0x0818558c in sp_paint_selector_get_pattern (psel=0x1) at widgets/paint-selector.cpp:969 #2 0x08172e6d in sp_fill_style_widget_paint_changed (psel=0x9852b88, spw=0x9853618) at dialogs/fill-style.cpp:896 #3 0x00dcc691 in g_cclosure_marshal_VOID__VOID () at dialogs/fill-style.cpp:782 #4 0x00db8160 in g_closure_invoke () at dialogs/fill-style.cpp:782 #5 0x00dcc195 in g_signal_emit_by_name () at dialogs/fill-style.cpp:782 #6 0x00dcb157 in g_signal_emit_valist () at dialogs/fill-style.cpp:782 #7 0x005c5379 in gtk_signal_emit () at dialogs/fill-style.cpp:782 #8 0x00dcc691 in g_cclosure_marshal_VOID__VOID () at dialogs/fill-style.cpp:782 #9 0x00db8160 in g_closure_invoke () at dialogs/fill-style.cpp:782 #10 0x00dcc195 in g_signal_emit_by_name () at dialogs/fill-style.cpp:782 #11 0x00dcb157 in g_signal_emit_valist () at dialogs/fill-style.cpp:782 #12 0x005c5379 in gtk_signal_emit () at dialogs/fill-style.cpp:782 #13 0x0818bfb3 in ColorSelector::setColorAlpha (this=0x71d7b4, color=@0x986bdf0, alpha=0.75) at widgets/sp-color-selector.cpp:239 #14 0x08185047 in sp_paint_selector_set_mode (psel=0x9852b88, mode=SP_PAINT_SELECTOR_MODE_COLOR_RGB) at widgets/paint-selector.cpp:711 #15 0x00dcc691 in g_cclosure_marshal_VOID__VOID () at dialogs/fill-style.cpp:782
Kees Cook wrote:
I'd like to see 984902 fixed before we release: it's not a "corner case", it can show up just from someone clicking around examining a dialog. I intend to continue looking at it this evening (if no one else gets a chance to).
I too think 984902 is a show-stopper. I would even prefer simply suppressing the pattern button for this release. Next release we're looking at moving to gtkmm-2.4, so some of that code will need looking at anyway.
pjrm.
On Sat, Jul 10, 2004 at 09:57:04AM +1000, Peter Moulder wrote:
Kees Cook wrote:
I'd like to see 984902 fixed before we release: it's not a "corner case", it can show up just from someone clicking around examining a dialog. I intend to continue looking at it this evening (if no one else gets a chance to).
I too think 984902 is a show-stopper. I would even prefer simply suppressing the pattern button for this release. Next release we're looking at moving to gtkmm-2.4, so some of that code will need looking at anyway.
I've almost got this one solved. Basically, it has to do with how GTK handles clean-up of widgets. I have to unhook the menu from the container before doing anything else. And the ref counter needs to be bumped like pjrm mentioned in the bug.
I should have a fix checked in shortly...
On Fri, 2004-07-09 at 16:00, Kees Cook wrote:
I'd like to see 984902 fixed before we release: it's not a "corner case", it can show up just from someone clicking around examining a dialog. I intend to continue looking at it this evening (if no one else gets a chance to).
#979858 is another important one for me (although I am still determining for sure that it is the problem I am experiencing); it is preventing me from handing off work to a Windows Inkscape user.
-mental
--- MenTaLguY <mental@...3...> wrote:
#979858 is another important one for me (although I am still determining for sure that it is the problem I am experiencing); it is preventing me from handing off work to a Windows Inkscape user.
-mental
Just had a look at this one (its bugged me before, but never enough to get me to fix it :) ) changing line 401 in sp-image.cpp to
fullname = g_strconcat (docbase, "\", filename, NULL);
works on windows here, the path its building from the docbase and relative path is missing the \ otherwise. Cant test what this does on linux, and dont want to break it so I'll wrap in an #ifdef win32 to be safe for now, if someone wants to change go ahead.
cheers
John
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
participants (12)
-
unknown＠example.com -
Bob Jamison -
Bryce Harrington -
bulia byak -
Carl Hetherington -
Colin Marquardt -
John Cliff -
Jon Phillips -
Kees Cook -
MenTaLguY -
Peter Moulder -
Ted Gould