> Date: Mon, 26 Feb 2007 13:53:27 -0500
> From: Richard Lowe <richlowe at richlowe.net>
> User-Agent: Thunderbird 1.5.0.9 (X11/20061229)
> MIME-Version: 1.0
> To: April Chin <April.Chin at eng.sun.com>
> Subject: Re: [osol-code] Round
two:((pre-)pre-review)ksh93-integrationwebrev2007-02-02
> Content-Transfer-Encoding: 7bit
>
> April Chin wrote:
> >> X-Authentication-Warning: dhcp-cbjs05-219-32.PRC.Sun.COM: meem set sender
to
> > peter.memishian at sun.com using -f
> >> From: Peter Memishian <peter.memishian at sun.com>
> >> MIME-Version: 1.0
> >> Content-Transfer-Encoding: 7bit
> >> Date: Tue, 27 Feb 2007 00:34:40 +0800
> >> To: Roland Mainz <roland.mainz at nrubsig.org>
> >> Cc: Peter.Memishian at sun.com, David.Comay at sun.com,
> >> ksh93-integration-discuss
> > <ksh93-integration-discuss at opensolaris.org>, OpenSolaris Code mailing
> > list
> > <opensolaris-code at opensolaris.org>, Mike Kupfer <mike.kupfer at
> > sun.com>, April
> > Chin <April.Chin at eng.sun.com>
> >> Subject: Re: [osol-code] Round
> > two:((pre-)pre-review)ksh93-integrationwebrev2007-02-02
> >>
> >> > > First, documentation is generally not subject to the same sort of
rules.
> >> > > You'll note that findunref already contains a blanket exception for
text
> >> > > files and READMEs. Second, if the source file can reasonably be
argued
> > to
> >> > > have value on Solaris, then it's fine. However, a directory filled
with
> >> > > (e.g.) Windows NT specific files would be hard to argue for.
> >> >
> >> > The only windows files in the tree are
> >> > 1. usr/src/lib/libpp/common/probe.win32
> >> > 2. include/ast_windows.h
> >> >
> >> > [1} can likely go away but [2] is an include file which is referenced
> >> > even on Unix/Linux and therefore we can't remove it easily.
> >>
> >> [1] needs to die. If [2] is referenced, it's not part of this discussion.
> >>
> >> > > As I mentioned in an earlier email, we generally grant exceptions for
> >> > > parts of the source tree that are kept in-sync with an upstream
source.
> >> > > But the exception should not be used to stockpile support for
non-Solaris
> >> > > platforms provided that the files could be automatically pruned from
the
> >> > > upstream source without too much effort.
> >> >
> >> > See above... AFAIK that are the only files which could be removed.
> >>
> >> You can verify this is the case by putting "f" in your NIGHTLY_OPTIONS and
> >> examining usr/src/unref-`uname -p`.out once the build finishes. Note that
> >> you will see a bunch of existing unreferenced files in the list, since the
> >> policy against unreferenced files is only goes back 5 years and was not
> >> retroactively enforced. (Also, to get a completely accurate list, you'll
> >> need to build on both SPARC and x86 and then merge the resulting files.)
> >
> > Thanks for these pointers.
> > Full nightly builds (sparc & x86) on Roland's workspace (version 619)
> > using the -f option yielded no new unreferenced files...the
> > usr/src/unref-{sparc,i386}.out files are identical to the
> > usr/src/unref-{sparc,i386}.ref files.
> >
>
> I assume because you updated exception lists or the like?
Actually, version 619, from which I downloaded Roland's workspace,
does NOT have any changes to usr/src/tools/findunref/exception_list;
however, the following new entries have been recently added to the latest
usr/src/tools/findunref/exception_list, which, according to the comments
in the file, require gatekeeper approval:
# ident "@(#)exception_list 1.76 06/09/13 SMI"
@@ -53,11 +53,18 @@
#
# Ignore everything under trees that may be resynched from outside ON.
#
+./src/cmd/ast
+./src/cmd/ksh
./src/cmd/perl
./src/cmd/svc/configd/sqlite
./src/cmd/tcpd
./src/common/openssl
./src/grub
+./src/lib/libast
+./src/lib/libcmd
+./src/lib/libdll
+./src/lib/libpp
+./src/lib/libshell
./src/uts/intel/sys/acpi
I'm therefore cc-ing the gatekeepers alias for this...
>
> Otherwise I can't see how that would be the case, given that we *know* some
> of the files being introduced are unreferenced by the build...
Yes, this was puzzling to us as well--neither I nor Roland saw
anything listed for "unreferenced files" for our nightly builds
(with -f option) based on his workspace.
April
>
> -- Rich
