If a story has some defects logged against its implementation, does this mean it's not done? What does your [DoD] Definition of Done say about this? If a defect is severe or blocking other teams or other testing, then I would agree that the story really isn't done. In that case the team should probably postpone other feature work and focus on fixing the defects. However, if the major business value is still delivered and the main functionality is not adversely affected by a defect, then I would support the story being called Done (all other done criteria being met of course).

The product owner of course will want perfection... this is to be expected. There is a line however, somewhere, that separates a story from done to not done. However "no bugs" is probably not it... minor defects that do not block the major functionality, other teams, or other testing / features should be logged as defect stories on the product backlog, prioritized highest (even above other high-demand features) unless they are so minor that the story could ship to production even with the existing defect uncorrected.

Perfection is not in the Agile Manifesto the last time I checked... however the defect vs. done issue continues to remain a gray area.

The recommendation is this: classify defects based on a priority.

Pri-0 - blocking bug, drop everything and fix NOW.
Pri-1 - non-blocking but serious bug, broken functionality. Fix ASAP.
Pri-2 - non-blocking with work-around. Fix when possible.
Pri-3 - non-blocking minor issue, does not block functional testing. Fix if possible.

I support the in-sprint fixing of Pri-0 and Pri-1 defects, but any else should be deferred to another sprint. DoD should include this as a working agreement, and any reasonable [practical] product owner should approve.

So, what's in your Definition of Done?