gnu3dkit-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu3dkit-discuss] Development Plan


From: Brent Gulanowski
Subject: Re: [Gnu3dkit-discuss] Development Plan
Date: Tue, 29 Oct 2002 20:21:04 -0500

(Hopefully my vicious cutting of my original post doesn't mar the meaning of Phil's words.)

On Tuesday, October 29, 2002, at 06:25  PM, Philippe C.D. Robert wrote:

1. Produce a major feature list

Yes, this would also help newcomers to understand what it is all about. I suggest we create a white paper for this purpose which eplains the 3DKit a little.

A white paper is good. As I said before, I'd be happy to write such a thing, or edit it, or whatever -- given a list of subject matter and general guidelines to start off. Let's just get an outline written and posted to this list and the website. A page or two to start would be plenty -- just a direction or a mission statement.

2. Identify the functional sub-systems

I am working on this. I also hope to make things as easy as possible by the layout of the PB project (see the GeometryKit as an example).

Yes, I've noticed that -- I approve!

3. Specify the code standards

I think we should just use the GNU standards as it is a GNU project. This requires reindentation of the GeometryKit as well, I assume.... The rules should be available on the GNU pages. We should also add the link to the 3DKit page.

Can you please reply with a link to a relevant GNU page? Is this GNUstep, or GNU in general which sets these standards?

4. Dependencies

Hmmm ... this should go into the white paper mentioned above as well, no? But to give a final answer the design has first to be finalised.

I agree this part cannot all be done in the early stages, but as you mentioned we don't want to use glu; that is an example of the kind of thing I mean. Crystal Space depends on libpng and zlib (and something else). We obviously depend on the Objective-C language and Foundation framework. I personally have no preferences whether the dev plan is all in one document or in separate documents. I would say separate initially -- we can combine them all later. I recommend the white paper server as a roadmap of the whole plan which will serve as an introduction -- a summary of the other sections.

5. Construction Plan
The last main thing might be to map out the order that the first set of features should be addressed...

I try to write a first version of such a white paper covering many of these issues within the next few days. I will then post it via CVS and hope that others will jump in and provide useful feedback/additions/corrections.

CVS is a great way to ensure the documentation gets around. Did you decide on what text format the design documentation was going to be in? I guess all Unix-friendly formats will be handled properly (but I've had problems with Word documents -- not that you'd use them, but I'm just wondering).


I read your emails, it was not the wrong list..:-) It's just that I try to sort out my thoughts and then I will come up with a preliminary idea which I hope will cause some heavy discussions. From there we can plan the further development process.

I also understand that it is hard to jump into the project w/o having any real code. I really try hard to change this ASAP. I am sorry that it takes me so long...

Well, this is why I like the top-down approach. I mean, doing it committee style can suck bad, but, Phil, if you just write up an outline, and expand on what you already know, we can start to fill in the details. An initial outline would tell people what topics are under consideration and, importantly for sorting through later, establish the right terminology. Even if you don't have time to expand on anything now, you could put little discussion notes like, "Part A, section 1: [bleah] -- open for discussion", "Part A, section 2: [something] -- plan in progress, published ASAP", ... , "Part E, section 5: [whatever] -- not sure, but we _won't_ be doing such and such...".

My only problem with contributing directly right now is I have no idea whether anything I do will be compatible, contrary, or what. I'm researching and doing my own parallel work, but I don't mind if I get assignments or suggestions or even a list of "To Do" items as a guide for where to put what time/energy I have. I guess that's my major motivation for this -- writing up a task list so that people can contribute immediately, and you, Phil, don't have to feel pressure to meet imaginary deadlines. It's perfectly OK for you to just play manager sometimes.

What I do hope to do, when there is enough design-oriented material on the list, is to then assemble something, perhaps even a system to pull information out of the list archives dynamically and assemble it into a rough draft, which could be edited for clarity and cohesion. If we could identify a skeleton for the development plan documentation, like with section names or, even better, a numbering system, this data mining process would be dramatically simplified. But it's just an > idea.

This would be really nice. Maybe you want to write a list of topics in a first move which can then be discussed here so that material for the draft can be generated for all these subjects?

I'm happy to. I expect such a list may betray my inexperience, but it would satisfy my need to summarize 8^).

You know, you shouldn't be afraid to cut and paste from other GPL/LGPL documents when and if it is suitable/permissible, at least as a first draft. I assume that the same rules apply to documentation as to code??

--
Brent Gulanowski                                address@hidden

http://inkubator.idevgames.com/
Working together to make great software.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]