BIND 10 #904: gen-wiredata.py need more documentation.

BIND 10 Development do-not-reply at isc.org
Tue Aug 9 06:49:36 UTC 2011


#904: gen-wiredata.py need more documentation.
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110816
                  Component:         |            Resolution:
  documentation                      |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  0.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:10 jinmei]:
 > > Otherwise, I'm not sure if referencing the default values in code is
 OK. Do we generate something from it? If so, wouldn't they be missing?
 >
 > I don't understand the comment...do you mean you don't like to
 > hardcode the default values in the source code like this?
 >
 > {{{
 > class A(RR):
 > [...]
 >     RDLEN_DEFAULT = 4           # fixed by default
 >     address = '192.0.2.1'
 > }}}
 >
 > If so, I don't have a very strong opinion, and although I normally
 > don't like any hardcoding, I think this case is acceptable (or perhaps
 > even useful), partly because it's just a test utility so conciseness
 > would be preferred over full generality/flexibility, and partly
 > because the hardcoded values will be shown via pydoc.

 I didn't know about pydoc and I didn't know it is able to extract the
 values from the source code ‒ that was what I was worried about. The
 documentation didn't contain the values, only talked about looking into
 the code. If it does extract them, it is OK.

 I fully agree with the hardcoding itself.

 Anyway, the branch didn't compile for me because of missing boost:: in
 front of lexical_cast in srv_impl.cc. I believe it is already fixed in
 master (I saw something like that in jabber), but if not, would you add it
 there, please?

 I don't see any other problem, so please merge.

 Thank you

-- 
Ticket URL: <http://bind10.isc.org/ticket/904#comment:12>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list