X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C7AF74.434D346F@onstor-exch02.onstor.net>; Fri, 15 Jun 2007 09:40:28 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7AF74.434D346F"
Content-class: urn:content-classes:message
Subject: A little more formaily...
Date: Fri, 15 Jun 2007 09:40:28 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E031D8894@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: A little more formaily...
Thread-Index: AcevdENdnR+AAq3pR3iU1eNT+eCFZA==
From: "Richard Beck" <IMCEAEX-_O=ONSTOR_OU=FIRST+20ADMINISTRATIVE+20GROUP_CN=RECIPIENTS_CN=RICHARD+2EBECK@onstor.com>
To: "Tim Gardner" <tim.gardner@onstor.com>,
	"Maxim Kozlovsky" <maxim.kozlovsky@onstor.com>,
	"Andy Sharp" <andy.sharp@onstor.com>,
	"Larry Scheer" <larry.scheer@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7AF74.434D346F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Good clear requirements are always a good thing. =20

In the case of requirements for neteee, I had to learn from my talk with
Max on Tuesday how pervasive the use of the EEE protocol is in the
application code.  We might all ask how an oversight like this could
happen, since it's clear when I grep the  nfx-tree for _EEE it's
everywhere. =20

But I was told when I did the initial neteee port in 2005 that only the
address and protocol families would be needed, and that EEE would only
be used during boot up (obviously untrue).  But this was the verbal
requirement.  And my work since I've been back has been focused on the
bottom layer required for the mgmt-bus. So my usual habit of documenting
requirements to avoid misunderstandings was skipped, and shouldn't have
been.

This "little" oversight means that the full neteee protocol, which
includes an additional two layers is being integrated into Linux at the
last minute under schedule pressure.  Since the upper layers of EEE rely
heavily on core network functions there will not be the temptation to
drag unique structures in from BSD, which is good.  But the additional
dependence on the Linux network stack requires a bit more conversion of
the code. I will be using what time I can claim from the weekend toward
getting this done, and will provide a more definitive status on Monday.
I am however, working on the mgmt-bus driver in parallel so there isn't
a linear slip on that.=20

I don't know how many times we all have to learn about assumptions in
communication.  I've got stories from doing fixed-price development that
point up the absolute need for a good detailed requirements document, so
I should know better.  And even though we're all experienced
professionals here, people are looking for ways to improve the process,
and I would put DETAILED REQUIREMENTS DOCUMENTS out there as a biggy.=20

--Rich


------_=_NextPart_001_01C7AF74.434D346F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>A little more formaily...</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us">Good clear requirements are always =
a good thing.&nbsp; </SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us">In the case of requirements for =
neteee, I had to learn from my talk with Max on Tuesday how pervasive =
the use of the EEE protocol is in the application code.&nbsp; We might =
all ask how an oversight like this could happen, since it&#8217;s clear =
when I grep the&nbsp; nfx-tree for _EEE it&#8217;s everywhere.&nbsp; =
</SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us">But I was told when I did the =
initial neteee port in 2005 that only the address and protocol families =
would be needed, and that EEE would only be used during boot up =
(obviously untrue).&nbsp; But this was the verbal requirement.&nbsp; And =
my work since I&#8217;ve been back has been focused on the bottom layer =
required for the mgmt-bus. So my usual habit of documenting requirements =
to avoid misunderstandings was skipped, and shouldn&#8217;t have =
been.</SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us">This &#8220;little&#8221; oversight =
means that the full neteee protocol, which includes an additional two =
layers is being integrated into Linux at the last minute under schedule =
pressure.&nbsp; Since the upper layers of EEE rely heavily on core =
network functions there will not be the temptation to drag unique =
structures in from BSD, which is good.&nbsp; But the additional =
dependence on the Linux network stack requires a bit more conversion of =
the code. I will be using what time I can claim from the weekend toward =
getting this done, and will provide a more definitive status on =
Monday.&nbsp; I am however, working on the mgmt-bus driver in parallel =
so there isn&#8217;t a linear slip on that. </SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us">I don&#8217;t know how many times =
we all have to learn about assumptions in communication.&nbsp; =
I&#8217;ve got stories from doing fixed-price development that point up =
the absolute need for a good detailed requirements document, so I should =
know better.&nbsp; And even though we&#8217;re all experienced =
professionals here, people are looking for ways to improve the process, =
and I would put DETAILED REQUIREMENTS DOCUMENTS out there as a biggy. =
</SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us">--Rich</SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C7AF74.434D346F--
