X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C83B64.F303CF61@onstor-exch02.onstor.net>; Mon, 10 Dec 2007 11:43:33 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C83B64.F303CF61"
References: <BB375AF679D4A34E9CA8DFA650E2B04E06FCE6C2@onstor-exch02.onstor.net>
Content-class: urn:content-classes:message
Subject: RE: This change broke cg and bl builds
Date: Mon, 10 Dec 2007 11:38:59 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02F3DC56@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: This change broke cg and bl builds
Thread-Index: Acg7XnCAwIgXS6AJQvqzSyzzRbWkUAAAB0xkAACZhPAAANb5TQ==
From: "Ken Renshaw" <ken.renshaw@onstor.com>
To: "Tim Gardner" <tim.gardner@onstor.com>,
	"Andy Sharp" <andy.sharp@onstor.com>
Cc: "Paul Hammer" <paul.hammer@onstor.com>,
	"Brian Stark" <brian.stark@onstor.com>,
	"Brian DeForest" <brian.deforest@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C83B64.F303CF61
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Tim, just wanted to clear up one point.=20

I agree again with all you said, and the emails do go out after every =
build except when they are in 'debugging' mode...which I try not to do =
live but sometimes have to. I realize that without asking for further =
information this could lead one to believe the builds didn't catch the =
error, or worst yet aren't even getting run. I'm certainly not trying to =
leave that impression, and apologize for the ensuing rumblings, and so =
emails will be sent out every night rain or shine....just remember they =
are modulo a low false trigger rate in that case.

Thanks Tim, and I'm happy to clear up anything or change process as you =
in development need.

-Ken


-----Original Message-----
From: Tim Gardner
Sent: Mon 12/10/2007 11:22 AM
To: Ken Renshaw; Andy Sharp
Cc: Paul Hammer; Brian Stark
Subject: RE: This change broke cg and bl builds
=20

Hi Ken,

Thanks for clearing this up.
Part of the confusion here is that I believe the cougar team was =
operating=20
with the expectation that any time the build broke, an email would be =
sent.
This is how it was for awhile and then the emails stopped and I don't =
recall
seeing an email from you saying you were changing the email policy.
When we originally discussed this you agreed to set it up so that we
would receive an email after every build.
If you are getting complaints about spam then perhaps it would be best
to setup a separate email alias. But I think it is in the best interest =
of
every software engineer to see a daily email about the nightly build.
This way we can react quickly to breakages and developers are reminded
that a nightly build is running which will hopefully make them more
sensitive to breaking the build.
I will bring this up at the next software meeting. But for now I would
like you to go back to the original policy of having the nightly build
send an email to dl-software indicating the success or failure
every night.

Tim

