Looking at the stuff we have slated for Milestone 6 (0.40), there seem to be several different major efforts going on at once.
I see at least:
* AST * gtkmmification * boehm collector * layers * text rewrite
I think we need to tease these apart, and perform triage to push some of these into a subsequent milestone.
-mental
On Sat, 2 Oct 2004, MenTaLguY wrote:
Looking at the stuff we have slated for Milestone 6 (0.40), there seem to be several different major efforts going on at once.
I see at least:
- AST
- gtkmmification
- boehm collector
- layers
- text rewrite
I think we need to tease these apart, and perform triage to push some of these into a subsequent milestone.
I think the text rewrite has not received very much attention. Bulia mentioned you were 25% along with layers? Gtkmmification is making progress but it's a huge task; I'd estimate it's only ~10% done.
With gtkmmification, if we pushed that one off, would we possibly be able to back off of the Gtkmm 2.4 libs and go back to Gtkmm 2.2? If so, that could eliminate that dependency worry.
The garbage collector work sounds like it's fairly far along but it sounds like there are issues still to be worked out (dependency trouble if nothing else). A 0.39.5 release would be useful here, in that it would help shake out and expose some of these problems, and let us get it completed.
I don't know where AST is at, but it doesn't sound like it's gotten very widespread review yet; since that is going to be a pretty intensive change, it's probably not something we want to rush. I'd favor giving that the additional development time of putting off to a future milestone.
Bulia says there's a significant amount bug fixing needed. Releases are effective ways of focusing efforts towards getting bugs fixed. Delaying a release only helps if accompanied by a freeze; given how much development is still needed to achieve goals, an extended delay doesn't seem like the ideal approach for the present - we'll be more likely to keep atop the bugs if we focus on releasing sooner rather than later.
It sounds like we need at least a few weeks to get stuff clean enough for a release, so that'd mean a late-October timeframe. That sounds like a good target because it won't conflict with holidays or other end-of-year activities. Then that'd give us a couple months over the holidays to work on stuff, and could shoot for the next release in January.
So I guess the real question is, aside from whether we've met our goals or not, has enough new stuff been implemented to make a release worth the trouble for users to upgrade? Keep in mind that with the new Gtkmm, boehm, etc. libs, this will be a more challenging release for users to install than we've had before. If we are able to back off of the Gtkmm 2.4 lib back to 2.2, that'd lessen that concern quite a bit.
Bryce
On Sat, 2004-10-02 at 15:25, Bryce Harrington wrote:
I think the text rewrite has not received very much attention.
Unfortunately we'd need to finish it or roll it back for a release, as it's pretty broken in its current state.
Bulia mentioned you were 25% along with layers?
That's about right, yes. I think layers are required (lots of users keep pinging me about it and are expecting it for our next release), but fortunately they are pretty doable. My main limitation is free time.
Gtkmmification is making progress but it's a huge task; I'd estimate it's only ~10% done.
With gtkmmification, if we pushed that one off, would we possibly be able to back off of the Gtkmm 2.4 libs and go back to Gtkmm 2.2? If so, that could eliminate that dependency worry.
I'm not sure -- wasn't part of the move to 2.4 for the sake of the newer version of sigc++ (or vice-versa)?
The garbage collector work sounds like it's fairly far along but it sounds like there are issues still to be worked out (dependency trouble if nothing else). A 0.39.5 release would be useful here, in that it would help shake out and expose some of these problems, and let us get it completed.
I think I've taken the garbage collector stuff as far as I want to for this release cycle, sans some additional debugging. I think the only additional garbage collector use for a while would be from the addition of new code.
I don't know where AST is at, but it doesn't sound like it's gotten very widespread review yet; since that is going to be a pretty intensive change, it's probably not something we want to rush. I'd favor giving that the additional development time of putting off to a future milestone.
Definitely. I'm not going to be ready for AST proper for a while yet.
Actually, I think the current state of the text code underscores the perils of doing out-of-tree development in a separate environment and then trying to merge a whole lot of work into the tree at once. As a result, I've been reconsidering my approach for AST implementation.
The AST code I've written so far was at least valuable as a draft and a learning experience, but at this point I don't think we're going to end up using it.
Rather than a revolutionary change I think we can get there from incremental changes to SPRepr, and for much of AST development without disturbing the existing SPRepr API very much.
I'm wondering if we may also want to re-examine our approach to gtkmmification along similar lines...
Bulia says there's a significant amount bug fixing needed. Releases are effective ways of focusing efforts towards getting bugs fixed. Delaying a release only helps if accompanied by a freeze; given how much development is still needed to achieve goals, an extended delay doesn't seem like the ideal approach for the present - we'll be more likely to keep atop the bugs if we focus on releasing sooner rather than later.
Agreed.
So I guess the real question is, aside from whether we've met our goals or not, has enough new stuff been implemented to make a release worth the trouble for users to upgrade? Keep in mind that with the new Gtkmm, boehm, etc. libs, this will be a more challenging release for users to install than we've had before. If we are able to back off of the Gtkmm 2.4 lib back to 2.2, that'd lessen that concern quite a bit.
I think layers, text-on-path, and bitmap tracing count as "killer features" for our userbase, and should be enough to justify a release, as far as that goes.
-mental
On Sat, 2 Oct 2004, MenTaLguY wrote:
On Sat, 2004-10-02 at 15:25, Bryce Harrington wrote:
I think the text rewrite has not received very much attention.
Unfortunately we'd need to finish it or roll it back for a release, as it's pretty broken in its current state.
Is anyone actively working on it right now? If not, what would need to be done to roll it back?
Bulia mentioned you were 25% along with layers?
That's about right, yes. I think layers are required (lots of users keep pinging me about it and are expecting it for our next release), but fortunately they are pretty doable. My main limitation is free time.
Yeah this would definitely be an important enough feature to warrant a release. And I hear ya on the need for more freetime...
Gtkmmification is making progress but it's a huge task; I'd estimate it's only ~10% done.
With gtkmmification, if we pushed that one off, would we possibly be able to back off of the Gtkmm 2.4 libs and go back to Gtkmm 2.2? If so, that could eliminate that dependency worry.
I'm not sure -- wasn't part of the move to 2.4 for the sake of the newer version of sigc++ (or vice-versa)?
I *think* it's vice versa; if we were able to use Gtkmm 2.2, then we could possibly also move back to a previous sigc++. Maybe the new sigc++ is being used elsewhere though.
The garbage collector work sounds like it's fairly far along but it sounds like there are issues still to be worked out (dependency trouble if nothing else). A 0.39.5 release would be useful here, in that it would help shake out and expose some of these problems, and let us get it completed.
I think I've taken the garbage collector stuff as far as I want to for this release cycle, sans some additional debugging. I think the only additional garbage collector use for a while would be from the addition of new code.
Okay, good. This might not be very visible to users, but if we can get it out in production it'll solidify that achievement.
I don't know where AST is at, but it doesn't sound like it's gotten very widespread review yet; since that is going to be a pretty intensive change, it's probably not something we want to rush. I'd favor giving that the additional development time of putting off to a future milestone.
Definitely. I'm not going to be ready for AST proper for a while yet.
Actually, I think the current state of the text code underscores the perils of doing out-of-tree development in a separate environment and then trying to merge a whole lot of work into the tree at once. As a result, I've been reconsidering my approach for AST implementation.
The AST code I've written so far was at least valuable as a draft and a learning experience, but at this point I don't think we're going to end up using it.
Okay, then it sounds like this should be moved out of the goals for the 0.40 release.
Rather than a revolutionary change I think we can get there from incremental changes to SPRepr, and for much of AST development without disturbing the existing SPRepr API very much.
I'm wondering if we may also want to re-examine our approach to gtkmmification along similar lines...
I've been thinking about that myself, but I think we're okay. I've been keeping a firm eye on the current codebase while working on the separate system, and gradually moving it towards compatibility. For instance, last weekend I implemented a stub for SPSelection to help, since that's a common tie-in point.
Doing the out of tree development has actually helped a lot in identifying where these sorts of clean interfaces are. Most of the items are fairly modular (e.g. a single class for a specific dialog or widget), so they're easy to focus on in exclusion of everything else.
I'm definitely seeing the benefits of Gtkmm - thousand line files are being replaced by hundred line files. This will make maintenance much easier. However, I'm also seeing some quirks in getting things to look 100% like the Gtk+ code, that may be difficult to resolve.
The main problem I've run into is not technical or architectural but rather just having enough time to get the work done. Thus, the benefit to bringing it into the codebase would be (in theory) that more people would have motivation to work on it, and portions could be brought online as they become ready. However, the assumption that more people would get involved in that case is far from certain; indeed it sounds like it'd risk distracting folks from more pressing features and bug fixes. There is also a risk in that it could get disorderly quickly as people diverge into different styles and approaches - I really want to make all the dialog code look and work consistently across the board, so it is easy for anyone to maintain.
So I guess the real question is, aside from whether we've met our goals or not, has enough new stuff been implemented to make a release worth the trouble for users to upgrade? Keep in mind that with the new Gtkmm, boehm, etc. libs, this will be a more challenging release for users to install than we've had before. If we are able to back off of the Gtkmm 2.4 lib back to 2.2, that'd lessen that concern quite a bit.
I think layers, text-on-path, and bitmap tracing count as "killer features" for our userbase, and should be enough to justify a release, as far as that goes.
Agreed. What remains for getting text-on-path to be usable?
Should I go through and revise the roadmap to focus it better? I think perhaps we should ensure every task we leave on there have an owner associated with it, and that nobody have more tasks than they feel they can achieve within a few weeks.
Bryce
On Sat, 2 Oct 2004 15:30:01 -0700 (PDT), Bryce Harrington <bryce@...260...> wrote:
On Sat, 2 Oct 2004, MenTaLguY wrote:
On Sat, 2004-10-02 at 15:25, Bryce Harrington wrote:
I think the text rewrite has not received very much attention.
Unfortunately we'd need to finish it or roll it back for a release, as it's pretty broken in its current state.
Is anyone actively working on it right now? If not, what would need to be done to roll it back?
It's certainly not that bad as to need rolling back. And in any case rolling it back now would be a HUGE amount of work.
Agreed. What remains for getting text-on-path to be usable?
Fixing the text bugs and adding a remove-from-path command, at least. But I also want to make commands for flowtext as well.
On Sat, 2 Oct 2004, bulia byak wrote:
On Sat, 2 Oct 2004 15:30:01 -0700 (PDT), Bryce Harrington <bryce@...260...> wrote:
On Sat, 2 Oct 2004, MenTaLguY wrote:
On Sat, 2004-10-02 at 15:25, Bryce Harrington wrote:
I think the text rewrite has not received very much attention.
Unfortunately we'd need to finish it or roll it back for a release, as it's pretty broken in its current state.
Is anyone actively working on it right now? If not, what would need to be done to roll it back?
It's certainly not that bad as to need rolling back. And in any case rolling it back now would be a HUGE amount of work.
Okay, so then that means we'd need to get it finished? What's currently broken about it? (It was working ok last I used it but that was a week ago).
Agreed. What remains for getting text-on-path to be usable?
Fixing the text bugs and adding a remove-from-path command, at least. But I also want to make commands for flowtext as well.
Okay, cool, that doesn't sound too bad; can you add these tasks to the roadmap so we can track them?
Bryce
On Sat, Oct 02, 2004 at 05:39:09PM -0400, MenTaLguY wrote:
I think layers, text-on-path, and bitmap tracing count as "killer features" for our userbase, and should be enough to justify a release, as far as that goes.
I think it would be very valuable to make a tutorial on doing tracing. I tried it earlier today with an image, and had absolutely no luck at all. :P
participants (4)
-
Bryce Harrington -
bulia byak -
Kees Cook -
MenTaLguY