I've finished twiddling DNS for inkscape.org to point at our SF webspace, I think, though it'll take a while for things to settle down and propagate.
I've also added email aliases @inkscape.org for each of the currently added developers (y'all let me know if you object).
Also, I'd like to congratulate bryce on his perennial state of being-on-the-ball with this mailing list thing and getting more folks added, so I didn't have to. ^_^
Next up is probably getting the goodies in CVS. I'm strongly in favor of labeling the Sodipodi fork "hydra", but I'm not sure what to call the piece of code I'm working on. I'd originally been thinking "hercules", but maybe just "inkscape" is fine?
Also, is anyone any good with Doxygen? I'd like to start looking into that for both codebases...
-mental
On Tue, 28 Oct 2003, MenTaLguY wrote:
I've finished twiddling DNS for inkscape.org to point at our SF webspace, I think, though it'll take a while for things to settle down and propagate.
I've also added email aliases @inkscape.org for each of the currently added developers (y'all let me know if you object).
Cool, thanks!
Next up is probably getting the goodies in CVS. I'm strongly in favor of labeling the Sodipodi fork "hydra", but I'm not sure what to call the piece of code I'm working on. I'd originally been thinking "hercules", but maybe just "inkscape" is fine?
Since we cannot distribute a forked Sodipodi under the same name, I think we're going to need to rebrand it. It's logical to rebrand it as 'inkscape' since that will be the name of the project.
The next question we face is how to get from Point A to Point B. Knowing this will help determine what to call your codebase.
I've been through this process a few times before. There are several different approaches for doing this, most of which don't work very well.
At WorldForge we had a client called UClient that was written early in the project and that had been its first deliverable product. It was nifty that it worked, and it even had sound, animation, weather effects, etc. implemented, but by all opinions the codebase was sheer terror. Nearly all the developers who looked at it decided it would be "more time efficient" to start new clients from scratch. We gave them the go-ahead and all the support we could muster, but after 1-2 years they were nowhere close to replacing UClient. Starting over from scratch doesn't work well; it's harder than you think and more likely to fail spectacularly.
Having gone through all that, we chose a new approach. We took the existing UClient codebase and one of the prototypical but aborted clients that had been developed, and started slowly refactoring UClient to start to look like the model. Of course, UClient didn't end up exactly like the model, since people figured out new ideas along the way, but this approach allowed us to achieve the end result while always having a distributable, working copy of the code, that always did at least what the previous release did (more or less).
I can easily see us slip into the first approach with Inkscape, but feel strongly that the second approach, while less glamorous, would be much more likely to succeed.
This was why I was asking you about what you thought of recompiling Sodipodi into C++. That would be the logical first step; switch the compiler from gcc to g++ and then work on fixing all the compiler errors. Get it to compile and cut a release. Then pick some subsystem that's in dire need of objectification, take a look at your prototype, and figure out how to change the codebase to make it resemble your codebase, and do it in a way that doesn't require you to change very many files. Shoot for ambitious but incremental steps that refactor it into the direction you want it.
Also, is anyone any good with Doxygen? I'd like to start looking into that for both codebases...
I've used it before. The basic usage is extremely straightforward. For each function or class, put a comment ahead of it in the following style:
/** A Test class. * More details about this class. */
class Test { public: /** An example member function. * More details about this function. */ void example(); };
Note the double asterisks; that's what clues Docygen in.
The documents are created with a commandline like,
$ doxytag -t example.tag example/html
This turns into something like this:
http://www.stack.nl/~dimitri/doxygen/examples/example/html/class_test.html
There's several other commenting styles that work with doxygen. I recommend the above style for two reasons: It is identical to JavaDoc, and the /* */ style comments will work find in any C compiler.
There are good lengthier examples you should next look at, on http://www.stack.nl/~dimitri/doxygen/docblocks.html This includes demonstrating how to do references to other doc sections, parameters, and alternate commenting styles.
Bryce
Bryce Harrington wrote:
This was why I was asking you about what you thought of recompiling Sodipodi into C++. That would be the logical first step; switch the compiler from gcc to g++ and then work on fixing all the compiler errors. Get it to compile and cut a release.
Bloody brilliant.
njh
On Wed, 2003-10-29 at 03:43, Bryce Harrington wrote:
Since we cannot distribute a forked Sodipodi under the same name, I think we're going to need to rebrand it. It's logical to rebrand it as 'inkscape' since that will be the name of the project.
The next question we face is how to get from Point A to Point B. Knowing this will help determine what to call your codebase.
I can easily see us slip into [rewriting from scratch] with Inkscape, but feel strongly that [reworking the existing codebase], while less glamorous, would be much more likely to succeed.
That's been my experience as well, although it can really suck for prototyping -- especially with things like some of the radical UI changes that I have in mind.
Your advice is well-taken, anyway.
So... here's what I'm thinking at this point...
* Sodipodi fork becomes the 'inkscape' module
* My sketch becomes ... 'experimental', maybe?
* I think our first tasks in inkscape should be:
1. Getting it building with a C++ compiler
2. Fixing the remaining XML compliance bugs
3. Removing the hacked-in Qt stuff
4. Cut a release
* While I'm wrangling patches on the inkscape side, I will keep attacking the prototyping/experimental side of things (along with anyone else who's interested). Eventually, depending on how they converge, we might start seeing code being merged both ways.
* At that point we may want to think about cutting an 'inkscape2' module based more on one side or the other, depending on how each have matured. It'll be an opportunity to lose any vestiges of the old Sodipodi directory structure, which I'm not particularly fond of, anyway.
How does that sound?
-mental
On Wed, 29 Oct 2003, MenTaLguY wrote:
On Wed, 2003-10-29 at 03:43, Bryce Harrington wrote:
Since we cannot distribute a forked Sodipodi under the same name, I think we're going to need to rebrand it. It's logical to rebrand it as 'inkscape' since that will be the name of the project.
The next question we face is how to get from Point A to Point B. Knowing this will help determine what to call your codebase.
I can easily see us slip into [rewriting from scratch] with Inkscape, but feel strongly that [reworking the existing codebase], while less glamorous, would be much more likely to succeed.
That's been my experience as well, although it can really suck for prototyping -- especially with things like some of the radical UI changes that I have in mind.
Your advice is well-taken, anyway.
So... here's what I'm thinking at this point...
Sodipodi fork becomes the 'inkscape' module
My sketch becomes ... 'experimental', maybe?
I think our first tasks in inkscape should be:
- Getting it building with a C++ compiler
To bulk rename all the .c files to .cpp:
find . -name "*.c" | xargs rename ".c" ".cpp"
Another extremely handy command for doing bulk changes is 'replace'. E.g.,
replace 'Sodipodi' 'Inkscape' -- *.c *.h
Fixing the remaining XML compliance bugs
Removing the hacked-in Qt stuff
Cut a release
There's also half a dozen patches still to be applied; most are pretty old but if they're useful we might as well snag them.
- While I'm wrangling patches on the inkscape side, I will keep
attacking the prototyping/experimental side of things (along with anyone else who's interested). Eventually, depending on how they converge, we might start seeing code being merged both ways.
- At that point we may want to think about cutting an 'inkscape2'
module based more on one side or the other, depending on how each have matured. It'll be an opportunity to lose any vestiges of the old Sodipodi directory structure, which I'm not particularly fond of, anyway.
How does that sound?
This sounds like a good plan to me. Can you put this in doc/PLAN in the sodipodi (inkscape) module, and we'll use it as the basis for our development roadmap.
Bryce
Okay, I've copied this plan into Wiki and tweaked it into a milestone/task format:
http://www.inkscape.org/cgi-bin/wiki.pl?DevelopmentRoadmap
The idea here is that as we each have ideas of how things should develop, we add them to this plan, into the appropriate milestone.
This is a working document, and based on past project work, this will be the most important document that we as developers have. This document helps us coordinate who does what and gives us a way to force decisions that need to be made, to be made and nailed down.
Some techniques I've picked up for best using these plans...
* Make the plan your friend. Don't let it feel like shackles or constraints. If the plan isn't right, change it so that it is.
* Indicate your name for tasks you want to own. If you need/want someone to do a task for you, put their name in brackets. If someone puts your name for a task you're unsure about doing, email them and work it out.
* If a given task seems too intractable, break it down into more specific sub-tasks. The ideal task-unit is something that'll require a single "work session" to achieve.
* All the items in the current/next milestone should be known as to how to implement them. If you need to "figure out how to..." then list that as the task, and move the "implement" into the future.
* Strive to keep the quantity of work per milestone modest. There is nothing important about the milestone numbers; we can have as many as we like. What's important is that we hit milestones with frequency; this gives us a feeling of accomplishment and helps keep up our motivation. If the next milestone is always within sight it helps us avoid feeling intimidated by the sheer amount of work to be done. Focus on incremental achievements.
* Skip setting dates. We either end up burning ourselves out to meet the dates or get discouraged at missing them. We're not in a hurry. We'll get things out when we're ready for them to get out, not before. Hopefully we should meet milestones every week or two or three. If one takes three months for some reason (like having lives), well, three months it is.
* Tying code releases to milestones is a good thing. You finish a milestone, make a code release, and can go have beers. :-)
* Try to avoid adding 'new' tasks to the current milestone; this increases the amount of work needed to achieve the milestone. If at all possible, add them to the next milestone (or later). Or insert another (small) milestone to follow after the current one.
* Try to avoid bumping tasks to the next milestone just because the task is annoying or unexciting. Use the pending completion of the milestone as motivation to get the grunge work done too. You'll feel prouder of the achievement.
* Follow the plan and push towards each milestone. It takes dedication to remain focused. There's tons of interesting things that are fun to get distracted by, but having a plan like this gives something to tie your attention to.
Bryce
On Wed, 29 Oct 2003, MenTaLguY wrote:
On Wed, 2003-10-29 at 03:43, Bryce Harrington wrote:
Since we cannot distribute a forked Sodipodi under the same name, I think we're going to need to rebrand it. It's logical to rebrand it as 'inkscape' since that will be the name of the project.
The next question we face is how to get from Point A to Point B. Knowing this will help determine what to call your codebase.
I can easily see us slip into [rewriting from scratch] with Inkscape, but feel strongly that [reworking the existing codebase], while less glamorous, would be much more likely to succeed.
That's been my experience as well, although it can really suck for prototyping -- especially with things like some of the radical UI changes that I have in mind.
Your advice is well-taken, anyway.
So... here's what I'm thinking at this point...
Sodipodi fork becomes the 'inkscape' module
My sketch becomes ... 'experimental', maybe?
I think our first tasks in inkscape should be:
Getting it building with a C++ compiler
Fixing the remaining XML compliance bugs
Removing the hacked-in Qt stuff
Cut a release
While I'm wrangling patches on the inkscape side, I will keep
attacking the prototyping/experimental side of things (along with anyone else who's interested). Eventually, depending on how they converge, we might start seeing code being merged both ways.
- At that point we may want to think about cutting an 'inkscape2'
module based more on one side or the other, depending on how each have matured. It'll be an opportunity to lose any vestiges of the old Sodipodi directory structure, which I'm not particularly fond of, anyway.
How does that sound?
-mental
participants (3)
-
Bryce Harrington -
MenTaLguY -
Nathan Hurst