> -----Original Message-----
> From: Ken Renshaw
> Sent: Monday, December 10, 2007 11:09 AM
> To: Andy Sharp; Ron Bhanukitsiri
> Cc: Yuvarani Cothandaraman; dl-software; Paul Hammer; Brian Stark; Ken
> Renshaw
> Subject: RE: This change broke cg and bl builds
>=20
> Wrong assumption Andy.
>=20
> Once again I wish people would *ask* instead of *assume*, that's where =
a
> lot of perception comes from, and where a lot of communication could =
be
> fixed.
>=20
> When I do work on the pass/fail logic for the nightly builds I turn =
off
> global notification to keep from spamming you, but always always send
> emails to myself from buildadm irregardless. Once I've tested the
> pass/fail logic by running it a day or so I reenable global =
notifications.
> I have dryrun flags in place but the entire process can only be tested
> live nightly, so once in a while I take this route ( last time was =
when a
> bsd problem was missed, can't remember the time before that... ).
>=20
> The last email from the build failure is included below ( rest assured
> there were 3 for 3 night's worth ), and it's what I used to trigger =
Ron
> into fixing the problem.
>=20
> My problem is that I'm going to get complaints either from the extra =
spam
> or from a missed email, so I choose the one that attracts the least
> attention. If you wish I can take the other route, that of always =
sending
> the global notifications, and then send out a 'false alarm' email once =
it
> has been triaged.
>=20
> But as I said, builds were running, build caught the failure, and =
build
> worked with the ensuring developer to correct the action. Sorry it =
didn't
> happen before y'all showed back up from the weekend.
>=20
> ------Included message-----------
>=20
> -----Original Message-----
> From: Build Admin [mailto:build@localhost.localdomain]
> Sent: Mon 12/10/2007 6:25 AM
> To: Ken Renshaw
> Subject: Compilation failure in dev branch
>=20
> /perforce/buildlogs/dev/Monday/bl-dbg-compile.log:make[2]: ***
> [../../Build/bl/dbg/Objects/SSC/sm-utils/cmd-utils.o] Error 1
> /perforce/buildlogs/dev/Monday/bl-dbg-compile.log:make[1]: *** =
[default]
> Error 1
> /perforce/buildlogs/dev/Monday/bl-dbg-compile.log:make: *** [ssc] =
Error 2
> /perforce/buildlogs/dev/Monday/bl-opt-compile.log:make[2]: ***
> [../../Build/bl/opt/Objects/SSC/sm-utils/cmd-utils.o] Error 1
> /perforce/buildlogs/dev/Monday/bl-opt-compile.log:make[1]: *** =
[default]
> Error 1
> /perforce/buildlogs/dev/Monday/bl-opt-compile.log:make: *** [ssc] =
Error 2
> /perforce/buildlogs/dev/Monday/cg-dbg-compile.log:make[2]: ***
> [../../Build/cg/dbg/Objects/SSC/sm-utils/cmd-utils.o] Error 1
> /perforce/buildlogs/dev/Monday/cg-dbg-compile.log:make[1]: *** =
[default]
> Error 1
> /perforce/buildlogs/dev/Monday/cg-dbg-compile.log:make: *** [ssc] =
Error 2
> /perforce/buildlogs/dev/Monday/cg-opt-compile.log:make[2]: ***
> [../../Build/cg/opt/Objects/SSC/sm-utils/cmd-utils.o] Error 1
> /perforce/buildlogs/dev/Monday/cg-opt-compile.log:make[1]: *** =
[default]
> Error 1
> /perforce/buildlogs/dev/Monday/cg-opt-compile.log:make: *** [ssc] =
Error 2
>=20
> -----End included message----
>=20
> Thanks,
>=20
> -Ken
>=20
> -----Original Message-----
> From: Andy Sharp
> Sent: Mon 12/10/2007 10:56 AM
> To: Ron Bhanukitsiri
> Cc: Ken Renshaw; Yuvarani Cothandaraman; dl-software; Paul Hammer; =
Brian
> Stark
> Subject: Re: This change broke cg and bl builds
>=20
> No worries, Ron.
>=20
> Well, almost no worries.
>=20
> The breakage was checked in on Friday, but apparently no notice from =
our
> nightly build whatsoever.
>=20
> I believe I'm correct in saying we should have been getting messages
> since Saturday informing us of the breakage?
>=20
> Our engineering processes, including QA and software development, rely
> heavily on the sanctity and trustworthiness of the nightly build, but
> right now the perception is that it can't be trusted.  Can we put a
> priority on doing whatever it is that needs to be done to fix it?
>=20
> Please?
>=20
> Thanks,
>=20
> a
>=20
>=20
> On Mon, 10 Dec 2007 10:36:04 -0800 "Ron Bhanukitsiri" =
<ronb@onstor.com>
> wrote:
>=20
> > Sorry about that.  The fix has been checked in.
> > CL #26840.
> >
> > Ron B[ee]
> >
> > -----Original Message-----
> > From: Ken Renshaw
> > Sent: Sunday, December 09, 2007 2:05 PM
> > To: Ron Bhanukitsiri
> > Cc: Brian DeForest
> > Subject: FW: This change broke cg and bl builds
> > Importance: High
> >
> > Hi Ron, this checkin breaks the cougar and bobcat-linux cg and bl
> > targets, here's the error:
> >
> > make[2]: Entering directory
> > `/perforce/trees/dev/nfx-tree/code/sm-utils' =
/usr/bin/mipsel-linux-gnu-
> gcc-4.1
> > -fPIC -fms-extensions -Wno-pointer-sign  -DBOBCAT -Wall
> > -Wmissing-prototypes -g -Wall -Wmissing-prototypes -Werror
> > -DEXTENDED_SECURITY -DNFX_KERBEROS -DNETEEE_FRAGMENT  -G 0
> > -DONSTOR_CHANGE -DLDAP_DEPRECATED -DOS_INCL=3D\"linux.h\"  -I./linux
> > -I../../Includes/bl/SSC -I../../Includes/bl -I../../Includes/linux
> > -I../../Includes -I. -I../../Build/bl/opt -DLANGUAGE_C -DLINUX_TEST
> > -g -DSSC -DSSC_mips -DNFX_MOD_SSC -c cmd-utils.c -o
> > ../../Build/bl/opt/Objects/SSC/sm-utils/cmd-utils.o
> > cmd-utils.c: In function 'utils_displayShareACL':
> > cmd-utils.c:2513: error: duplicate case value
> > cmd-utils.c:2511: error: previously used here
> > cmd-utils.c:2520: error: duplicate case value
> > cmd-utils.c:2519: error: previously used here
> > cmd-utils.c:2522: error: duplicate case value
> > cmd-utils.c:2521: error: previously used here
> > make[2]: *** [../../Build/bl/opt/Objects/SSC/sm-utils/cmd-utils.o]
> > Error 1
> > make[2]: Leaving directory
> > `/perforce/trees/dev/nfx-tree/code/sm-utils'
> >
> > I thought I'd give you a chance to fix it before teh cougar team
> > notices in the morning ;)
> >
> > Thanks,
> >
> > -Ken
> >
> >
> > -----Original Message-----
> > From: Build Admin [mailto:build@localhost.localdomain]
> > Sent: Sun 12/9/2007 2:02 PM
> > To: Ken Renshaw
> > Subject:
> >
> > Change 26825 by ronb@ronb-dev-local on 2007/12/07 19:41:10
> >
> > 	Reviewed by: briand
> >
> > 	Add AT&T mkdir filesystem CLI feature.
> >
> > Affected files ...
> >
> > ... //depot/dev/nfx-tree/code/sm-gns/gns-api.c#4 edit
> > ... //depot/dev/nfx-tree/code/sm-utils/cmd-utils.c#14 edit
> > ... //depot/dev/nfx-tree/code/sm-utils/cmd-utils.h#5 edit
> > ... //depot/dev/nfx-tree/code/ssc-cluster/cluster-gns-api.c#6 edit
> > ...
> > =
//depot/dev/nfx-tree/code/ssc-nfxsh/agile-man/help_filesystem_quota_grou
> > p_set.txt#2 edit
> > ...
> > =
//depot/dev/nfx-tree/code/ssc-nfxsh/agile-man/help_filesystem_quota_tree
> > _set.txt#2 edit
> > ...
> > =
//depot/dev/nfx-tree/code/ssc-nfxsh/agile-man/help_filesystem_quota_user
> > _set.txt#2 edit
> > ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_cshare.c#6 edit
> > ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_fsutil.c#3 edit
> > ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_fsutil.h#2 edit
> > ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_gns.c#3 edit
> > ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_quota.c#8 edit
> > ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_vol.c#27 edit
> >
> >
> >



------_=_NextPart_001_01C83B64.F303CF61
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE: This change broke cg and bl builds</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi Tim, just wanted to clear up one point.<BR>
<BR>
I agree again with all you said, and the emails do go out after every =
build except when they are in 'debugging' mode...which I try not to do =
live but sometimes have to. I realize that without asking for further =
information this could lead one to believe the builds didn't catch the =
error, or worst yet aren't even getting run. I'm certainly not trying to =
leave that impression, and apologize for the ensuing rumblings, and so =
emails will be sent out every night rain or shine....just remember they =
are modulo a low false trigger rate in that case.<BR>
<BR>
Thanks Tim, and I'm happy to clear up anything or change process as you =
in development need.<BR>
<BR>
-Ken<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Tim Gardner<BR>
Sent: Mon 12/10/2007 11:22 AM<BR>
To: Ken Renshaw; Andy Sharp<BR>
Cc: Paul Hammer; Brian Stark<BR>
Subject: RE: This change broke cg and bl builds<BR>
<BR>
<BR>
Hi Ken,<BR>
<BR>
Thanks for clearing this up.<BR>
Part of the confusion here is that I believe the cougar team was =
operating<BR>
with the expectation that any time the build broke, an email would be =
sent.<BR>
This is how it was for awhile and then the emails stopped and I don't =
recall<BR>
seeing an email from you saying you were changing the email policy.<BR>
When we originally discussed this you agreed to set it up so that we<BR>
would receive an email after every build.<BR>
If you are getting complaints about spam then perhaps it would be =
best<BR>
to setup a separate email alias. But I think it is in the best interest =
of<BR>
every software engineer to see a daily email about the nightly =
build.<BR>
This way we can react quickly to breakages and developers are =
reminded<BR>
that a nightly build is running which will hopefully make them more<BR>
sensitive to breaking the build.<BR>
I will bring this up at the next software meeting. But for now I =
would<BR>
like you to go back to the original policy of having the nightly =
build<BR>
send an email to dl-software indicating the success or failure<BR>
every night.<BR>
<BR>
Tim<BR>
<BR>
&gt; -----Original Message-----<BR>
&gt; From: Ken Renshaw<BR>
&gt; Sent: Monday, December 10, 2007 11:09 AM<BR>
&gt; To: Andy Sharp; Ron Bhanukitsiri<BR>
&gt; Cc: Yuvarani Cothandaraman; dl-software; Paul Hammer; Brian Stark; =
Ken<BR>
&gt; Renshaw<BR>
&gt; Subject: RE: This change broke cg and bl builds<BR>
&gt;<BR>
&gt; Wrong assumption Andy.<BR>
&gt;<BR>
&gt; Once again I wish people would *ask* instead of *assume*, that's =
where a<BR>
&gt; lot of perception comes from, and where a lot of communication =
could be<BR>
&gt; fixed.<BR>
&gt;<BR>
&gt; When I do work on the pass/fail logic for the nightly builds I turn =
off<BR>
&gt; global notification to keep from spamming you, but always always =
send<BR>
&gt; emails to myself from buildadm irregardless. Once I've tested =
the<BR>
&gt; pass/fail logic by running it a day or so I reenable global =
notifications.<BR>
&gt; I have dryrun flags in place but the entire process can only be =
tested<BR>
&gt; live nightly, so once in a while I take this route ( last time was =
when a<BR>
&gt; bsd problem was missed, can't remember the time before that... =
).<BR>
&gt;<BR>
&gt; The last email from the build failure is included below ( rest =
assured<BR>
&gt; there were 3 for 3 night's worth ), and it's what I used to trigger =
Ron<BR>
&gt; into fixing the problem.<BR>
&gt;<BR>
&gt; My problem is that I'm going to get complaints either from the =
extra spam<BR>
&gt; or from a missed email, so I choose the one that attracts the =
least<BR>
&gt; attention. If you wish I can take the other route, that of always =
sending<BR>
&gt; the global notifications, and then send out a 'false alarm' email =
once it<BR>
&gt; has been triaged.<BR>
&gt;<BR>
&gt; But as I said, builds were running, build caught the failure, and =
build<BR>
&gt; worked with the ensuring developer to correct the action. Sorry it =
didn't<BR>
&gt; happen before y'all showed back up from the weekend.<BR>
&gt;<BR>
&gt; ------Included message-----------<BR>
&gt;<BR>
&gt; -----Original Message-----<BR>
&gt; From: Build Admin [<A =
HREF=3D"mailto:build@localhost.localdomain">mailto:build@localhost.locald=
omain</A>]<BR>
&gt; Sent: Mon 12/10/2007 6:25 AM<BR>
&gt; To: Ken Renshaw<BR>
&gt; Subject: Compilation failure in dev branch<BR>
&gt;<BR>
&gt; /perforce/buildlogs/dev/Monday/bl-dbg-compile.log:make[2]: ***<BR>
&gt; [../../Build/bl/dbg/Objects/SSC/sm-utils/cmd-utils.o] Error 1<BR>
&gt; /perforce/buildlogs/dev/Monday/bl-dbg-compile.log:make[1]: *** =
[default]<BR>
&gt; Error 1<BR>
&gt; /perforce/buildlogs/dev/Monday/bl-dbg-compile.log:make: *** [ssc] =
Error 2<BR>
&gt; /perforce/buildlogs/dev/Monday/bl-opt-compile.log:make[2]: ***<BR>
&gt; [../../Build/bl/opt/Objects/SSC/sm-utils/cmd-utils.o] Error 1<BR>
&gt; /perforce/buildlogs/dev/Monday/bl-opt-compile.log:make[1]: *** =
[default]<BR>
&gt; Error 1<BR>
&gt; /perforce/buildlogs/dev/Monday/bl-opt-compile.log:make: *** [ssc] =
Error 2<BR>
&gt; /perforce/buildlogs/dev/Monday/cg-dbg-compile.log:make[2]: ***<BR>
&gt; [../../Build/cg/dbg/Objects/SSC/sm-utils/cmd-utils.o] Error 1<BR>
&gt; /perforce/buildlogs/dev/Monday/cg-dbg-compile.log:make[1]: *** =
[default]<BR>
&gt; Error 1<BR>
&gt; /perforce/buildlogs/dev/Monday/cg-dbg-compile.log:make: *** [ssc] =
Error 2<BR>
&gt; /perforce/buildlogs/dev/Monday/cg-opt-compile.log:make[2]: ***<BR>
&gt; [../../Build/cg/opt/Objects/SSC/sm-utils/cmd-utils.o] Error 1<BR>
&gt; /perforce/buildlogs/dev/Monday/cg-opt-compile.log:make[1]: *** =
[default]<BR>
&gt; Error 1<BR>
&gt; /perforce/buildlogs/dev/Monday/cg-opt-compile.log:make: *** [ssc] =
Error 2<BR>
&gt;<BR>
&gt; -----End included message----<BR>
&gt;<BR>
&gt; Thanks,<BR>
&gt;<BR>
&gt; -Ken<BR>
&gt;<BR>
&gt; -----Original Message-----<BR>
&gt; From: Andy Sharp<BR>
&gt; Sent: Mon 12/10/2007 10:56 AM<BR>
&gt; To: Ron Bhanukitsiri<BR>
&gt; Cc: Ken Renshaw; Yuvarani Cothandaraman; dl-software; Paul Hammer; =
Brian<BR>
&gt; Stark<BR>
&gt; Subject: Re: This change broke cg and bl builds<BR>
&gt;<BR>
&gt; No worries, Ron.<BR>
&gt;<BR>
&gt; Well, almost no worries.<BR>
&gt;<BR>
&gt; The breakage was checked in on Friday, but apparently no notice =
from our<BR>
&gt; nightly build whatsoever.<BR>
&gt;<BR>
&gt; I believe I'm correct in saying we should have been getting =
messages<BR>
&gt; since Saturday informing us of the breakage?<BR>
&gt;<BR>
&gt; Our engineering processes, including QA and software development, =
rely<BR>
&gt; heavily on the sanctity and trustworthiness of the nightly build, =
but<BR>
&gt; right now the perception is that it can't be trusted.&nbsp; Can we =
put a<BR>
&gt; priority on doing whatever it is that needs to be done to fix =
it?<BR>
&gt;<BR>
&gt; Please?<BR>
&gt;<BR>
&gt; Thanks,<BR>
&gt;<BR>
&gt; a<BR>
&gt;<BR>
&gt;<BR>
&gt; On Mon, 10 Dec 2007 10:36:04 -0800 &quot;Ron Bhanukitsiri&quot; =
&lt;ronb@onstor.com&gt;<BR>
&gt; wrote:<BR>
&gt;<BR>
&gt; &gt; Sorry about that.&nbsp; The fix has been checked in.<BR>
&gt; &gt; CL #26840.<BR>
&gt; &gt;<BR>
&gt; &gt; Ron B[ee]<BR>
&gt; &gt;<BR>
&gt; &gt; -----Original Message-----<BR>
&gt; &gt; From: Ken Renshaw<BR>
&gt; &gt; Sent: Sunday, December 09, 2007 2:05 PM<BR>
&gt; &gt; To: Ron Bhanukitsiri<BR>
&gt; &gt; Cc: Brian DeForest<BR>
&gt; &gt; Subject: FW: This change broke cg and bl builds<BR>
&gt; &gt; Importance: High<BR>
&gt; &gt;<BR>
&gt; &gt; Hi Ron, this checkin breaks the cougar and bobcat-linux cg and =
bl<BR>
&gt; &gt; targets, here's the error:<BR>
&gt; &gt;<BR>
&gt; &gt; make[2]: Entering directory<BR>
&gt; &gt; `/perforce/trees/dev/nfx-tree/code/sm-utils' =
/usr/bin/mipsel-linux-gnu-<BR>
&gt; gcc-4.1<BR>
&gt; &gt; -fPIC -fms-extensions -Wno-pointer-sign&nbsp; -DBOBCAT =
-Wall<BR>
&gt; &gt; -Wmissing-prototypes -g -Wall -Wmissing-prototypes -Werror<BR>
&gt; &gt; -DEXTENDED_SECURITY -DNFX_KERBEROS -DNETEEE_FRAGMENT&nbsp; -G =
0<BR>
&gt; &gt; -DONSTOR_CHANGE -DLDAP_DEPRECATED =
-DOS_INCL=3D\&quot;linux.h\&quot;&nbsp; -I./linux<BR>
&gt; &gt; -I../../Includes/bl/SSC -I../../Includes/bl =
-I../../Includes/linux<BR>
&gt; &gt; -I../../Includes -I. -I../../Build/bl/opt -DLANGUAGE_C =
-DLINUX_TEST<BR>
&gt; &gt; -g -DSSC -DSSC_mips -DNFX_MOD_SSC -c cmd-utils.c -o<BR>
&gt; &gt; ../../Build/bl/opt/Objects/SSC/sm-utils/cmd-utils.o<BR>
&gt; &gt; cmd-utils.c: In function 'utils_displayShareACL':<BR>
&gt; &gt; cmd-utils.c:2513: error: duplicate case value<BR>
&gt; &gt; cmd-utils.c:2511: error: previously used here<BR>
&gt; &gt; cmd-utils.c:2520: error: duplicate case value<BR>
&gt; &gt; cmd-utils.c:2519: error: previously used here<BR>
&gt; &gt; cmd-utils.c:2522: error: duplicate case value<BR>
&gt; &gt; cmd-utils.c:2521: error: previously used here<BR>
&gt; &gt; make[2]: *** =
[../../Build/bl/opt/Objects/SSC/sm-utils/cmd-utils.o]<BR>
&gt; &gt; Error 1<BR>
&gt; &gt; make[2]: Leaving directory<BR>
&gt; &gt; `/perforce/trees/dev/nfx-tree/code/sm-utils'<BR>
&gt; &gt;<BR>
&gt; &gt; I thought I'd give you a chance to fix it before teh cougar =
team<BR>
&gt; &gt; notices in the morning ;)<BR>
&gt; &gt;<BR>
&gt; &gt; Thanks,<BR>
&gt; &gt;<BR>
&gt; &gt; -Ken<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt; -----Original Message-----<BR>
&gt; &gt; From: Build Admin [<A =
HREF=3D"mailto:build@localhost.localdomain">mailto:build@localhost.locald=
omain</A>]<BR>
&gt; &gt; Sent: Sun 12/9/2007 2:02 PM<BR>
&gt; &gt; To: Ken Renshaw<BR>
&gt; &gt; Subject:<BR>
&gt; &gt;<BR>
&gt; &gt; Change 26825 by ronb@ronb-dev-local on 2007/12/07 19:41:10<BR>
&gt; &gt;<BR>
&gt; &gt; &nbsp;&nbsp;&nbsp; Reviewed by: briand<BR>
&gt; &gt;<BR>
&gt; &gt; &nbsp;&nbsp;&nbsp; Add AT&amp;T mkdir filesystem CLI =
feature.<BR>
&gt; &gt;<BR>
&gt; &gt; Affected files ...<BR>
&gt; &gt;<BR>
&gt; &gt; ... //depot/dev/nfx-tree/code/sm-gns/gns-api.c#4 edit<BR>
&gt; &gt; ... //depot/dev/nfx-tree/code/sm-utils/cmd-utils.c#14 edit<BR>
&gt; &gt; ... //depot/dev/nfx-tree/code/sm-utils/cmd-utils.h#5 edit<BR>
&gt; &gt; ... //depot/dev/nfx-tree/code/ssc-cluster/cluster-gns-api.c#6 =
edit<BR>
&gt; &gt; ...<BR>
&gt; &gt; =
//depot/dev/nfx-tree/code/ssc-nfxsh/agile-man/help_filesystem_quota_grou<=
BR>
&gt; &gt; p_set.txt#2 edit<BR>
&gt; &gt; ...<BR>
&gt; &gt; =
//depot/dev/nfx-tree/code/ssc-nfxsh/agile-man/help_filesystem_quota_tree<=
BR>
&gt; &gt; _set.txt#2 edit<BR>
&gt; &gt; ...<BR>
&gt; &gt; =
//depot/dev/nfx-tree/code/ssc-nfxsh/agile-man/help_filesystem_quota_user<=
BR>
&gt; &gt; _set.txt#2 edit<BR>
&gt; &gt; ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_cshare.c#6 =
edit<BR>
&gt; &gt; ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_fsutil.c#3 =
edit<BR>
&gt; &gt; ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_fsutil.h#2 =
edit<BR>
&gt; &gt; ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_gns.c#3 edit<BR>
&gt; &gt; ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_quota.c#8 edit<BR>
&gt; &gt; ... //depot/dev/nfx-tree/code/ssc-nfxsh/cmd_vol.c#27 edit<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C83B64.F303CF61--
