X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C78B83.0E693260@onstor-exch02.onstor.net>; Mon, 30 Apr 2007 16:55:40 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C78B83.0E693260"
References: <BB375AF679D4A34E9CA8DFA650E2B04E0346A3E8@onstor-exch02.onstor.net>
Content-class: urn:content-classes:message
Subject: RE: flash_install.sh - Don't do it...
Date: Mon, 30 Apr 2007 16:52:27 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02F3D03B@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: flash_install.sh - Don't do it...
Thread-Index: AceLgABoKfmQrDw2T/KOmOQHifQeOwAADfGgAABpLrAAAC+vSA==
From: "Ken Renshaw" <ken.renshaw@onstor.com>
To: "John Rogers" <john.rogers@onstor.com>,
	"Andy Sharp" <andy.sharp@onstor.com>
Cc: "John Keiffer" <john.keiffer@onstor.com>,
	"dl-QA" <dl-qa@onstor.com>,
	<dl-data-management>

This is a multi-part message in MIME format.

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

Well, not exactly.
=20
I fixed two problems in the build script WRT openbsd usage.
=20
- Don't ever use the public copies in /n/Build-Trees/BSD since =
developers can wipe these out. Use local masters. This also gives a =
source to replenish the aforementioned directory.
=20
-Always fully sync and build openbsd for submittals. Andy's point came =
from this direction.
=20
Other than that, I do believe we're covered.
=20
Thanks,
=20
-Ken
=20

________________________________

From: John Rogers
Sent: Mon 4/30/2007 4:47 PM
To: John Rogers; Andy Sharp; Ken Renshaw
Cc: John Keiffer; dl-QA; 'dl-data-management'
Subject: RE: flash_install.sh - Don't do it...



Nevermind, I think I understand. You are saying build-trees is a bad =
place because of some issue.

-----Original Message-----
From: John Rogers
Sent: Monday, April 30, 2007 4:43 PM
To: Andy Sharp; Ken Renshaw
Cc: John Keiffer; dl-QA; dl-data-management
Subject: RE: flash_install.sh - Don't do it...

I am not sure what you mean by build procedure. I'm not arguing to keep =
any particular process. I'm just trying to understand what you are =
proposing.

Generally QA folk don't run flash_install.sh unless their system has =
failed an upgrade process, that uses system upgrade. flash_install uses =
build_trees which should be a known good(or well at least known) source =
of compiled code.

I think you might be blurring some workflows. What I think you are =
suggesting is that to recover a system, we should compile the source =
code and then get it onto a flash card somehow.

-----Original Message-----
From: Andy Sharp
Sent: Monday, April 30, 2007 4:34 PM
To: Ken Renshaw
Cc: John Keiffer; dl-QA; dl-data-management
Subject: Re: flash_install.sh - Don't do it...

This problem I thought was fixed in the referenced version, but I
confess I don't always grok the QA version nomenclature.

Suffice it to say that this problem is of a category that has happened
more than once since I started here, and really cries out for "fixin"
the build procedure.

The official build procedure should start with a blank directory, p4
sync the entire branch, and build *everything*, producing the release
candidate.  I've brought this up before, and was told about history and
other things, but I don't recall any of it, so let's hear now in print
if there are any objections to adopting this as our build procedure.
Otherwise I will just forget again and ask the same question three
months from now.

Cheers,

a

On Mon, 30 Apr 2007 16:02:00 -0700 "Ken Renshaw"
<ken.renshaw@onstor.com> wrote:

> This is known in teh sub14 builds, sub15 due out tomorrow will have
> those defects addressed.
>
> Thanks,
>
> -Ken
>
>
> -----Original Message-----
> From: John Keiffer
> Sent: Mon 4/30/2007 3:54 PM
> To: dl-QA
> Cc: Andy Sharp
> Subject: flash_install.sh - Don't do it...
>=20
> FYI:
>
>=20
>
> After almost completely messing up my system for good, I decided to



