[Top][All Lists]

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

Re: [libredwg] contributions v1.2 available

From: Thien-Thi Nguyen
Subject: Re: [libredwg] contributions v1.2 available
Date: Mon, 22 Feb 2010 09:47:15 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux)

() Rodrigo Rodrigues da Silva <address@hidden>
() 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 


   >  - 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.


reply via email to

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