<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-GB link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Python 2.7 has @unittest.skip and @unittest.skipUnless
decorators.  Is this what you want?  You could write the failing unit
test, and then mark it as skipped until the bug is fixed.  My only concern
would be the Python 2.7 dependency – we’re using 2.6 still
ourselves, so I’d ask that you wrote some backwards-compat code for that.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>You could even have skipUnless(datetime.now() - datetime(2011,3,1)
> timedelta(0)), so if someone promised you that they were going to fix it today,
you could hold them to it!  (I don’t recommend that, by the way, but
I thought that it was fun ;-)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Ewan.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>
openstack-bounces+ewan.mellor=citrix.com@lists.launchpad.net
[mailto:openstack-bounces+ewan.mellor=citrix.com@lists.launchpad.net] <b>On
Behalf Of </b>Justin Santa Barbara<br>
<b>Sent:</b> 28 February 2011 10:56<br>
<b>To:</b> openstack@lists.launchpad.net<br>
<b>Subject:</b> [Openstack] How to deal with 'tangential' bugs?<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p> </o:p></p>

<div>

<p class=MsoNormal>Jay and I have been having an interesting discussion about
how to deal with bugs that mean that unit tests _should_ fail.  So, if I
find a bug, I should write a failing unit test first, and fix it (in one
merge).  However, if I can't fix it, I can't get a failing unit test
merged into the trunk (because it fails).  It may be that I can't get what
I'm actually working on merged with good unit tests until this 'tangential' bug
is fixed.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal>(The discussion is here: <a
href="https://code.launchpad.net/~justin-fathomdb/nova/bug724623/+merge/51227">https://code.launchpad.net/~justin-fathomdb/nova/bug724623/+merge/51227</a>)<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal>I suggested that we introduce a "known_bugs"
collection.  It would have a set of values to indicate bugs that are known
but not yet fixed.  Ideally these would be linked to bug reports (we could
mandate this).  When a developer wants to write a test or behavior to work
around a particular bug, they can control it based on testing this collection
("if 'bug12345' in known_bugs:")  When someone is ready to fix
the bug, they remove the bug from the collection, the unit tests then fail,
they fix the code and commit with the known_bugs item removed.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal>This would let people that find bugs but can't or don't want
to fix them still contribute unit tests.  This could be a QA person that
can write tests but not necessarily code the fix.  This could be a
developer who simply isn't familiar with the particular system.  Or it
could be where the fix needs to go through the OpenStack discussion process.
 Or it could simply be a train-of-thought / 'flow' issue.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal>Take, for example, my favorite OpenStack API authentication
issue.  To get a passing unit test with OpenStack authentication, my best
bet is to set all three values (username, api_key, api_secret) to the same
value.  This, however, is a truly terrible test case.  Having
"known_bugs" marks my unit test as being suboptimal; it lets me
provide better code in the same place (controlled by the known_bugs setting);
and when the bug fixer comes to fix it they easily get a failing unit test that
they can use for TDD.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal>Jay (correctly) points out that this is complicated; can
cause problems down the line when the bug is fixed in an unexpected way; that
known_bugs should always be empty; and that the right thing to do is to fix the
bug or get it fixed.  I agree, but I don't think that getting the bug
fixed before proceeding is realistic in a project with as many stakeholders as
OpenStack has.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal>Can we resolve the dilemma?  How should we proceed when
we find a bug but we're working on something different?<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal>Justin<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal> <o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>