------_=_NextPart_001_01C78B83.0E693260
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML dir=3Dltr><HEAD><TITLE>RE: flash_install.sh - Don't do =
it...</TITLE>=0A=
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A=
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText38249 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Well, not =
exactly.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I fixed two problems in the =
build script WRT openbsd usage.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>- Don't ever use the public =
copies in /n/Build-Trees/BSD since developers can wipe these out. Use =
local masters. This also gives a source to replenish the aforementioned =
directory.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>-Always fully sync and build =
openbsd for submittals. Andy's point came from this =
direction.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Other than that, I do believe =
we're covered.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Thanks,</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2>-Ken</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></DIV>=0A=
<DIV dir=3Dltr><BR>=0A=
<HR tabIndex=3D-1>=0A=
<FONT face=3DTahoma size=3D2><B>From:</B> John Rogers<BR><B>Sent:</B> =
Mon 4/30/2007 4:47 PM<BR><B>To:</B> John Rogers; Andy Sharp; Ken =
Renshaw<BR><B>Cc:</B> John Keiffer; dl-QA; =
'dl-data-management'<BR><B>Subject:</B> RE: flash_install.sh - Don't do =
it...<BR></FONT><BR></DIV>=0A=
<DIV>=0A=
<P><FONT size=3D2>Nevermind, I think I understand. You are saying =
build-trees is a bad place because of some issue.<BR><BR>-----Original =
Message-----<BR>From: John Rogers<BR>Sent: Monday, April 30, 2007 4:43 =
PM<BR>To: Andy Sharp; Ken Renshaw<BR>Cc: John Keiffer; dl-QA; =
dl-data-management<BR>Subject: RE: flash_install.sh - Don't do =
it...<BR><BR>I am not sure what you mean by build procedure. I'm not =
arguing to keep any particular process. I'm just trying to understand =
what you are proposing.<BR><BR>Generally QA folk don&#8217;t run =
flash_install.sh unless their system has failed an upgrade process, that =
uses system upgrade. flash_install uses build_trees which should be a =
known good(or well at least known) source of compiled code.<BR><BR>I =
think you might be blurring some workflows. What I think you are =
suggesting is that to recover a system, we should compile the source =
code and then get it onto a flash card somehow.<BR><BR>-----Original =
Message-----<BR>From: Andy Sharp<BR>Sent: Monday, April 30, 2007 4:34 =
PM<BR>To: Ken Renshaw<BR>Cc: John Keiffer; dl-QA; =
dl-data-management<BR>Subject: Re: flash_install.sh - Don't do =
it...<BR><BR>This problem I thought was fixed in the referenced version, =
but I<BR>confess I don't always grok the QA version =
nomenclature.<BR><BR>Suffice it to say that this problem is of a =
category that has happened<BR>more than once since I started here, and =
really cries out for "fixin"<BR>the build procedure.<BR><BR>The official =
build procedure should start with a blank directory, p4<BR>sync the =
entire branch, and build *everything*, producing the =
release<BR>candidate.&nbsp; I've brought this up before, and was told =
about history and<BR>other things, but I don't recall any of it, so =
let's hear now in print<BR>if there are any objections to adopting this =
as our build procedure.<BR>Otherwise I will just forget again and ask =
the same question three<BR>months from =
now.<BR><BR>Cheers,<BR><BR>a<BR><BR>On Mon, 30 Apr 2007 16:02:00 -0700 =
"Ken Renshaw"<BR>&lt;ken.renshaw@onstor.com&gt; wrote:<BR><BR>&gt; This =
is known in teh sub14 builds, sub15 due out tomorrow will have<BR>&gt; =
those defects addressed.<BR>&gt;<BR>&gt; Thanks,<BR>&gt;<BR>&gt; =
-Ken<BR>&gt;<BR>&gt;<BR>&gt; -----Original Message-----<BR>&gt; From: =
John Keiffer<BR>&gt; Sent: Mon 4/30/2007 3:54 PM<BR>&gt; To: =
dl-QA<BR>&gt; Cc: Andy Sharp<BR>&gt; Subject: flash_install.sh - Don't =
do it...<BR>&gt;&nbsp;<BR>&gt; =
FYI:<BR>&gt;<BR>&gt;&nbsp;<BR>&gt;<BR>&gt; After almost completely =
messing up my system for good, I decided =
to<BR></FONT></P></DIV></BODY></HTML>
------_=_NextPart_001_01C78B83.0E693260--
