() Rodrigo Rodrigues da Silva <[email protected]> () Sun, 21 Feb 2010 21:03:46 -0300
Thanks for your job. I think we can give you write access if nobody objects it. Just do any dirty stuff in a branch =D Cool. OK. > v2 -- add "configure --enable-tracing" Check the src/logging.h. This simple logging framework allows different loglevels for different files. I was thinking about --enable-tracing or --enable-log --loglevel=x (#defines inside the files would override the default to allow fine log tuning -- maybe this fine tuning will not useful at all) Thanks for the pointers. I have a v2 ready to push (to gnuvola) for review -- will do so in the next couple hours. I will explain it in detail in the announcement. > - What are the version numbering schemes for LibreDWG? > - repository tags > - project version > - shared-object library version There's no clear policy yet. The only thing we know is that the first release will be 0.4 (in homage to libdwg which died after 0.3). Nice touch. But there is a rough roadmap somewhere in the wiki. 1.0 means: "stable" + R13-R2007 read support + C (at least) API. 2.0 means stable write support (if we ever get there). I think we are taking too long to release. No worries. I expect in the next couple weeks that we'll be able to do "make all check install installcheck dist distcheck", at which point making a nightly/weekly alpha release will be push-button affair. Maybe we should set some milestones or blocker bugs to release at least a beta. There is many people interested in LibreDWG, but not having a release makes it seem untrustworthy. I would caution against the label "beta" until 0.9 or so. > - Should "configure --enable-tracing" be yes or no by default? No. A library should not output any text by default. OK, thanks for the clarification. > - What is the criteria for declaring a stable API (for bindings)? Good question. But something like: we are able to write a dwg2foo converter (or maybe an importing module for a software like grass - I'm doing that) without having to access the dwg struct directly - things like dwg->tio.object->tio.BLK_HDR->inserts->tio.object->tio.INSERT->.... OK. > - What is the documentation strategy (doxygen, hand-write, ...)? When we joined the GNU project we told the evaluators that we would think about docs before releasing a stable version. Maybe we should start thinking about this. The default documentation format for the GNU project is TeXinfo IIRC. Can doxygen generate TeXinfo files? Yes, texinfo is the standard GNU way. Probably the best approach for reference documentation is to use a texinfo skeleton and include bits extracted from comments in the source code. I don't know too much about doxygen, but surely it can do the extraction. It's a question of comfort and familiarity -- some people like the structure and ease of a particular tool, while others don't like the same tool's limitations and restrictions. Perhaps a regular doxygen user can speak up about it? In any case, i'll be glad to write the texinfo skeleton unless someone else beats me to it. BTW, why all those distcheck installcheck (make dist seems ok)? The more problems we find, earlier, the less problems we (and users) will have, later. These techniques are standardized ways to isolate and address certain classes of problems. They are tools for a clean process, like "gcc -Wall -Wextra" is a tool for clean code. thi
