BIND 10 #1584: auth::Query NSEC3 support: Wildcard answer case

[BIND 10 Development]

#1584: auth::Query NSEC3 support: Wildcard answer case
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  haikuo
  jinmei                             |                Status:  closed
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20120221
                  Component:         |            Resolution:  fixed
  b10-auth                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:  NSEC3  |           Total Hours:  2
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:11 haikuo]:

 > > As we briefly discussed in the daily call, I reviewed the latest
 > > snapshot of the trac1584 branch anyway.  I completed the review, and
 > > actually even addressed my own comments myself.  I didn't want to
 > > steal the branch owned by someone else, but in this particular case
 > > we rely on the completion of this branch for including the major
 > > feature in the next release, and apparently we are running out of our
 > > time.  So I hope it's acceptable for you.
 >
 > sorry for the delay. but this is my first coding ticket and I spent  a
 lot
 > of time to learn how to use git, how to use gtest tools and handling
 with
 > something else about building bind10(I used boost 1_39_0,there are a lot
 of warnings
 > for bind10)

 What Jelte said, but to repeat it myself, you don't have to feel sorry
 about the delay at all.  It's completely understandable that it takes
 time for a new developer to even learn how to build the system, much
 less extend it.  Normally we (or I) don't take over an assigned task
 this way just because it takes a bit longer time.  Please consider
 this a very special case before a release, and especially when the
 major feature is possibly related to the promise to the sponsors.

 > > - There are many violations of the coding guidelines: indentation, too
 > >   long lines, (although not explicitly documented) redundant white
 > >   space characters at end-of-lines or in blank lines, inconsistent
 > >   space style like "if (foo){" (we add space between ')' and '{').
 > >   If you have not done so, please read the guideline carefully.  For
 > >   indentation, maybe you want to adjust your editor configuration (you
 > >   seem to insert 8-space for a "tab")
 >
 > from my side, I want to say I would like to tidy up codes after the
 codes is done
 > and before change it to "review" status. If we have the rules that we
 must tidy codes before
 > commit to repository, I will do it every time.

 Until the code gets ready for review, it's up to you when to fix the
 style issues.  In that sense my comments above may be a bit
 premature.  With noting that I have two followup comments:

 - if you prefer committing intermediate changes (and even pushing them
   to the central repository), it's probably more helpful for the
   reviewer if you also make the committed code as clean as possible
   wrt the style guidelines.  Especially for larger diffs the reviewer
   may want to follow the changes commit-by-commit, in which case it'd
   be a lot easier if the commit doesn't have noisy style glitches.
 - I guess some of the style issues are avoidable more easily by
   adjusting the tool (editor, IDE, etc) than trying to fix them
   afterward by hand.  Indentation width is one such thing.

-- 
Ticket URL: <https://bind10.isc.org/ticket/1584#comment:16>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development