@(#) LSARC Questions Version 2.0u @(#)LSARC 1.30 07/12/07 __________________________________________________________________ Copyright 2007 Sun Microsystems, Inc. 0. Remind us: 0.1 The case number for this project? LSARC 2008/493 0.2 This questionnaire is for an [X] Inception Review or [ ] Commitment Review 0.3 Name(s) of person(s) answering the questions? Tom Mueller 0.4 Are these case materials considered public or confidential? public 1. What specifically is the proposal that we are reviewing? 1.1 The case owner will need to put a 1 to 4 paragraph description at the top of the Opinion document. Suggest text for it. Please be specific about deliverable components and their interfaces. This is a sub-project of the Update Center 2 Toolkit project which focuses on the IPS Enhancements, Java-based Bootstrap Initialization Interface, IPS Java API and Python Dependency. 1.2 Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", "micro" or "patch" change and why? (See the release type definitions in http://sac.eng.sun.com/BestPractices/release_taxonomy.html ) New 2. What is the motivation for it? What are the expected benefits for Sun? By what criteria will you judge its success? See the umbrella case for Update Center 2, LSARC/2008/411 3. The plan: 3.1 Who (what groups in what business units) are working on it? The Update Center 2 team in the in Java Enterprise System Engineering department of the Software Infrastructure (SWI) business unit. 3.2 What is the current status? Build 14 of 15 planned builds has been completed. Release of this software is planned for the Glassfish V3 Prelude release in October, 2008. 3.3 Has a design review been done? Yes. 3.4 What Product Approval Committee (PAC) do you expect to approve this project? WAPPAC JESPAC 4. Related Projects: 4.1 What not-yet-delivered Sun projects (libraries, hardware, etc.) does this project depend upon (i.e., need to be successful)? Image Packaging System (IPS or pkg(5)) (PSARC/2008/190) 4.2 What non-Sun projects does this project depend upon? Python OpenSSL 4.3 What other projects depend on this one? See the umbrella case (LSARC/2008/411) 4.4 What other active projects at Sun are related to your project, and how are they related? See the umbrella case (LSARC/2008/411) 4.5 What future projects should be started or avoided to help your project succeed, and why? See the umbrella case (LSARC/2008/411) 4.6 What open source communities does this project interact with? opensolaris.org - pkg(5) project 5. What technical approach has been selected by the project? This is a "fill in the gaps" project. SWI projects have requirements that are not met completely by the OpenSolaris pkg(5) project such as: - portability to other OS platforms - emphasis on user (non-root) images - minimized download size - Java-based universal software (not platform dependent) This project seeks to work with the pkg(5) project to enhance the pkg(5) software where possible to meet these requirements and to provide additional software as needed. 6. How is the project delivered into the system? See FSD section 3.1. 7. Hardware Platform Dependencies: 7.1 What are the project's hardware platform dependencies, including Sun or third-party add-on hardware that is explicitly supported. See FSD section 3.1.1 7.2 Are Solaris components expected to work on SPARC and x86? If not, why? What will be affected in porting? Any problems if porting to another architecture were desirable? Yes. 7.3 Are there issues with "binary" interfaces, which would be incompatible on various instruction set architectures? No. 7.4W For Microsoft Windows components, what is the minimal hardware configuration supported (e.g., Pentium with 128mb of memory)? This isn't an issue since any hardware that runs Windows today will be able to run this software. 8. Compatibility and Interoperability See http://wikis.sun.com/display/IpsBestPractices/OS+Platform+Support for information on OS platform support. (Consider a compatibility matrix, if the information is nontrivial.) 8.1W For Microsoft Windows components, what Windows releases does it work on? Client-oriented releases (98/ME/XP/Vista)? Server releases (2000/2003)? Yes, both. 8.2W Does it depend on features and software that exist only in certain versions of Windows, such as networking features not in XP Home? No. 8.1S OS compatibility: 8.1.1 For Solaris components, what Solaris release(s) does it run on or work with? See web page referenced above. 8.1.2 Does it run on Linux? What distribution(s) and version(s)? Yes. See web page referenced above. 8.1.3 Might the project need any extra adaptation to work successfully with future (i.e., later) releases? patches? Yes. 8.2S Do Solaris components depend on OS features not in the core OS (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional loadable kernel modules)? What packages or clusters must be installed first (if the "core" set of packages is insufficient)? Do the packages express those dependencies explicitly? See the web page referenced above. 8.3 Do Solaris components use any system interfaces, commands, or features not in POSIX or the Single Unix Specification? What is the minimum version of those standards required? (POSIX.1-1990, UNIX98, UNIX2003?) Yes. Python most certainly uses interfaces not in these standards. However, this is deemed to be low risk because it already ships with Solaris. 8.4 Do Linux components use any interfaces, commands, or features not in the Linux System Base? What is the minimum LSB version required? See answer to 8.3. 8.4 With what releases of what other projects or products does this project interoperate? Using what interfaces? (Provide reference to ARC case approving these interfaces or a specification and proposed stability classification for the interfaces.) IPS - see LSARC/2008/190. IPS release numbers have not yet been solidified. The UC2 release is planning to ship with an IPS snapshot from 7/16/2008. 8.5 What internationalization (I18n) issues are involved? What languages *can* be supported by localization without modifying the base product, whether or not a localization is currently planned? What I18N interfaces will the project adhere to? If strings are used, how are they accessed -- Solaris-mostly gettext(), X/Open catgets(), GNU gettext? What items and interfaces are (or are not) being internationalized? I18n of python IPS is out of scope for this project. The Java API for IPS support i18n, but no l10n has been done for this. 8.6 Are there any existing or proposed standards it conforms to or deviates from? Examples: SPARC/x86 ABI, POSIX, Open Group standards, IETF RFCs, national or international standards. Include version numbers where applicable. No. 8.7 Can this version co-exist or interoperate with earlier and later versions? with alternative implementations (perhaps by other vendors)? Is switching between installed versions or implementations possible? What is involved? Yes, through the use of multiple user images. 8.8 Does the project move, disable, delete, circumvent or change any files, components, or services outside the project? No. 8.9 Does it use any interfaces (for example, a driver using kernel structures) that are private to another consolidation? read or write /dev/kmem? trap directly into the kernel, instead of via libc functions? Yes. This project accesses meta data from the IPS project that is private to that project. 8.10 What components (e.g., libraries or packages) are shared with other projects or products? See the interface table. 8.11 Can customization (e.g., OEM relabeling) be accomplished via resource files that are separable from the source code? N/A 8.12 Device Drivers: 8.12.1 Does this project deliver any device drivers? No 8.12.2 Does it conform to the Solaris DDI/DKI (manual sections 9e, 9f, & 9s)? 8.12.3 Does it pass "DDICT" DDI compliance tool (available on Solaris DDK)? 9. Technical Content 9.1 Architecture Diagram: Include in case materials an Architecture Diagram, showing the major components, major interfaces, and all customer-visible interfaces and inter-project interfaces. Give each a number or brief name for use in the Interface Table below. See FSD section 2.1. 9.2 Interface Table: Include Imported and Exported Interface Tables showing all customer-visible interfaces and inter-project interfaces and significant internal interfaces (inter-subsystem and inter-invocation). Interfaces are not just function calls. Include user interfaces (graphical, browser based, character based), configuration files, XML DTD's, database schemas, network protocols, port numbers, etc. See FSD section 2.2 9.3 Identify names and contents of packages, directories, libraries, databases, etc. Identify package abbreviations (SUNWxxx) and contents figuratively ("configuration command line utilities"). See FSD section 3.1.2. Also see the umbrella case LSARC/2008/411 (one-pager section 4.10.1). Also the file lists in the manifests (see question 9.4). 9.4 Package manifest: The package manifests are included in the case materials in the following files: manifests/python2.4-minimal.manifest. manifests/pkg.manifest. manifests/pkg-java.manifest (this package is platform independent) 10. The operational environment: 10.1 Command line or calling syntax: What options/operands are supported? See manual pages referenced in interface table. 10.1S Do they conform to PSARC/1999/645 command syntax guidelines, an extension of the Single Unix Specifications rules? Are any of the "CLIP" extensions to the SUS guidelines used? yes 10.1.1 Is there support for standard forms, e.g. X11(5) manpage's "-display", etc.? If not, why not? n/a 10.1.2 Are these options propagated to sub-environments? n/a 10.2 Can it be included in a shell pipeline? How does it use standard input, output and error? yes 10.3 Environment Variables: 10.3.1 What environment variables are used? Describe values and semantics. See manual pages. 10.3.2 What is the default behavior if the environment variable is not set? See manual pages. 10.3.3 What environment variables are set? See manual pages. 10.4 For Solaris, Linux, or other Unix programs, what are their exit status values? What nonzero status values have what meanings? See manual pages. 10.5W What inter-component Windows messages are sent or intercepted? None. 10.5S Signals issued? Signals caught? (See "man signal".) What are their semantics? See IPS ARC case (LSARC/2008/190). 10.6 Device drivers directly used (e.g. /dev/audio)? None. 10.7W SYSTEM.INI, WIN.INI or other resource/configuration files or databases? Describe any files used between invocations. The bootstrap scrips read the Windows registry for proxy information. 10.7S .rc/defaults files, Java properties, GNOME GConf keys or other resource/configuration files or databases? Describe any files used between invocations. None. 10.8 Does it use any "hidden" files (filename begins with "."), system files, or temporary files? Yes (.org.opensolaris,pkg - IPS image metadata) 10.9 Does it use any locking files? Does it use Solaris locking facilities? No 10.10 Can it execute remotely? In a distributed fashion? Is the user aware that the tool is executing remotely? IPS is inherently a client/server system. 10.11W For each Windows component (EXE, DLL or VxD) identify the name of the component and module identifier (EXE/DLL) or VxD ID (VxD)? If a module provides a plug-compatible replacement for a standard system component, identify the component and its version. Indicate whether VxD IDs are officially registered. python.exe pythonw.exe 10.11S Solaris/Linux/Unix Libraries If you have code, include output from both "dump -Lv" and "ldd"; but note that the ARC wants to know what the project will deliver, regardless of what developers currently have. /home/trm/ws/uc2/project/build/dist/sunos-i386/pkg/python2.4-minimal/bin/python: **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED libresolv.so.2 [2] NEEDED libsocket.so.1 [3] NEEDED libnsl.so.1 [4] NEEDED librt.so.1 [5] NEEDED libdl.so.1 [6] NEEDED libpthread.so.1 [7] NEEDED libm.so.1 [8] NEEDED libc.so.1 [9] INIT 0x80f36dc [10] FINI 0x80f36f8 [11] RUNPATH $ORIGIN:$ORIGIN/../lib [12] RPATH $ORIGIN:$ORIGIN/../lib [13] HASH 0x8050118 [14] STRTAB 0x8056a54 [15] STRSZ 0x4adb [16] SYMTAB 0x8052434 [17] SYMENT 0x10 [18] CHECKSUM 0xa51c [19] VERNEED 0x805b530 [20] VERNEEDNUM 0x5 [21] PLTSZ 0x668 [22] PLTREL 0x11 [23] JMPREL 0x805b600 [24] REL 0x805b5e0 [25] RELSZ 0x688 [26] RELENT 0x8 [27] DEBUG 0 [28] FEATURE_1 PARINIT [29] SUNW_CAP 0x8050108 [30] FLAGS ORIGIN [31] FLAGS_1 [ ORIGIN ] [32] PLTGOT 0x810f11c 10.11.1 What dynamic (aka "shared") libraries does it use directly or indirectly, including via dlopen/dlsym(3x)? See above. The IPS code also bring in libelf dynamically. 10.11.2 With what -R options will executables be built? $ORIGIN:$ORIGIN/../lib 10.11.3 Does it use any static libraries? No. 10.11.4 What libraries does your project export? None. 10.12 Does your project use or ship database or persistent storage software? If not, skip the rest of this section. Yes. 10.12.1 What software does it use? The database software that is included with Python. 10.12.2 Does it meet the SAC Policy on using standard databases? (see the Database Policy at http://sac.eng.sun.com/cgi-bin/bp.cgi?NAME=dbpolicy.bp ) If NO, please provide the reason: [ ] does not meet technical requirements (please specify) [ ] product already shipping with non-compliant technology [ ] customer requires we use a specific database [X ] other (please describe) See IPS ARC case (LSARC/2008/190). 10.12.3 Is the database technology available for customer use? No 10.12.4 Does the customer have to explicitly manage/administer the technology? No 10.13 Does the project depend on particular versions of supporting software (especially Java virtual machines)? If so, do you deliver a copy? What happens if a conflicting or incompatible version is already or subsequently installed on the system? The Java API for IPS depends on Java SE 5 or later. We do not deliver a copy. 11. System Administration Interfaces: 11.1 How will the project's deliverables be installed? Using IPS or via delivery of a pre-installed image. 11.2 How will the project's deliverables be uninstalled? Using IPS or via an uninstaller or file system remove. 11.3 How will the project's deliverables be configured and reconfigured? The pkg CLI includes configuration subcommands. 11.4 Does it need installation within any global system tables? Does your package edit existing files in a common directory (/etc/vfstab for example)? If so, how do you remove your edits when your package is removed? If your package is reinstalled over itself, does it recognize that the edits are already there or does it make all new entries? No. What Microsoft Windows registry entries are created or modified? None. 11.5 Does your package use components of other unbundled packages? If so, how do you find those packages? No. 11.6 Can your product be installed to an alternate filesystem (using "pkgadd -R") for use with diskless/auto clients or live upgrade? N/A - this software doesn't involve the use of pkgadd. The software is fully relocatable. 11.7 Can your product be installed anywhere on the target system and still function (is it relocatable)? (BASEDIR) Yes. 11.7.1 Has your project changed or introduced any package procedural scripts (postinstall, preremove, etc)? N/A. If YES, are these scripts well-behaved with respect to alternate roots? That is, when these packages are added or removed using -R, do they cause any changes to be made to /? The correct answers are either "No" or "Yes, Yes, and No". 11.8 Even relocatable packages may have one or two elements that *must* go in a certain place (/etc files for example). Are these "absolute" elements in the pkgmap or are they being installed with a postinstall script? If installed with a postinstall, how does the administrator check their integrity (how does pkgchk know about them)? N/A. 11.9 How does a new version of your package upgrade a prior version? This is done via the IPS package update capability. 11.10 Does your package replace a filesystem object delivered by a prior package? If so, how do you inform the other package that it doesn't own this file anymore? How do you return the original package to its original state if your package is pkgrm'd? No 11.11 Have you grouped generic functionalities that may be used by other projects into their own packages (KLG widgets, a third-party set of device drivers)? If not how do other projects know this generic functionality is installed? Are you using existing classes and libraries as far as possible? Yes. 11.12 How is it started? The software delivered in this project is started manually. However, other UC2 components, such as the updatetool notifier are started automatically. The IPS project delivers a pkg-server.xml file that is used for creating an SMF server for pkg.depotd. This file is not currently delivered by the UC2 toolkit (see UC2 issue 525). 11.13 Does it use a naming service such as NIS, DNS, LDAP? Directly, or through the name service switch? Indirectly via Java APIs. 11.14 What are its on-going maintenance requirements (e.g. keeping global tables up to date, trimming files)? None. 11.15 Can administration be done from a remote machine? How? Yes, via remote login. 11.16 Can all GUI administration also be performed without the GUI? How? No GUIs are defined by this project. 11.17 What command or scripting language is used? The implementation uses sh, BAT, python. 11.18 Does the project include runtime license checking? Why? How is it accomplished? How does it cope with changes of the underlying system due to hardware replacement or virtualization? No. 11.19 Are there any restrictions or other architectural effects from contractual obligations, copyright restrictions, technology royalty structure, or open source license requirements? No. 12. The Window System/Desktop Operational Environment: 12.0 Does the project include a GUI (Graphical User Interface)? If not, say "NONE" and remove all this section's subsections. NONE. 13. Brainstorming Interfaces (exported and imported): Include in your Interface Table any of the following that apply. You may comment on them here, if you wish. See section 2.2 of the FSD. 13.1 Exported Library APIs and ABIs exposed to customers 13.1.1 The name of the library 13.1.2 The installation location for the library 13.1.3 The prefix(es) reserved for use by the library and its header files. 13.1.4 The syntax and semantics of every symbol exported by the library. 13.1.5 Compile time symbols (#defines or #ifdefs) defined by the project? 13.1.6 Are there any library or headerfile symbols that don't start with one of those prefixes? 13.2 Protocols (public or private, including RPCs) 13.3 Drag and Drop: what objects and what are the semantics? 13.4 GNOME ORB (bonobo) remote calls, Web service calls (SOAP, etc.), ToolTalk messages? 13.5 Files used as an interface, e.g. Resources, config files, etc. 13.6 Significant file formats, names, syntax, and semantics? Is there an /etc/magic entry for any new file format? What will file(1) say? 13.7 Interfaces to applications it interoperates or communicates with? (Perhaps pipes, shared memory.) 13.8 Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? 13.9 Other External Interfaces? 13.10 Brainstorming Significant Internal Interfaces 13.11 Protocols (public or private) 13.12 Private ORB, RPC, SOAP, RMI, etc. transactions 13.13 Files and their Formats 13.14 Do any internal interfaces save state across invocations? 13.15 Other Internal Interfaces? 14. Questions for Every Interface: These questions should be asked for every one of the project's interfaces; the answers are therefore often listed in Section 9.2 (Don't repeat.) Only the interesting answers are normally discussed. 14.1 Propose the stability/commitment classification of the interface -- Committed (formerly Public, Stable or Standard), Uncommitted (formerly Unstable), Volatile, Project Private, etc. -- per the SAC Interface Taxonomy document at http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp 14.2 Who controls the interface (i.e., could make changes to it)? Point out any interfaces not solely controlled by Sun. 14.3 Interface Specification: 14.3.1 Where is the interface specified (documented)? 14.3.2 Is the specification complete enough for a re-implementation? 14.3.3 Will the project deliver to customers documentation for the interface? 14.3.4 Are the interfaces documented clearly enough for a non-Sun client to use them successfully? 14.4 Interface Versioning and Projected Evolution 14.4.1 Present Change: if any interface is an update to or replacement for a previous one, what was the stability classification of the previous version? Is this backwards-compatible? Describe any migration story to mitigate the conversion. 14.4.2 Future Evolution: Even if an interface is new, it should be prepared for evolution. How will a transition to a new version to be accomplished? What are the expected consequences to ISVs and users and administrators? What provisions are made now to minimize or manage the pain (to clients) of future evolution? 14.4.3 For Microsoft Windows components that install on top of an existing product (such as PC-X on top of PC-NFSpro): are there common files that should only be upgraded if the files being installed have a new version? 15. Performance and Scalability: 15.1 What are the performance goals of the project? How were they evaluated (or how will they be)? On what type of test platform? How will performance regressions be identified? See the umbrella case (LSARC/2008/411) and the IPS case (PSARC/2008/190) 15.2 Are there any limits to scalability, such as a fixed-size array forcing a maximum number of clients, users, simultaneous connections, etc.? Are any data structures (e.g., kernel structures) so huge that large numbers of them are impractical? One of the limitations of the Java API is that it has not been optimized to perform well with thousands of packages. There are some O(n^2) algorithms. This problem has already been corrected in the Python code, so those solutions can be ported to Java. 15.3 Resource Consumption: 15.3.1 Attempt to describe resource consumption scaling, even crudely. For example, if each client consumes 1MB of memory, you could say: Memory_required = 1MB * Nclients 15.3.2 Which resources are likely to be bottlenecks? Memory, disk access speed, CPU time. 15.4 Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? N/A 15.5 Multi-threading: What is your project's MT model? What must an MT client do to use your interface(s) safely? How does your project use threads internally? How does it expect its client to use threads? If it uses call-backs, can the called entity create a thread and recursively call back? Is it prepared for multi-thread & multi-core systems like Niagara and Opteron? See the IPS case (PSARC/2008/190) for information on IPS client API MT. There is currently no provision in the IPS code for dealing with multi-thread access to installation images (no synchronization). See IPS issue 1668. Because of this lack of locking at the file system level, the Java API also suffers from the same problem. 15.6 What is the impact on system performance (positive or negative)? These components do not have a significant impact on overall system performance. 15.6.1 What is the average memory usage or working set of this component? 15.6.2W How much of this is locked down? 15.6.3W What system resources are consumed by each component under Windows? 15.6.2S How much of this is shared/sharable by other apps? 15.7 Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? No. 15.8 Will it require large files/databases (for example, new fonts)? See the IPS case (PSARC/2008/190) 15.9 Do files/databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? See the IPS case (PSARC/2008/190) 15.10 What are the project's effects on boot time requirements? See the IPS case (PSARC/2008/190) 16. Security: Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. A separate Security Questionnaire http://sac.eng.sun.com/cgi-bin/bp.cgi?NAME=Security.bp is provided for more detailed guidance on the necessary information. Cases are encouraged to fill out and include the Security questionnaire (leveraging references to existing documentation) in the case materials. See the IPS case (PSARC/2008/190) 16.1 What security issues do you address in your project? The only security-related aspect of this project over and above that of the IPS project itself is that this project provides the OpenSSL implementation in the minimized python distribution. 16.2 What security concerns might customers or reviewers have? Unknown. 16.3 Are any components (e.g., encryption) subject to export restrictions? Why or why not? OpenSSL. 16.4 How are particularly security-critical data like passwords treated? This project does not deal with any security-critical data. 17. Availability and Serviceability See the IPS case (PSARC/2008/190). This project does not provide anything to either degrade or improve availablility and serviceability except for the points mentioned below. 17.1 How will it respond to failures? (Does it ever require reboot? Can it lock up? Is there a way for the user to "unstick it"?) 17.2 How does your project deal with network failures (including partition and re-integration)? 17.3 Can it save and restore state? Is any special action required if the filesystem is rolled-back to previous state (such as via ZFS or other filesystem snapshot technologies)? 17.4 Can it checkpoint and recover? Can its files be corrupted by failures? Does it clean up any locks/files after crashes? 17.5 Will it participate in the Solaris Fault Management Architecture (http://fma.eng.sun.com/)? 17.6 Can the project's deliverables be patched and upgraded without requiring a reboot? Without a noticeable service interruption? The Windows related changes to IPS provide for upgrading files that have executable locks by moving the existing file aside and then deleting it later. Also, files that are locked and cannot be modified are detected before an update and the updated is terminated. 17.7 How will patches be installed? 18. Adaptability to a Changing World: 18.1 Any plans for supporting operating systems other than Solaris (Linux, Microsoft Windows, MacOS X, AIX, HP/UX, etc.)? Yes. That is one of the main points of this project. 18.2 How does it deal with issues in the 64-bit world, including 64-bit address spaces, 64-bit integers, and 64-bit files? Java and Python handle this transparently. 18.3 How will the project provide services to other projects? 18.3.1 Current or planned usage of CORBA IDL, IIOP, and an ORB? If an ORB, hich one (Bonobo, Java IDL, ...)? None. 18.3.2 Current or planned Java Beans, especially J2EE? None. 18.3.3 Current or planned Web Services interfaces (SOAP, etc.?) The IPS server interface is REST-based. 18.4 What is its relationship (or difficulties) with . . . 18.4.1 the Internet? Web Services? 18.4.2 Java? J2EE? Application Servers? The Java API for IPS is intended to be used within Java application servers. 18.4.3 "Network of Things" (thin clients, portable devices, cell phones, wireless networking, kitchen appliances with IP addresses?) 18.4.4 Multimedia? 18.4.5 Networked storage (SANs, NAS) 18.4.5 Infiniband? 18.4.6 Network identity services? 18.4.7 Virtualized environments (Xen, Zones, VMWare)? 19. Issues? Please identify the issues for which you would like ARC guidance. (e.g. Interface classification, deviations from standards, architectural conflicts, release constraints...) No Any issues outstanding from previous reviews (or the case's mail archive)? No 20. Appendices and References 20.1 Interface Tables, Package Manifests, etc See FSD. 20.2 References to other documents (one-pager, design papers, interface contracts, etc.). Copies are to be placed in the case directory. 20.3 Comments For Us? 20.3.1 How many engineer hours went into preparation of case materials, including answering this questionnaire (that would not otherwise have been needed for other purposes)? 5 20.3.2 Do you think it was time well spent? 20.3.3 How many engineer hours went into answering this questionnaire alone? 3. 20.3.4 Comments on this questionnaire should be mailed to lsarc-chair@sac.eng.sun.com. 20.3.5 Comments on your case owner, the review process, or the experience may be placed here if they're not too personal, may be mailed to the chair or arc-chairs@sac, or may be expressed to John Plocher (x87604), or your divisional CTO.