From sacadmin Mon Jul 30 11:47:32 2007 Received: from stickit.sfbay.sun.com (stickit [129.146.226.107]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l6UIlW6q002726 for ; Mon, 30 Jul 2007 11:47:32 -0700 (PDT) Received: from stickit (stickit [129.146.226.107]) by stickit.sfbay.sun.com (8.13.3+Sun/8.13.1) with SMTP id l6UIWa3L004130; Mon, 30 Jul 2007 11:32:36 -0700 (PDT) Message-Id: <200707301832.l6UIWa3L004130@stickit.sfbay.sun.com> Date: Mon, 30 Jul 2007 11:32:36 -0700 (PDT) From: John Danielson Reply-To: John Danielson Subject: Contract DKC_VBD to Solaris Install [PSARC/2007/437 FastTrack timeout 08/06/2007] To: psarc@sac.eng Cc: matrix-eng@sun.com MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Herd_of_Zebra_916_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 6414 --Herd_of_Zebra_916_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NpO7MeTWFBeOeE06/tsM4g== I am sponsoring the following fast-track to establish a contract on the use of the DKC_VBD disk controller type by the Solaris Install consolidation. Consistent with original case, we are seeking a patch binding. The timeout for this case is set to expire on 08/06/2007. The interface being contracted is the DKC_VBD disk controller type delivered via by the xVM project. The Solaris install software checks the type of the disk controller to determine what is required (and not required) to initialize disk devices. When install encounters disks of this type, it skips writing the master boot record to the disk and initializing the alternate sector lists. The contract is attached to this e-mail and has been delivered into the case directory as PSARC/2007/437-01 ----- - john --Herd_of_Zebra_916_000 Content-Type: TEXT/plain; name=contract-437-01; charset=us-ascii; x-unix-mode=0644 Content-Description: contract-437-01 Content-MD5: flcGnkJfrf7OHru+FRk24w== @(#)contract 1.8 @(#) /shared/sac/arc/ARC-Templates/contract [1.8 06/12/06] [This is a template for the Contract associated with Contracted interfaces (i.e. Contracted Consolidation Private, Contracted Project Private, etc). It must be tailored for each use, and be approved as part of the case approving the interfaces. Remove the explanatory text in square brackets before using this template. This is NOT a legal contract; it is simply a mechanism used to specify the details of an unusual dependency between two components that is not allowed under the normal rules set forth in the interface taxonomy.] CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2007/437-01 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris Consolidation: ON Department or Group: Solaris Kernel Bugster Product/Category/SubCategory: kernel/xen Responsible Manager: Jerri-Ann Meyer 3. The CONSUMER is identified by the following: Product or Bundle: Solaris Consolidation: Install Department or Group: Solaris Install Bugster Product/Category/SubCategory: sysadmin/install Responsible Manager: Eric Ray 4. The INTERFACES are: sys/dkio.h:DKC_VBD Unstable 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing (Exporting) these INTERFACES is: PSARC/2006/260 Solaris on Xen 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the stability levels listed in section 4 above: _Y_ 7a. Although the stability level doesn't normally restrict it, SUPPLIER promises to only modify INTERFACES in an incompatible way as follows: Upon mutual agreemenmt _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will expose INTERFACES to a PARTNER, which is external to Sun, namely: Name of Company: Name of Department or Group within Company: Responsible Manager: _N_ 7c. Although the stability level doesn't normally allow it, CONSUMER will import INTERFACES from a separate consolidation. _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any portion of the INTERFACES, SUPPLIER will notify CONSUMER of the proposed new version, no later than the application for ARC approval of the new version. If SUPPLIER and CONSUMER are contained in the same consolidation, they have the option of arranging for simultaneous conversion to the new interfaces. If this is not possible, or if they are not in the same consolidation, then SUPPLIER will either make best effort to work with CONSUMER so that CONSUMER can detect which version of INTERFACES is being supplied, or else SUPPLIER will make best effort to supply both old and new versions of INTERFACES. If SUPPLIER cannot make both versions of INTERFACES available, and SUPPLIER and CONSUMER cannot devise a method whereby CONSUMER can detect which version of INTERFACES is being supplied, and the old version of CONSUMER will not run with the new version of SUPPLIER, then either the EOL process must be followed by SUPPLIER, or else a major release of SUPPLIER will be required, or the change will not be allowed. 8. If CONSUMER requires changes in INTERFACES, SUPPLIER will make best effort to accommodate such changes, which shall then be treated in accordance with paragraph 7 above. 9. Notwithstanding paragraphs 7 and 8, a change to any portion of the INTERFACES shall be regarded as a completely new set of INTERFACES which require both ARC approval and execution of a new contract. 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: SUPPLIER will inform CONSUMER prior to making changes. 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: SUPPLIER will continue to support INTERFACES or modify the consumer code in the same WOS build. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: As documented in the PSARC case directory. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: The INTERFACES are tested regularly as part of Solaris installation. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: CONSUMER no longer needs interfaces. OR SUPPLIER replaces interfaces and CONSUMER adapts to the new interfaces. 15. This contract is not valid until "signed" via agreement from the SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by this contract. E-mail agreement to the contract should be archived in the mail archive of CASE; verbal agreement to the contract should be noted in the meeting minutes. This contract remains valid until superseded or invalidated. For SUPPLIER: Jerri-Ann Meyer Date: 7/30/2007 For CONSUMER: Eric Ray Date: 7/30/2007 For ARC: John Danielson Date: 7/30/2007 16. (Not to be filled in until superseded or invalidated.) This contract was superseded or invalidated by CASE: For ARC: Date: --Herd_of_Zebra_916_000-- From sacadmin Tue Jul 31 12:48:22 2007 Received: from marduk.eng.sun.com (marduk [129.146.108.224]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l6VJmMZ1001366 for ; Tue, 31 Jul 2007 12:48:22 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l6VJnvIt015703; Tue, 31 Jul 2007 12:49:57 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l6VJnuTO015702; Tue, 31 Jul 2007 12:49:56 -0700 (PDT) Date: Tue, 31 Jul 2007 12:49:56 -0700 (PDT) From: Gary Winiger Message-Id: <200707311949.l6VJnuTO015702@marduk.eng.sun.com> To: jhd@stickit.sfbay.sun.com, psarc@sac.sfbay.sun.com Cc: matrix-eng@sun.com Subject: Re: Contract DKC_VBD to Solaris Install [PSARC/2007/437 FastTrack timeout 08/06/2007] Status: RO Content-Length: 481 > 2. The SUPPLIER (definer and/or implementor) is identified by the following: > Bugster Product/Category/SubCategory: kernel/xen ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 3. The CONSUMER is identified by the following: > Bugster Product/Category/SubCategory: sysadmin/install ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Please update the contract to include the Bugster Product. (It's now part of the specification, so it's possible to actually track down new RM's :-0 Gary..