Re: [Cgdb-devel] CGDB Development Methods (was Re: CGDB 1.0 Proposal)

[Mike M. <mmu...@cs...>]

On Thu, 14 Aug 2003, Bob Rossi wrote:

:   1. testing should be a key component in CGDB/TGDB.
:      TGDB is poorly tested. It does have a testsuite, but it basically
:      is a sanity checking device. For *every* new feature we add to
:      either tool, we need to add a testsuite entry. I don't know how
:      we are going to do this, but it will help with regressions.

I agree, but I think this isn't really an issue right now.  It is 
definitely something to keep in mind during development.

:   2. Documentation is also very important. CGDB/TGDB need to 
:      support 2 different types of documentation. 
:         a) Internal, describing algorithms, design decisions, interfaces ...
:            For the internal we could use doxygen ( of course ). If
:            anyone recommends anything else, please bring it up.
:         b) External, user manuals, HOWTO's, FAQ's, ...
:            For external, we should probably use the GNU documentation
:            standard. 
:            http://gnu.ghks.de/software/texinfo/texinfo.html
:            I would defiantly be up to picking a different standard if
:            anyone can suggest it.

Ok.  I am not sure if doxygen is overkill or not, but I'm not 
opposed to using it.  We could also just comment header files well, 
and write a text file or two about the design (in the CVS 
repository).

:   4. Coding standards. 
:      For this we can go two different routes. Pick a coding standard or
:      don't. I prefer to have one. I don't really care which one it is,
:      I would like to hear someone else's opinion on this topic.
:
:      I only know of 2 coding standards. The Linux kernel, and GNU's.

We currently have differing styles of code in CGDB, and I don't see 
it as a problem.  As long as it's readable.

:   5. Patch approval mailing list.
:      I think all patches should be mailed in, and one of us can apply
:      the patch. This way, we can make sure that the ChangeLog is done
:      correct, the coding standard is correct, and none of us are
:      getting lazy.
:
:
:I understand that many of these ideas seem like overhead, but in the
:end, there will be a good product thats well rounded, instead of just
:another free software project.
:
:So, if you think that some of these are too much for a small project,
:and that its overboard, let me know.

My reaction to a lot of these suggestions is that they are overkill.  
However, if you don't mind putting the extra work in to make them 
happen, they don't hurt to have.

This is a really small project, and I think it will always be (even 
if it becomes popular).  Also, a lot of these are bridges we can 
cross in the future if it is necessary.

Mike