Hi,
sorry for the delay, but last weekend my computer broke down while I was
on travel.
So I had to arrange for a replacement first.
Trying to avoid a detailed discussion, let me try to summarize what I
understand up to here
- there is a difference of "higher level" design documentation and
"lower level" design documentation, and the "lower level" part is
currently in Doxygen/Git, the "higher level" part is available in bits
and peaces in several places (Doxygen, texinfo files, Wiki, emails, etc.)
- a decision is needed whether to go for Wiki or Doxygen including the
points
-- only Wiki for everything (meaning, move the lower level part to Wiki,
too)
-- only Doxygen/Git for everything
-- Doxygen/Git for "Lower level", Wiki for "higher level"
We have had quite different opinions so far about where and how the docu
maintenance seems to be better. My impression is that no-one will
convince no-one, no matter how long the discussion will be.
How do you usually take decisions?
Voting?
Kind regards,
Carsten
On 05.09.2014 00:11, John Ralls wrote:
On Sep 4, 2014, at 9:04 AM, Frank H. Ellenberger
<[email protected]> wrote:
Am 04.09.2014 um 16:26 schrieb John Ralls:
Just like Carsten you missed the point that the *design*
documentation doesn't and can't live in the code files and isn't part
of writing a patch.
Just for completeness:
There is a bunch of texi files in src/doc/design.
- But https://github.com/Gnucash/gnucash/commits/master/src/doc/design
shows only sparse updates after 2001.
- And Intro starts with "This whole document is completely outdated.
Don't read this. All function names and every described structure has
changed completely. Only read this if you want to know how gnucash
looked like in 1999. This is completely outdated!"
So, I agree, mediawiki texts are today easier to maintain than texinfo
files. Perhaps we should replace the content of this directory with a
file containing pointers to the respective wiki pages.
But we should add somewhere in the doxygen linked readme files
- A sketch of the modules, their purpose and relations
Better done in the master header file for each module than in separate “read
me” files, but the problem is keeping them current.
- Explanation of namespaces gnc_, qof_, xacc_, …
Better idea: Let’s get rid of all of the extra namespaces and have just one.
BTW:
Am 03.09.2014 um 10:57 schrieb Carsten Rinke:
BTW: I took a look at the Wiki C API page. There is also good stuff
in it. Note that the link to the entity relationship diagram returns
404 and offers me a log in. Is that correct?
John, didn't you update the ERM some time ago? But later it became
inaccessible.
Yeah, I’d put it in the downloads section on Github. They dumped that service
last spring and the diagram went away. I need to learn how to put images
directly in the wiki.
Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
