Thanks for the review!

>>>>> Mark J Nelson writes:

Mark> usr/src/tools/scripts/cryptodrop.sh: 
Mark> 107 Should mktemp get a six-digit template?  

AFAICT it doesn't matter that much.  The X's are filled in with random
characters, not a pid.

Mark> 122 This relies on findcrypto emitting relative paths?  (Ie no
Mark>     test for "/" needed?)

Right.  The "cpio_filt -p" also relies on that.  I'll add a sanity check
to the script.

Mark> 131 If we care overly much about performance here, we could prune
Mark>     the list via dirname/sort -u before we pass the elements to
Mark>     alldirs.  But this is relatively short, as lists go, right?

Yeah, under 50 entries.

Mark> usr/src/tools/scripts/mktpl.pl
Mark> - I'm not really a big Perl guy.  Seems like the maketpl calls on
Mark>   151-153 could be guarded by !opt_c, but instead rely on the
Mark>   lists in question being empty?

Right, the current mktpl keys off the list.  It seemed more robust to
keep that logic, rather than make assumptions about what would be in the
list.

Mark> usr/src/tools/scripts/nightly.1 
Mark> 571-575 Does this imply a need to update default gatekeeper and
Mark>         developer env files, as well as open?

Well, if you set ON_CRYPTO_BINS, nightly will use those binaries instead
of what you built.  So you really only want to set it when you know that
you can't use the binaries that you built.

I suppose I could add a commented-out entry to the gatekeeper and
developer env files, for use by project gates (nightly -O).  I'll go
ahead and do that.

Mark> usr/src/tools/scripts/nightly.sh 
Mark> 81 Should this use $BUILD_DATE?

Yes, that seems cleaner.  

thanks,
mike
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org

Reply via email to