<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'>I think, having read through everything that Vish said, and
everything you guys have said, the only problem we have here is one of communication.<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'>I’m sure that Trey didn’t _<i>want</i>_ to skip
these tests, and I know that Vish accepted the patch knowing the downsides. 
He had to trade off the time taken to fix everything perfectly, versus the further
remerging / rebasing that would have been necessary if the patch got stalled for
any longer.  I agree with Soren that this was not a desirable thing, and I
think everyone else would too, but Vish made that decision in full sight of the
facts, and I’m happy to support him in that, even though it’s my
team that’s taken the hit in this case.<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'>So what we need to do is to fix the communication.  I don’t
want Citrix to “own” the ESX support (or anyone else to own any
other subsystem) because it would be too easy for people to say “that
doesn’t matter – Citrix will fix it”.  That way, we’ll
only ever find out too late about stuff that breaks.  However, I _<i>am</i>_
happy for us to talk to people when it comes to complicated cross-cutting
features.  We very seriously want multi-NIC support on ESX, so we’d
have been very happy to help, if only we found out a bit earlier.  There
will be plenty of things in the future that we want to work on multiple
hypervisors, and we’re willing to invest the developer time to make that
the case.<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'>I don’t know if either of them will like this idea, but
maybe we could make it Vish’s problem or Theirry’s problem to think
about whether the right communication is happening.  By that I mean, when
the blueprint is reviewed / accepted for a release, either the PTL or the
release manager could take the time to think about whether anyone else should
be on the blueprint for notification or involvement.<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'> Thoughts?<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>Trey Morris<br>
<b>Sent:</b> 03 August 2011 09:32<br>
<b>To:</b> Soren Hansen<br>
<b>Cc:</b> openstack@lists.launchpad.net<br>
<b>Subject:</b> Re: [Openstack] Nova D3 Milestone and the skipped tests<o:p></o:p></span></p>

</div>

</div>

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

<p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p>

<div>

<p class=MsoNormal>On Tue, Aug 2, 2011 at 6:40 AM, Soren Hansen <<a
href="mailto:soren@linux2go.dk" target="_blank">soren@linux2go.dk</a>>
wrote:<o:p></o:p></p>

<p class=MsoNormal>2011/7/27 Trey Morris <<a
href="mailto:trey.morris@rackspace.com" target="_blank">trey.morris@rackspace.com</a>>:<o:p></o:p></p>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'>> I'm fairly certain that in
this particular case, without support from the<br>
> hypervisor and api lieutenants, and a testing guru or two, I would still
be<br>
> trying to fit all the pieces together.<o:p></o:p></p>

</div>

<p class=MsoNormal>On any reasonably large software project, sometimes making
changes to<br>
the code isn't just about making changes to the code. Sometimes it<br>
involves pestering people to help you out if there are things you<br>
can't work out yourself.<o:p></o:p></p>

<div>

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

</div>

<div>

<p class=MsoNormal>But at what cost? How long should we delay progress in one
area, in this case networking, to make sure <i>everything</i> works even
if it doesn't necessarily need to right now as we're no where near a release?
We need to be able to develop in independent areas without having to worry
about the entire codebase.<o:p></o:p></p>

</div>

<div>

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

</div>

<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-right:0cm'>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'><br>
> Merging with broken pieces in this case was necessary.<o:p></o:p></p>

</div>

<p class=MsoNormal>I absolutely, nonequivocally disagree.<o:p></o:p></p>

</blockquote>

<div>

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

</div>

<div>

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

</div>

<div>

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

</div>

<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-right:0cm'>

<div>

<p class=MsoNormal><br>
> Some more thoughts to fuel discussion...<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'>> 2) shims:<br>
> Sandy would say we could use shims here, wait for the other parts to be<br>
> merged, then remove the shims in such a way that nothing is ever broken. I<br>
> think a procedure like this works in the vast majority of cases, and makes<br>
> for smaller merges with trunk. Certainly we don't want shims in place any<br>
> more than we want skipped tests, so how do we get the pieces updated? Who
is<br>
> going to do the updating?<o:p></o:p></p>

