AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080922160131.0ca027bd@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<larry.scheer@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E056C9835@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 22 Sep 2008 16:01:49 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Larry Scheer" <larry.scheer@onstor.com>
Subject: Re: please review 29151
Message-ID: <20080922160149.1bf0e4cd@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E056C9835@onstor-exch02.onstor.net>
References: <20080911163111.11898fb1@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E056C9835@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Oh crap.  You mean I have to check this !%@!@#$ in?  Why are my palms
sweating?

On Mon, 22 Sep 2008 14:06:14 -0700 "Larry Scheer"
<larry.scheer@onstor.com> wrote:

> I can live with this. Let's get this puppy checked in please!
> 
> Larry
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Thursday, September 11, 2008 4:31 PM
> To: Larry Scheer
> Subject: Re: please review 29151
> 
> Please re-review.  Comments from last review are inline.
> 
> Thanks,
> 
> a
> 
> On Mon, 4 Aug 2008 14:13:34 -0700 "Larry Scheer"
> <larry.scheer@onstor.com> wrote:
> 
> > 
> > build_scripts/buildver/nfxbuild.sh
> > 
> > 
> > line 231, If -u was not given on the command line looks like we
> >      are going to update the FTP upgrade server anyway. Isn't a test
> >      for UPGRADE_FLAG warranted here as well?
> 
> No, it's set the upgrade for true by default only if it's not a
> nightly build.  On nightly builds, you have to specify -u to get that
> funk-tionality.
> 
> > 
> >      All this code for date can be greatly reduced...
> 
> Heh.  I've already reduced it by about 5x it's original.  I'll leave
> the last 20 line reduction for you...
> 
> > Lines 244 through 314 can be replaced with
> > 
> >      export DAYOFTHEWEEK=$(date +%A)
> > 
> >      export MIL_DATE=$(date +%Y%m%d)
> > 
> >      export MIL_LABEL_TAG=$(date +%m%d%y)
> > 
> > Line 334 break the line at '\' It would be nice if the line was
> >      80 chars or less
> 
> Fixed.  I never noticed it was only one line.
> 
> > Line 327: Subtle bug? Does the '\' at the end of this comment
> >      make the next line a comment as well? Shouldn't the '&&\' at
> > the end of the line -- or this whole line -- be removed?
> 
> Hmm.  Fixed.
> 
> > -- General comment-- What is up with the use of '&&' after writing
> >      to the auditlog?!!! Is this some clever "ass saving" trick or
> >      just a collection of subtle bugs to promote job security when
> >      the nightly build doesn't run or breaks in very strange ways?
> 
> The original was filled with that crap, and I mean filled.  With
> absolutely no logic to where control flow would dump out if all the &&
> failed.  Just basically completely retarded.  I didn't remove them
> all I guess. Lazy.
> 
> > Line 350: I would collect the current changelist after the p4
> >      sync was done and change the command to record the top
> > changelist of the workspace and not the depot. There is a subtle
> > difference here. The workspace changelist # can be different from
> > the depot especially since you are syncing only specific
> > directories. The syntax is: cd <workspace>; p4 changes
> > -m1 ...@$P4CLIENT.
> 
> Well hold on.  I need to grab a changelist, and then sync to that.
> That way I know what I'm sync'd to.  If I sync first, then get the
> changelist, another change could go in in the mean time, and I would
> have a changelist I wasn't sync'd to.  As to the syntax, I'm doing the
> equivalent, since the client is set in the environment.
> 
> >      Given the next 40 -- 50 lines of code revolves around
> > collecting the current change list number in this manner this can
> > slide for now. But let's remember to clean this up in the near
> > future this whole section can be simplified and be more accurate by
> > syncing first then collecting the change list number.
> 
> As I mentioned, that sounds buggy to me but maybe I'm missing
> something.
> 
> > Lines 380 -- 395 Ok for now, but here is another tip. It appears
> >      all the builds done by this script are clean builds because the
> >      entire tree is blown away before a p4 sync is done. All you
> > need is a P4 client set to modtime.  You don't need 2 clients.
> 
> I only have one client.  I just change the settings of that client.
> The old nightly build script did it this way, except that one did it
> wrong and used two clients.  Heh.  But given what you say, if one
> client and one sync will work, then great.
> 
> > Line 921: I want to see the build audit logs. Maybe we should
> >      set up a BUILDDOG mail list.
> 
> Quite correct.  Fixed.
> 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Thursday, July 31, 2008 1:55 PM
> > To: Larry Scheer
> > Subject: please review 29151
> > 
> > Change 29151 by andys@ripper on 2008/05/08 15:39:48 *pending*
> > 
> >         Rewrite the nightly build script:
> >         
> >         Delete large unused blocks of code.
> >         
> >         Properly indent code blocks so that's it's actually possible
> >         to maintain this script.
> >         
> >         Fix bug where it was building a different version of BSD
> > than nfx-tree.
> >         
> >         Make it possible to build any arbitrary branch.  No, that
> >         wasn't possible before.  Version information now comes from
> >         nfx-tree/Tools/version-$PROD.
> >         
> >         Pump up the error detection and reporting.  For instance, if
> > the "make" command fails, then the build probably failed.  Hello.
> >         
> >         Add robust error reporting in the emails themselves.
> >         
> >         Add complete information to success emails concerning
> > location of builds, tarballs, etc.
> >         
> >         Upload the source, and put in symlinks for all the different
> >         release variants to the one place the source was actually
> >         uploaded to.
> >         
> >         TODO:
> >                 Some kind of automated archiving to terciary storage
> > of nightly builds, source, and log files that are older
> > than
> >                 some arbitrary age.  And deleting off primary
> > storage. 
> >         reviewed by
> > 
> > Affected files ...
> > 
> > ... //depot/cm/build_scripts/buildver/nfxbuild.sh#45 edit
