[Top][All Lists]
[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.