</div>

<p class=MsoNormal>Maybe I'm not completely clear on what you mean by
"shims". Do you<br>
mean wrappers for backwards compatibility?<o:p></o:p></p>

</blockquote>

<div>

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

</div>

<div>

<p class=MsoNormal>Basically yeah, but they don't always need to be wrappers.
Another example would be structure added to a model that presents a changed
underlying db table in the same manner as it was presented before the change,
allowing someone to change a db table without being required to update all of
the code that refers to it at the same time. Bits and pieces could be merged
over time and once they are all merged, then the model structure (shim) is
removed.<o:p></o:p></p>

</div>

<div>

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

</div>

<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-right:0cm'>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'><br>
> 3) skipped tests:<br>
> Very visible. Everyone sees them. But very bad habits can be formed around<br>
> using them.<o:p></o:p></p>

</div>

<p class=MsoNormal>a) Not everyone sees them. I rarely sit around and stare at
the test<br>
suite run. If it fails, yes, I go back and look, but if it all passes,<br>
I don't care much about its output. This is, in fact, how I discovered<br>
this: I made a change to the test suite that I *knew* should make it<br>
fail, but it didn't. *Then* I went and looked and saw all of these. <o:p></o:p></p>

</blockquote>

<div>

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

</div>

<div>

<p class=MsoNormal>Successful test run output:<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=MsoNormal>Ran 1049 tests in 206.878s<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=MsoNormal>OK (SKIP=44)"<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=MsoNormal>Even if it all passes, you see the "SKIP=44" at
the end. Either way, at this point the cat is over the wall so let's discuss
remedy instead of the original reasons for taking this action. How should we
handle situations like this in the future?<o:p></o:p></p>

</div>

<div>

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

</div>

<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-right:0cm'>

<p class=MsoNormal><br>
b) I never for a second assumed that a skipped test meant that it was<br>
my problem to fix it. If someone disables a test, I assume they're<br>
working around the clock(!) to fix the problem.<o:p></o:p></p>

</blockquote>

<div>

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

</div>

<div>

<p class=MsoNormal>If the tests are skipped in an area of the code that you are
responsible for, find out why and remedy the problem. This was the original
purpose for lieutenants, there was no one to communicate these problems to at
the time; no one responsible for the work.<o:p></o:p></p>

</div>

<div>

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

</div>

<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;
margin-left:4.8pt;margin-right:0cm'>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'><br>
> 4) dropped support:<br>
> We've decided to add feature X to Nova. Developer A determines adding X<br>
> requires nontrivial changes to hypervisors Q W E and R (and yes, soren,<br>
> their tests). Developer A, being familiar with Q, updates Q (and tests) to<br>
> work with Nova+X; however, W E and R are still broken. If requests for<br>
> option 1 above fail and cooperation doesn't seem to happen and things drag<br>
> out, we should remove the shims, merge, and drop support for W E and R
from<br>
> Nova until updated code (with tests) for W E and R is proposed for merging<br>
> into trunk.<o:p></o:p></p>

</div>

<p class=MsoNormal>I'm perfectly fine with this. If no-one wants to maintain a
particular<br>
hypervisor, it gets dropped. This is perfectly reasonable.<o:p></o:p></p>

</blockquote>

<div>

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

</div>

<div>

<p class=MsoNormal>So is this our new route? When code needs to hit trunk and
would break an API or a hypervisor, network plugin, etc, we immediately drop
support? Should we wait a milestone first? What are the criteria for becoming
supported again? I'm fine with this route over skipped tests as well, we just
need to make sure we've covered the particulars and tried options 1 and 2
first.<o:p></o:p></p>

</div>

<div>

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

</div>

<div>

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

</div>

</div>

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

</div>

</div>

</body>

</html>