From sacadmin Thu Feb 21 11:55:08 2008 Received: from gilia.eng.sun.com (gilia [129.146.226.101]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LJt84L025053; Thu, 21 Feb 2008 11:55:08 -0800 (PST) Received: from gilia.eng.sun.com (localhost [127.0.0.1]) by gilia.eng.sun.com (8.14.1+Sun/8.14.1) with ESMTP id m1LJsOAZ015036; Thu, 21 Feb 2008 11:54:25 -0800 (PST) Received: (from wendyp@localhost) by gilia.eng.sun.com (8.14.1+Sun/8.14.1/Submit) id m1LJsKRe015032; Thu, 21 Feb 2008 11:54:20 -0800 (PST) Date: Thu, 21 Feb 2008 11:54:20 -0800 (PST) From: Wendy Phillips Message-Id: <200802211954.m1LJsKRe015032@gilia.eng.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: Norm.Jacobs@sun.com, Wendy.Phillips@sun.com Subject: CUPS 1.3.6 [PSARC/2008/130 FastTrack timeout 02/29/2008] Status: RO Content-Length: 13842 I am sponsoring this fast track for Norm Jacobs. I have set the timer for 02/29/08. The requested release binding is patch/micro. The proposal, a complete enumeration of the interfaces and man pages may be found in the case directory. -Wendy While we do not currently plan to backport this, we are requesting patch/micro release binding in the event that management requests this of us. Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: CUPS 1.3.6 1.2. Name of Document Author/Supplier: Author: Norm Jacobs 1.3. Date of This Document: 02/11/2007 4. Technical Description Summary This project creates a mechanism that allows delivery of and selection between more than one print system on Solaris. This project integrates CUPS 1.3.6 into Solaris This project seeks micro/patch binding. Details CUPS The open source operating system world has begun a fairly rapid convergence on CUPS as the default print service. In the last couple of years, CUPS has become the default print service on virtually all Linux distributions, *BSD distributions, and MacOS/X. This convergence fuels and has been fueled by wide adoption of CUPS APIs in desktop applications and toolkits. Additionally, it's imaging format and printer driver interfaces have been recently adopted by a number of printer vendors and 3rd party printer driver projects for supporting non Microsoft platforms. At it's core CUPS contains a scheduler that uses the Internet Print Protocol (IPP) as it's means of communicating with client applications and/or systems. IPP allows for, but does not require, authentication of the requester and encryption during transport. It also provides an expanded set of standard operations and attributes allowing a rich set capability and data when operating with other IPP based print services like those in the more recent Windows platforms. As mentioned previously, CUPS includes application level interfaces that have been rapidly adopted by many key open source applications and toolkits. These interfaces can be broken down into "convenience" calls for applications with very limited need from the print service, "ppd" calls for processing and interpreting PPD file data representing printer capabilities, and "lower-level" calls for applications with more specialized needs from the print service like asynchronous operation. The CUPS community has stated that they intend on maintaining backward compatibility in minor relases moving forward for the libcups interfaces. As a result of this and requests from 3rd parties, the Linux Foundation has begun to integrate portions of the "convenience" and "ppd" calls into LSB 3.2 and expect to include more of these interfaces in subsequent versions of the LSB. On the back-end, CUPS includes interfaces to process it's own annotated raster image format. Support for this format and these interfaces is integrated into GhostScript and other key open source print driver technology. Additionally, several printer vendors either support or have begun to use these interfaces to support their printers on open source platforms. Like the application interfaces, the CUPS community intends to maintain backward compatibility and these interfaces are included in the LSB 3.2. Additionally, CUPS supplies assorted APIs and other interfaces for integration of filtering, communication, and notification support. Finally, CUPS includes an RFC1179 (LPD protocol) listening service, printer (device) enumeration support, print queue advertisement and discovery support, and a web-based management interface. CUPS/LP Solaris's LP based print service supplies something similar to the CUPS interfaces and capabilities, however much of the LP based support is not as complete and not as widely adopted or integrated with other open source technologies. While CUPS supplies some features and interfaces lacking in the LP based print service on Solaris at this time, CUPS lacks some features and support in Solaris that would make it suitable as the only choice of print service on Solaris. At a higher level, it is lacking integration with facilities like RBAC, NIS/NIS+ naming, and support for trusted printing. It is also lacking support for some of the LP based features like pre-printed media (forms). As a result of this, in the short-term, we intend on retaining the current LP based print service and also integrating CUPS into Solaris allowing customers to choose the service that best suits their needs. Ultimately, we intend on working with the CUPS community to make better use of Solaris features and enhance it to include support it lacks so that we can simply replace the LP based print service. Multiple Services We intend on introducing a new interface print-service(1m) to allow customers to choose their active print system. This interface will provide five functions. * Allow setting of the active print service, optionally migrating basic print queue configuration from the old service to the new service. * Report the active print service. * Export basic print queue configuration from the active print service. * Import basic print queue configuration into the active print service. * When called under another name, redirect to the named command under the active print service. Initially, the default "active" service will be "lp". Once users gain more of an opportunity to become familiar with it and it has evolved to better support our users, CUPS will be made the default service. We will be re-evaluating this in 6 months. Because the current LP based service includes IPP and RFC1179 listening services, the corresponding CUPS based service will be marked as incompatible in their smf(5) service definitions. A more complete enumeration of interfaces follows in the interfaces section of this proposal, as well as in the cups-interfaces.txt attachment. Additionally, draft man pages for libcups(3), libcupsimage(3), and print-service(1m) are bundled with the proposal. Since cups makes use of OpenSSL, I am in the process of requesting a contract to use those interfaces. Interfaces Exported Interfaces Interface Classification Comment --------- -------------- ------- svc:/application/cups/scheduler Committed core CUPS scheduler service svc:/application/cups/in-lpd Committed rfc-1179 listener service solaris.smf.manage.cups Committed service management authorizations solaris.smf.value.cups Committed service management authorizations tcp/631 Committed IPP service tcp/515 Committed RFC-1179 service udp/631 Committed CUPS browse protocol SUNWpcu Packaging /usr/bin/cancel=../sbin/print-service Committed PSARC 1993/348 /usr/bin/lp=../sbin/print-service Committed PSARC 1993/348 /usr/bin/lpq=../sbin/print-service Committed PSARC 1993/348 /usr/bin/lpr=../sbin/print-service Committed PSARC 1993/348 /usr/bin/lprm=../sbin/print-service Committed PSARC 1993/348 /usr/bin/lpstat=../sbin/print-service Committed PSARC 1993/348 /usr/sbin/accept=./print-service Uncommitted PSARC 1993/348 /usr/sbin/disable=./print-service Uncommitted PSARC 1993/348 /usr/sbin/enable=./print-service Uncommitted PSARC 1993/348 /usr/sbin/lpadmin=./print-service Uncommitted Obsolete PSARC 1993/348 /usr/sbin/lpc=./print-service Committed PSARC 1993/348 /usr/sbin/lpmove=./print-service Uncommitted PSARC 1993/348 /usr/sbin/print-service Uncommitted Obsolete service selection and redirection /usr/sbin/reject=./print-service Uncommitted PSARC 1993/348 /usr/lib/lp/bin/lpadmin Private moved from /usr/sbin SUNWlp-cmds Packaging /usr/lib/lp/bin/cancel Private moved from /usr/bin /usr/lib/lp/bin/accept Private moved from /usr/sbin /usr/lib/lp/bin/disable Private moved from /usr/sbin /usr/lib/lp/bin/enable Private moved from /usr/sbin /usr/lib/lp/bin/lp Private moved from /usr/bin /usr/lib/lp/bin/lpstat Private moved from /usr/bin /usr/lib/lp/bin/lpmove Private moved from /usr/sbin /usr/lib/lp/bin/reject Private moved from /usr/sbin SUNWlpr-cmds Packaging /usr/lib/lp/bin/lpc Private moved from /usr/sbin /usr/lib/lp/bin/lpq Private moved from /usr/bin /usr/lib/lp/bin/lpr Private moved from /usr/bin /usr/lib/lp/bin/lprm Private moved from /usr/bin A complete enumeration of the files delivered by CUPS is included in the cups-interfaces.txt file Imported Interfaces Interface Classification Source --------- -------------- ------- libgss.so Standard PSARC 1996/059 (not defined in ARC case, but referred to by RFC) libkrb5.so External PSARC 2006/027 libssl.so External PSARC 2005/500 libcrypto.so External PSARC 2005/500 libtiff.so Evolving LSARC 2003/085 libpng12.so Evolving LSARC 2003/085 libjpeg.so Evolving LSARC 2003/085 libz.so Committed PSARC 2006/537 libslp.so Standard PSARC 1999/181 libpam.so Public PSARC 1995/269 libdns_sd.so Committed PSARC 2005/562 libdbus-1.so Volatile LSARC 2006/368 udp/161 Standard SNMP HOST-RESOURCES-MIB::hrDeviceDescr.1 Standard Host-Resource MIB device description HOST-RESOURCES-MIB::hrDeviceType.1 Standard Host-Resource MIB device type 5. Reference Documents: PSARC/1993/348 LP Committed Interfaces PSARC/1995/269 Pluggable Authentication Modules (PAM) Upgrade PSARC/1996/059 GSS-API: Generic Security Services API PSARC/1999/181 SLP API Update LSARC/2003/085 libtiff, libjpeg and libpng PSARC/2003/500 OpenSSL in /usr/sfw PSARC/2005/562 Multicast DNS and Service Discovery LSARC/2006/368 D-BUS Message Bus System PSARC/2006/027 Expose Kerberos V5 API PSARC/2006/537 zlib 1.2.3 http://cups.org/documentation.php CUPS Online Documentation 6. Resources and Schedule: 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: Open 7. Prototype Availability: 7.1. Prototype Availability: Now From wendyp@gilia.eng.sun.com Thu Feb 21 14:17:25 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LMHOXN002839 for ; Thu, 21 Feb 2008 14:17:25 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1LMHKxW000054 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 22 Feb 2008 06:17:23 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWM00M0T0KV5Y00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 21 Feb 2008 15:17:19 -0700 (MST) Received: from gilia.eng.sun.com ([129.146.226.101]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWM00KDW0KVUY10@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 21 Feb 2008 15:17:19 -0700 (MST) Received: from gilia.eng.sun.com (localhost [127.0.0.1]) by gilia.eng.sun.com (8.14.1+Sun/8.14.1) with ESMTP id m1LMGXEp015270; Thu, 21 Feb 2008 14:16:34 -0800 (PST) Received: (from wendyp@localhost) by gilia.eng.sun.com (8.14.1+Sun/8.14.1/Submit) id m1LMGV70015269; Thu, 21 Feb 2008 14:16:31 -0800 (PST) Date: Thu, 21 Feb 2008 14:16:31 -0800 (PST) From: Wendy Phillips Subject: CUPS 1.3.6 [PSARC/2008/130 FastTrack timeout 02/29/2008] To: psarc-ext@sun.com Cc: jacobs@gilia.eng.sun.com, wendyp@gilia.eng.sun.com Message-id: <200802212216.m1LMGV70015269@gilia.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 13844 I am sponsoring this fast track for Norm Jacobs. I have set the timer for 02/29/08. The requested release binding is patch/micro. The proposal, a complete enumeration of the interfaces and man pages may be found in the case directory. -Wendy While we do not currently plan to backport this, we are requesting patch/micro release binding in the event that management requests this of us. Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: CUPS 1.3.6 1.2. Name of Document Author/Supplier: Author: Norm Jacobs 1.3. Date of This Document: 02/11/2007 4. Technical Description Summary This project creates a mechanism that allows delivery of and selection between more than one print system on Solaris. This project integrates CUPS 1.3.6 into Solaris This project seeks micro/patch binding. Details CUPS The open source operating system world has begun a fairly rapid convergence on CUPS as the default print service. In the last couple of years, CUPS has become the default print service on virtually all Linux distributions, *BSD distributions, and MacOS/X. This convergence fuels and has been fueled by wide adoption of CUPS APIs in desktop applications and toolkits. Additionally, it's imaging format and printer driver interfaces have been recently adopted by a number of printer vendors and 3rd party printer driver projects for supporting non Microsoft platforms. At it's core CUPS contains a scheduler that uses the Internet Print Protocol (IPP) as it's means of communicating with client applications and/or systems. IPP allows for, but does not require, authentication of the requester and encryption during transport. It also provides an expanded set of standard operations and attributes allowing a rich set capability and data when operating with other IPP based print services like those in the more recent Windows platforms. As mentioned previously, CUPS includes application level interfaces that have been rapidly adopted by many key open source applications and toolkits. These interfaces can be broken down into "convenience" calls for applications with very limited need from the print service, "ppd" calls for processing and interpreting PPD file data representing printer capabilities, and "lower-level" calls for applications with more specialized needs from the print service like asynchronous operation. The CUPS community has stated that they intend on maintaining backward compatibility in minor relases moving forward for the libcups interfaces. As a result of this and requests from 3rd parties, the Linux Foundation has begun to integrate portions of the "convenience" and "ppd" calls into LSB 3.2 and expect to include more of these interfaces in subsequent versions of the LSB. On the back-end, CUPS includes interfaces to process it's own annotated raster image format. Support for this format and these interfaces is integrated into GhostScript and other key open source print driver technology. Additionally, several printer vendors either support or have begun to use these interfaces to support their printers on open source platforms. Like the application interfaces, the CUPS community intends to maintain backward compatibility and these interfaces are included in the LSB 3.2. Additionally, CUPS supplies assorted APIs and other interfaces for integration of filtering, communication, and notification support. Finally, CUPS includes an RFC1179 (LPD protocol) listening service, printer (device) enumeration support, print queue advertisement and discovery support, and a web-based management interface. CUPS/LP Solaris's LP based print service supplies something similar to the CUPS interfaces and capabilities, however much of the LP based support is not as complete and not as widely adopted or integrated with other open source technologies. While CUPS supplies some features and interfaces lacking in the LP based print service on Solaris at this time, CUPS lacks some features and support in Solaris that would make it suitable as the only choice of print service on Solaris. At a higher level, it is lacking integration with facilities like RBAC, NIS/NIS+ naming, and support for trusted printing. It is also lacking support for some of the LP based features like pre-printed media (forms). As a result of this, in the short-term, we intend on retaining the current LP based print service and also integrating CUPS into Solaris allowing customers to choose the service that best suits their needs. Ultimately, we intend on working with the CUPS community to make better use of Solaris features and enhance it to include support it lacks so that we can simply replace the LP based print service. Multiple Services We intend on introducing a new interface print-service(1m) to allow customers to choose their active print system. This interface will provide five functions. * Allow setting of the active print service, optionally migrating basic print queue configuration from the old service to the new service. * Report the active print service. * Export basic print queue configuration from the active print service. * Import basic print queue configuration into the active print service. * When called under another name, redirect to the named command under the active print service. Initially, the default "active" service will be "lp". Once users gain more of an opportunity to become familiar with it and it has evolved to better support our users, CUPS will be made the default service. We will be re-evaluating this in 6 months. Because the current LP based service includes IPP and RFC1179 listening services, the corresponding CUPS based service will be marked as incompatible in their smf(5) service definitions. A more complete enumeration of interfaces follows in the interfaces section of this proposal, as well as in the cups-interfaces.txt attachment. Additionally, draft man pages for libcups(3), libcupsimage(3), and print-service(1m) are bundled with the proposal. Since cups makes use of OpenSSL, I am in the process of requesting a contract to use those interfaces. Interfaces Exported Interfaces Interface Classification Comment --------- -------------- ------- svc:/application/cups/scheduler Committed core CUPS scheduler service svc:/application/cups/in-lpd Committed rfc-1179 listener service solaris.smf.manage.cups Committed service management authorizations solaris.smf.value.cups Committed service management authorizations tcp/631 Committed IPP service tcp/515 Committed RFC-1179 service udp/631 Committed CUPS browse protocol SUNWpcu Packaging /usr/bin/cancel=../sbin/print-service Committed PSARC 1993/348 /usr/bin/lp=../sbin/print-service Committed PSARC 1993/348 /usr/bin/lpq=../sbin/print-service Committed PSARC 1993/348 /usr/bin/lpr=../sbin/print-service Committed PSARC 1993/348 /usr/bin/lprm=../sbin/print-service Committed PSARC 1993/348 /usr/bin/lpstat=../sbin/print-service Committed PSARC 1993/348 /usr/sbin/accept=./print-service Uncommitted PSARC 1993/348 /usr/sbin/disable=./print-service Uncommitted PSARC 1993/348 /usr/sbin/enable=./print-service Uncommitted PSARC 1993/348 /usr/sbin/lpadmin=./print-service Uncommitted Obsolete PSARC 1993/348 /usr/sbin/lpc=./print-service Committed PSARC 1993/348 /usr/sbin/lpmove=./print-service Uncommitted PSARC 1993/348 /usr/sbin/print-service Uncommitted Obsolete service selection and redirection /usr/sbin/reject=./print-service Uncommitted PSARC 1993/348 /usr/lib/lp/bin/lpadmin Private moved from /usr/sbin SUNWlp-cmds Packaging /usr/lib/lp/bin/cancel Private moved from /usr/bin /usr/lib/lp/bin/accept Private moved from /usr/sbin /usr/lib/lp/bin/disable Private moved from /usr/sbin /usr/lib/lp/bin/enable Private moved from /usr/sbin /usr/lib/lp/bin/lp Private moved from /usr/bin /usr/lib/lp/bin/lpstat Private moved from /usr/bin /usr/lib/lp/bin/lpmove Private moved from /usr/sbin /usr/lib/lp/bin/reject Private moved from /usr/sbin SUNWlpr-cmds Packaging /usr/lib/lp/bin/lpc Private moved from /usr/sbin /usr/lib/lp/bin/lpq Private moved from /usr/bin /usr/lib/lp/bin/lpr Private moved from /usr/bin /usr/lib/lp/bin/lprm Private moved from /usr/bin A complete enumeration of the files delivered by CUPS is included in the cups-interfaces.txt file Imported Interfaces Interface Classification Source --------- -------------- ------- libgss.so Standard PSARC 1996/059 (not defined in ARC case, but referred to by RFC) libkrb5.so External PSARC 2006/027 libssl.so External PSARC 2005/500 libcrypto.so External PSARC 2005/500 libtiff.so Evolving LSARC 2003/085 libpng12.so Evolving LSARC 2003/085 libjpeg.so Evolving LSARC 2003/085 libz.so Committed PSARC 2006/537 libslp.so Standard PSARC 1999/181 libpam.so Public PSARC 1995/269 libdns_sd.so Committed PSARC 2005/562 libdbus-1.so Volatile LSARC 2006/368 udp/161 Standard SNMP HOST-RESOURCES-MIB::hrDeviceDescr.1 Standard Host-Resource MIB device description HOST-RESOURCES-MIB::hrDeviceType.1 Standard Host-Resource MIB device type 5. Reference Documents: PSARC/1993/348 LP Committed Interfaces PSARC/1995/269 Pluggable Authentication Modules (PAM) Upgrade PSARC/1996/059 GSS-API: Generic Security Services API PSARC/1999/181 SLP API Update LSARC/2003/085 libtiff, libjpeg and libpng PSARC/2003/500 OpenSSL in /usr/sfw PSARC/2005/562 Multicast DNS and Service Discovery LSARC/2006/368 D-BUS Message Bus System PSARC/2006/027 Expose Kerberos V5 API PSARC/2006/537 zlib 1.2.3 http://cups.org/documentation.php CUPS Online Documentation 6. Resources and Schedule: 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: Open 7. Prototype Availability: 7.1. Prototype Availability: Now From wendyp@dalea.eng.sun.com Fri Feb 29 15:26:29 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1TNQSIa004563 for ; Fri, 29 Feb 2008 15:26:29 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1TNQKnj017939 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Sat, 1 Mar 2008 07:26:27 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JX000A0ZX43IS00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Feb 2008 16:26:27 -0700 (MST) Received: from dalea.Eng.Sun.COM ([129.146.226.137]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JX000A0GX42IN00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 29 Feb 2008 16:26:26 -0700 (MST) Received: from dalea.Eng.Sun.COM (localhost [127.0.0.1]) by dalea.Eng.Sun.COM (8.14.2+Sun/8.14.2) with ESMTP id m1TNQKHv003942; Fri, 29 Feb 2008 15:26:20 -0800 (PST) Received: (from wendyp@localhost) by dalea.Eng.Sun.COM (8.14.2+Sun/8.14.2/Submit) id m1TNQHEp003939; Fri, 29 Feb 2008 15:26:17 -0800 (PST) Date: Fri, 29 Feb 2008 15:26:17 -0800 (PST) From: Wendy Phillips Subject: PSARC/2008/130 - CUPS 1.3.6 To: psarc-ext@sun.com, wendyp@dalea.eng.sun.com Cc: jacobs@dalea.eng.sun.com Message-id: <200802292326.m1TNQHEp003939@dalea.Eng.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 45 This case has been closed approved. -Wendy From Norm.Jacobs@sun.com Tue Mar 18 14:56:36 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2ILuZml021268 for ; Tue, 18 Mar 2008 14:56:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2ILuZDS022989; Tue, 18 Mar 2008 14:56:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXY00F0N4YATC00@nwk-avmta-2.sfbay.sun.com>; Tue, 18 Mar 2008 14:56:34 -0700 (PDT) Received: from printing.Eng.Sun.COM ([129.146.178.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXY009Y04YAXL80@nwk-avmta-2.sfbay.sun.com>; Tue, 18 Mar 2008 14:56:34 -0700 (PDT) Received: from snappy.1149-Donegal-Ln.northbrook.il.us (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by printing.Eng.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2ILvlEH015666; Tue, 18 Mar 2008 14:57:48 -0700 (PDT) Date: Tue, 18 Mar 2008 16:56:33 -0500 From: Norm Jacobs Subject: CUPS 1.3.6 [PSARC/2008/130] To: PSARC-ext@sun.com Cc: Norm Jacobs Message-id: <47E03A91.20504@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 643 In my original materials for PSARC/2008/130 CUPS 1.3.6 I designated an interface stability of "Volatile" for the libcups and libcupsimage interfaces. I don't believe that we are likely to see incompatible change in these interfaces from the open source project and there are potentially a number of consumers. The open source project owner has stated that they intend on maintaining backward compatibility in these interfaces in minor releases. As a result, I would like to change their stability to "Uncommitted". If there are no objections, this mail will serve to correct the taxonomy of libcups and libcupsimage. -Norm From Norm.Jacobs@sun.com Wed Mar 19 09:04:34 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JG4YOk020220 for ; Wed, 19 Mar 2008 09:04:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2JG4Wn3005475; Wed, 19 Mar 2008 09:04:33 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ00C69JBLBG00@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 10:04:33 -0600 (MDT) Received: from printing.Eng.Sun.COM ([129.146.178.26]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ009KWJBI2E40@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 10:04:30 -0600 (MDT) Received: from snappy.1149-Donegal-Ln.northbrook.il.us (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by printing.Eng.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2JG5inB016487; Wed, 19 Mar 2008 09:05:44 -0700 (PDT) Date: Wed, 19 Mar 2008 11:04:28 -0500 From: Norm Jacobs Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E03A91.20504@Sun.COM> To: Norm Jacobs Cc: PSARC-ext@sun.com Message-id: <47E1398C.2070902@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 1540 Norm Jacobs wrote: > > In my original materials for PSARC/2008/130 CUPS 1.3.6 I designated an > interface stability of "Volatile" for > the libcups and libcupsimage interfaces. I don't believe that we are > likely to see incompatible change in these interfaces from the open > source project and there are potentially a number of consumers. The > open source project owner has stated that they intend on maintaining > backward compatibility in these interfaces in minor releases. As a > result, I would like to change their stability to "Uncommitted". > > If there are no objections, this mail will serve to correct the > taxonomy of libcups and libcupsimage. > > -Norm It was pointed out to me by a potential consumer of these interfaces that I should have included the cups-config script and header files in my list of interfaces to make Uncommitted. The complete list is as follows: /usr/sbin/cups-config /usr/include/cups/adminutil.h /usr/include/cups/array.h /usr/include/cups/backend.h /usr/include/cups/cups.h /usr/include/cups/dir.h /usr/include/cups/file.h /usr/include/cups/http.h /usr/include/cups/i18n.h /usr/include/cups/image.h /usr/include/cups/ipp.h /usr/include/cups/language.h /usr/include/cups/ppd.h /usr/include/cups/raster.h /usr/include/cups/sidechannel.h /usr/include/cups/transcode.h /usr/lib/libcups.so /usr/lib/libcupsimage.so /usr/lib/{amd64|sparcv9}/libcups.so /usr/lib/{amd64|sparcv9}/libcupsimage.so -Norm From gdamore@sun.com Wed Mar 19 09:43:44 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JGhiQ8021342 for ; Wed, 19 Mar 2008 09:43:44 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2JGhgEH063586 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Mar 2008 10:43:43 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ00E51L4UPR00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 10:43:43 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ009S1L4S2660@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 10:43:40 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2JGheJL008414 for ; Wed, 19 Mar 2008 09:43:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXZ00F01KUOVV00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 09:43:40 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXZ00CYML4OUEC0@fe-sfbay-10.sun.com>; Wed, 19 Mar 2008 09:43:37 -0700 (PDT) Date: Wed, 19 Mar 2008 09:40:44 -0700 From: "Garrett D'Amore" Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E1398C.2070902@Sun.COM> Sender: Garrett.Damore@sun.com To: Norm Jacobs Cc: PSARC-ext@sun.com Message-id: <47E1420C.7010705@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2028 Norm Jacobs wrote: > Norm Jacobs wrote: >> >> In my original materials for PSARC/2008/130 CUPS 1.3.6 I designated >> an interface stability of "Volatile" for >> the libcups and libcupsimage interfaces. I don't believe that we are >> likely to see incompatible change in these interfaces from the open >> source project and there are potentially a number of consumers. The >> open source project owner has stated that they intend on maintaining >> backward compatibility in these interfaces in minor releases. As a >> result, I would like to change their stability to "Uncommitted". >> >> If there are no objections, this mail will serve to correct the >> taxonomy of libcups and libcupsimage. >> >> -Norm > It was pointed out to me by a potential consumer of these interfaces > that I should have included the cups-config script and header files in > my list of interfaces to make Uncommitted. The complete list is as > follows: Hmm... I seem to recall someone saying that the trend was to move away from *-config scripts. Is cups-config an autoconf-style configuration script, or something that is used to configure CUPS itself? (If the former, then perhaps Volatile for just cups-config would be better, so we can move to pkg-config at a later date and yank the script. If the latter, then I see no issue for concern. :-) -- Garrett > > /usr/sbin/cups-config > /usr/include/cups/adminutil.h > /usr/include/cups/array.h > /usr/include/cups/backend.h > /usr/include/cups/cups.h > /usr/include/cups/dir.h > /usr/include/cups/file.h > /usr/include/cups/http.h > /usr/include/cups/i18n.h > /usr/include/cups/image.h > /usr/include/cups/ipp.h > /usr/include/cups/language.h > /usr/include/cups/ppd.h > /usr/include/cups/raster.h > /usr/include/cups/sidechannel.h > /usr/include/cups/transcode.h > /usr/lib/libcups.so > /usr/lib/libcupsimage.so > /usr/lib/{amd64|sparcv9}/libcups.so > /usr/lib/{amd64|sparcv9}/libcupsimage.so > > -Norm From Norm.Jacobs@sun.com Wed Mar 19 10:58:26 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JHwPuW025123 for ; Wed, 19 Mar 2008 10:58:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2JHwKGT007571; Thu, 20 Mar 2008 01:58:22 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ00I03OL9DA00@nwk-avmta-2.sfbay.sun.com>; Wed, 19 Mar 2008 10:58:21 -0700 (PDT) Received: from printing.Eng.Sun.COM ([129.146.178.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ00EZCOL93EB0@nwk-avmta-2.sfbay.sun.com>; Wed, 19 Mar 2008 10:58:21 -0700 (PDT) Received: from snappy.1149-Donegal-Ln.northbrook.il.us (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by printing.Eng.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2JHxYcm016762; Wed, 19 Mar 2008 10:59:35 -0700 (PDT) Date: Wed, 19 Mar 2008 12:58:19 -0500 From: Norm Jacobs Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E1420C.7010705@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <47E1543B.5060400@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 2358 Garrett D'Amore wrote: > Norm Jacobs wrote: >> Norm Jacobs wrote: >>> >>> In my original materials for PSARC/2008/130 CUPS 1.3.6 I designated >>> an interface stability of "Volatile" for >>> the libcups and libcupsimage interfaces. I don't believe that we >>> are likely to see incompatible change in these interfaces from the >>> open source project and there are potentially a number of >>> consumers. The open source project owner has stated that they >>> intend on maintaining backward compatibility in these interfaces in >>> minor releases. As a result, I would like to change their stability >>> to "Uncommitted". >>> >>> If there are no objections, this mail will serve to correct the >>> taxonomy of libcups and libcupsimage. >>> >>> -Norm >> It was pointed out to me by a potential consumer of these interfaces >> that I should have included the cups-config script and header files >> in my list of interfaces to make Uncommitted. The complete list is >> as follows: > > Hmm... I seem to recall someone saying that the trend was to move away > from *-config scripts. Is cups-config an autoconf-style configuration > script, or something that is used to configure CUPS itself? (If the > former, then perhaps Volatile for just cups-config would be better, so > we can move to pkg-config at a later date and yank the script. If the > latter, then I see no issue for concern. :-) > cups-config is used by consumers of CUPS interfaces to augment their CFLAGS, LDLIBS, ... during their build. CUPS doesn't ship a pkg-config .pc file, though I suppose that I could generate one. Even at that, those tools that already use cups-config during their build aren't likely to change until CUPS shipped a pkg-config .pc file for some time. I can work with the upstream community to try to include a cups pkg-config .pc file and re-implement cups-config in terms of pkg-config/cups.pc, but cups-config is likely to be around for some time. Perhaps the trend is to move away from *-config scripts, but CUPS hasn't embraced this yet and as a result, neither have the consumers of it's interfaces (at least for CUPS related build information). I would be inclined to have it Uncommitted until we see CUPS move in the direction of pkg-config. We can make it volatile if/when they start to support pkg-config. -Norm From gdamore@sun.com Wed Mar 19 11:19:16 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JIJFYN025703 for ; Wed, 19 Mar 2008 11:19:16 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2JIJ9gi015430 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Mar 2008 02:19:14 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ00H1RPK1I800@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 11:19:13 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ004AXPK0FVA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 11:19:12 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2JIJCDG000175 for ; Wed, 19 Mar 2008 11:19:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXZ00C01OSYIU00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 11:19:12 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXZ000PJPJW1R50@fe-sfbay-09.sun.com>; Wed, 19 Mar 2008 11:19:08 -0700 (PDT) Date: Wed, 19 Mar 2008 11:16:16 -0700 From: "Garrett D'Amore" Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E1543B.5060400@Sun.COM> Sender: Garrett.Damore@sun.com To: Norm Jacobs Cc: PSARC-ext@sun.com Message-id: <47E15870.40507@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 2787 Norm Jacobs wrote: > Garrett D'Amore wrote: >> Norm Jacobs wrote: >>> Norm Jacobs wrote: >>>> >>>> In my original materials for PSARC/2008/130 CUPS 1.3.6 I designated >>>> an interface stability of "Volatile" for >>>> the libcups and libcupsimage interfaces. I don't believe that we >>>> are likely to see incompatible change in these interfaces from the >>>> open source project and there are potentially a number of >>>> consumers. The open source project owner has stated that they >>>> intend on maintaining backward compatibility in these interfaces in >>>> minor releases. As a result, I would like to change their >>>> stability to "Uncommitted". >>>> >>>> If there are no objections, this mail will serve to correct the >>>> taxonomy of libcups and libcupsimage. >>>> >>>> -Norm >>> It was pointed out to me by a potential consumer of these interfaces >>> that I should have included the cups-config script and header files >>> in my list of interfaces to make Uncommitted. The complete list is >>> as follows: >> >> Hmm... I seem to recall someone saying that the trend was to move >> away from *-config scripts. Is cups-config an autoconf-style >> configuration script, or something that is used to configure CUPS >> itself? (If the former, then perhaps Volatile for just cups-config >> would be better, so we can move to pkg-config at a later date and >> yank the script. If the latter, then I see no issue for concern. :-) >> > cups-config is used by consumers of CUPS interfaces to augment their > CFLAGS, LDLIBS, ... during their build. CUPS doesn't ship a pkg-config > .pc file, though I suppose that I could generate one. Even at that, > those tools that already use cups-config during their build aren't > likely to change until CUPS shipped a pkg-config .pc file for some > time. I can work with the upstream community to try to include a cups > pkg-config .pc file and re-implement cups-config in terms of > pkg-config/cups.pc, but cups-config is likely to be around for some time. > Perhaps the trend is to move away from *-config scripts, but CUPS > hasn't embraced this yet and as a result, neither have the consumers > of it's interfaces (at least for CUPS related build information). I > would be inclined to have it Uncommitted until we see CUPS move in the > direction of pkg-config. We can make it volatile if/when they start > to support pkg-config. Um... you can't do that easily. Its far far easier to *raise* commitment than reduce it. Please consider leaving this particular interface Volatile for now. (I imagine that at some point CUPS will offer a .pc file, since that seems to be the way of the future.) And yes, I'd like to see this requested upstream as well... -- Garrett > > -Norm > From Norm.Jacobs@sun.com Wed Mar 19 11:41:48 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JIfmEV025929 for ; Wed, 19 Mar 2008 11:41:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2JIfmKY010605; Wed, 19 Mar 2008 11:41:48 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ00J01QLNQF00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 11:41:47 -0700 (PDT) Received: from printing.Eng.Sun.COM ([129.146.178.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ004M5QLLFVB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 11:41:46 -0700 (PDT) Received: from snappy.1149-Donegal-Ln.northbrook.il.us (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by printing.Eng.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2JIgxre016856; Wed, 19 Mar 2008 11:43:00 -0700 (PDT) Date: Wed, 19 Mar 2008 13:41:44 -0500 From: Norm Jacobs Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E15870.40507@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com Message-id: <47E15E68.4070708@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 3345 Garrett D'Amore wrote: > Norm Jacobs wrote: >> Garrett D'Amore wrote: >>> Norm Jacobs wrote: >>>> Norm Jacobs wrote: >>>>> >>>>> In my original materials for PSARC/2008/130 CUPS 1.3.6 I >>>>> designated an interface stability of "Volatile" for >>>>> the libcups and libcupsimage interfaces. I don't believe that we >>>>> are likely to see incompatible change in these interfaces from the >>>>> open source project and there are potentially a number of >>>>> consumers. The open source project owner has stated that they >>>>> intend on maintaining backward compatibility in these interfaces >>>>> in minor releases. As a result, I would like to change their >>>>> stability to "Uncommitted". >>>>> >>>>> If there are no objections, this mail will serve to correct the >>>>> taxonomy of libcups and libcupsimage. >>>>> >>>>> -Norm >>>> It was pointed out to me by a potential consumer of these >>>> interfaces that I should have included the cups-config script and >>>> header files in my list of interfaces to make Uncommitted. The >>>> complete list is as follows: >>> >>> Hmm... I seem to recall someone saying that the trend was to move >>> away from *-config scripts. Is cups-config an autoconf-style >>> configuration script, or something that is used to configure CUPS >>> itself? (If the former, then perhaps Volatile for just cups-config >>> would be better, so we can move to pkg-config at a later date and >>> yank the script. If the latter, then I see no issue for concern. :-) >>> >> cups-config is used by consumers of CUPS interfaces to augment their >> CFLAGS, LDLIBS, ... during their build. CUPS doesn't ship a >> pkg-config .pc file, though I suppose that I could generate one. >> Even at that, those tools that already use cups-config during their >> build aren't likely to change until CUPS shipped a pkg-config .pc >> file for some time. I can work with the upstream community to try to >> include a cups pkg-config .pc file and re-implement cups-config in >> terms of pkg-config/cups.pc, but cups-config is likely to be around >> for some time. >> Perhaps the trend is to move away from *-config scripts, but CUPS >> hasn't embraced this yet and as a result, neither have the consumers >> of it's interfaces (at least for CUPS related build information). I >> would be inclined to have it Uncommitted until we see CUPS move in >> the direction of pkg-config. We can make it volatile if/when they >> start to support pkg-config. > > Um... you can't do that easily. Its far far easier to *raise* > commitment than reduce it. Please consider leaving this particular > interface Volatile for now. > > (I imagine that at some point CUPS will offer a .pc file, since that > seems to be the way of the future.) > > And yes, I'd like to see this requested upstream as well... > The point of raising the stability of the interfaces is to save anyone wanting to use the CUPS APIs the trouble of having to file a contract to use them. If they have to file one to use cups-config in order to discover the interfaces through the GNU auto* koolaid, it kind of refutes the purpose in my mind. I can plan for the future, but I need to accommodate the realities of today. Given what I am trying to acheive, perhaps "Uncommitted Obsolete" would be more appropriate. -Norm From gdamore@sun.com Wed Mar 19 11:59:15 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JIxEX8026656 for ; Wed, 19 Mar 2008 11:59:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2JIxCN4000706 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Mar 2008 02:59:13 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ00105REP7O00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 12:59:13 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ00M86REOJK10@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 12:59:12 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2JIxCdB027816 for ; Wed, 19 Mar 2008 11:59:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXZ00L01QZLYO00@fe-sfbay-09.sun.com> (original mail from gdamore@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 11:59:12 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXZ00572REKQCB0@fe-sfbay-09.sun.com>; Wed, 19 Mar 2008 11:59:08 -0700 (PDT) Date: Wed, 19 Mar 2008 11:56:16 -0700 From: "Garrett D'Amore" Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E15E68.4070708@Sun.COM> Sender: Garrett.Damore@sun.com To: Norm Jacobs Cc: PSARC-ext@sun.com Message-id: <47E161D0.2090001@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> <47E15E68.4070708@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 4685 Norm Jacobs wrote: > Garrett D'Amore wrote: >> Norm Jacobs wrote: >>> Garrett D'Amore wrote: >>>> Norm Jacobs wrote: >>>>> Norm Jacobs wrote: >>>>>> >>>>>> In my original materials for PSARC/2008/130 CUPS 1.3.6 I >>>>>> designated an interface stability of "Volatile" for >>>>>> the libcups and libcupsimage interfaces. I don't believe that we >>>>>> are likely to see incompatible change in these interfaces from >>>>>> the open source project and there are potentially a number of >>>>>> consumers. The open source project owner has stated that they >>>>>> intend on maintaining backward compatibility in these interfaces >>>>>> in minor releases. As a result, I would like to change their >>>>>> stability to "Uncommitted". >>>>>> >>>>>> If there are no objections, this mail will serve to correct the >>>>>> taxonomy of libcups and libcupsimage. >>>>>> >>>>>> -Norm >>>>> It was pointed out to me by a potential consumer of these >>>>> interfaces that I should have included the cups-config script and >>>>> header files in my list of interfaces to make Uncommitted. The >>>>> complete list is as follows: >>>> >>>> Hmm... I seem to recall someone saying that the trend was to move >>>> away from *-config scripts. Is cups-config an autoconf-style >>>> configuration script, or something that is used to configure CUPS >>>> itself? (If the former, then perhaps Volatile for just cups-config >>>> would be better, so we can move to pkg-config at a later date and >>>> yank the script. If the latter, then I see no issue for concern. :-) >>>> >>> cups-config is used by consumers of CUPS interfaces to augment their >>> CFLAGS, LDLIBS, ... during their build. CUPS doesn't ship a >>> pkg-config .pc file, though I suppose that I could generate one. >>> Even at that, those tools that already use cups-config during their >>> build aren't likely to change until CUPS shipped a pkg-config .pc >>> file for some time. I can work with the upstream community to try >>> to include a cups pkg-config .pc file and re-implement cups-config >>> in terms of pkg-config/cups.pc, but cups-config is likely to be >>> around for some time. >>> Perhaps the trend is to move away from *-config scripts, but CUPS >>> hasn't embraced this yet and as a result, neither have the consumers >>> of it's interfaces (at least for CUPS related build information). I >>> would be inclined to have it Uncommitted until we see CUPS move in >>> the direction of pkg-config. We can make it volatile if/when they >>> start to support pkg-config. >> >> Um... you can't do that easily. Its far far easier to *raise* >> commitment than reduce it. Please consider leaving this particular >> interface Volatile for now. >> >> (I imagine that at some point CUPS will offer a .pc file, since that >> seems to be the way of the future.) >> >> And yes, I'd like to see this requested upstream as well... >> > The point of raising the stability of the interfaces is to save anyone > wanting to use the CUPS APIs the trouble of having to file a contract > to use them. If they have to file one to use cups-config in order to > discover the interfaces through the GNU auto* koolaid, it kind of > refutes the purpose in my mind. I can plan for the future, but I need > to accommodate the realities of today. Given what I am trying to > acheive, perhaps "Uncommitted Obsolete" would be more appropriate. Hmm, actually that might. But I think to declare something Obsolete you need to have a non-Obsolete alternative (i.e. pkg-config) already in place. If you can effect that change, I'd be satisfied. I'm not sure Volatile requires a contract be put into place. Another approach might be Consolidation Private, if you don't need to access this from outside of the Consolidation. (Of course, that begs the other question, which is 3rd party *unbundled* software. But of course, most of that is just going to use it no matter what we call the stability level. So are the intended consumers of this within the same consolidation, or are you intending this to be a public API?) So as I see it the choices are: 1) Uncommitted Obsolete, with a .pc config file -- which I presume would have Uncommitted stability.) 2) Volatile - 3rd party software depends on it at their own risk (this is really the case, anyway) 3) Consolidation Private -- if you don't need to support 3rd party consumers, *particularly* if you are able to avoid packaging the actual /usr/sbin/*-config script (but perhaps leave it in the proto area or whatever equivalent SFW uses.) There may be others -- but those are the ones I can think of. -- Garrett > -Norm > > From carlsonj@phorcys.east.sun.com Wed Mar 19 12:03:54 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JJ3sle027016 for ; Wed, 19 Mar 2008 12:03:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2JJ3q7W046059; Wed, 19 Mar 2008 13:03:53 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ00M03RMG1S00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 12:03:52 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ004PYRMFFLD0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 12:03:52 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2JJ3p5a009677; Wed, 19 Mar 2008 15:03:51 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m2JJ3p6Y009674; Wed, 19 Mar 2008 15:03:51 -0400 (EDT) Date: Wed, 19 Mar 2008 15:03:51 -0400 From: James Carlson Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E15E68.4070708@Sun.COM> To: Norm Jacobs Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <18401.25495.403330.16348@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> <47E15E68.4070708@Sun.COM> Status: RO Content-Length: 918 Norm Jacobs writes: > to accommodate the realities of today. Given what I am trying to > acheive, perhaps "Uncommitted Obsolete" would be more appropriate. This is just a minor nit, but I'd suggest using "Obsolete Committed." "Obsolete Uncommitted" is possible, but doesn't really make much sense. It means that we don't want people to use it (it's obsolete) but that we're likely to make incompatible changes to it in the future. Other than removal (which is what "obsolete" already implies), what incompatible changes would we bother making in an interface we're going to tear down anyway? Such interfaces typically don't evolve in any meaningful way; they just get removed over time. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Norm.Jacobs@sun.com Wed Mar 19 12:44:38 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JJibgB027975 for ; Wed, 19 Mar 2008 12:44:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2JJiQ05019482; Thu, 20 Mar 2008 03:44:33 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ00225TI5V300@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 12:44:29 -0700 (PDT) Received: from printing.Eng.Sun.COM ([129.146.178.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ001QJTI55880@nwk-avmta-1.sfbay.Sun.COM>; Wed, 19 Mar 2008 12:44:29 -0700 (PDT) Received: from snappy.1149-Donegal-Ln.northbrook.il.us (punchin-jacobs.SFBay.Sun.COM [10.7.251.237]) by printing.Eng.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2JJjhDx016976; Wed, 19 Mar 2008 12:45:43 -0700 (PDT) Date: Wed, 19 Mar 2008 14:44:28 -0500 From: Norm Jacobs Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <18401.25495.403330.16348@gargle.gargle.HOWL> To: James Carlson Cc: "Garrett D'Amore" , psarc-ext@sun.com Message-id: <47E16D1C.9070704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> <47E15E68.4070708@Sun.COM> <18401.25495.403330.16348@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 962 James Carlson wrote: > Norm Jacobs writes: > >> to accommodate the realities of today. Given what I am trying to >> acheive, perhaps "Uncommitted Obsolete" would be more appropriate. >> > > This is just a minor nit, but I'd suggest using "Obsolete Committed." > "Obsolete Uncommitted" is possible, but doesn't really make much > sense. It means that we don't want people to use it (it's obsolete) > but that we're likely to make incompatible changes to it in the > future. > > Other than removal (which is what "obsolete" already implies), what > incompatible changes would we bother making in an interface we're > going to tear down anyway? Such interfaces typically don't evolve in > any meaningful way; they just get removed over time Ok, I propose that cups-config be "Obsolete Committed" and I add a new .pc file /usr/lib/pkgconfig/cups.pc that I will designate as Uncommitted. That should address both your and Garrett's issues. -Norm From John.Plocher@sun.com Wed Mar 19 13:24:48 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JKOmtm029489 for ; Wed, 19 Mar 2008 13:24:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2JKOmJK026035 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Mar 2008 13:24:48 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ00003VDBHE00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 19 Mar 2008 13:24:47 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ0002GVDBFC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 19 Mar 2008 13:24:47 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2JKOkbE017547 for ; Wed, 19 Mar 2008 13:24:46 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXZ00801SNFPW00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 19 Mar 2008 13:24:46 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXZ00HLWVD0B310@fe-sfbay-10.sun.com>; Wed, 19 Mar 2008 13:24:36 -0700 (PDT) Date: Wed, 19 Mar 2008 13:24:34 -0700 From: John Plocher Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E15E68.4070708@Sun.COM> Sender: John.Plocher@sun.com To: Norm Jacobs Cc: "Garrett D'Amore" , PSARC-ext@sun.com Message-id: <47E17682.3080501@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> <47E15E68.4070708@Sun.COM> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 1833 Norm Jacobs wrote: > The point of raising the stability of the interfaces is to save anyone > wanting to use the CUPS APIs the trouble of having to file a contract to > use them. The interface taxonomy is used for two different-but-related purposes: 1) It sets expectations for the "end user", and 2) It sets expectations *and policies* for "project, component and distro developers". While the expectations being set are somewhat similar, their impact on the local development process differs. "External (#1)" consumers get to make their own policies about how and when to use the interfaces, and what risk management/testing/... they need to plan for in case of incompatible change in a new release. "Internal users (#2)" get the benefit of a preexisting set of policies *and* the added granularity of a suite of Private taxonomy classifications. The focus for this class of user is maintaining the ability for us to build our own systems so that they can be delivered to those "External" consumers. A large part of this "make sure we can continue to build our systems" mentality is delegating the "you get to worry about everything that impacts your consolidation's internal self-consistency" job to the consolidation itself, freeing the ARC and individual projects from having to micro-manage the consolidations themselves. Volatile or even Obsolete would be my choice based on the above. If you can ensure that all consumers of the CUPS -config stuff are within the SFW consolidation, then all the internal dependencies can/should/will be handled as "SFW Consolidation management" issues. From an ARC process standpoint, maybe we should expand the definition of Volatile to include the assertion that Volatile implies a Consolidation Private level of cross-Project sharing. -John From danek.duvall@sun.com Wed Mar 19 13:26:40 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JKQdnO029623 for ; Wed, 19 Mar 2008 13:26:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2JKQYOl005786; Thu, 20 Mar 2008 04:26:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ0000HVG9KE00@nwk-avmta-2.sfbay.sun.com>; Wed, 19 Mar 2008 13:26:34 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ0006VVG9F900@nwk-avmta-2.sfbay.sun.com>; Wed, 19 Mar 2008 13:26:33 -0700 (PDT) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2JKQWuB042203; Wed, 19 Mar 2008 13:26:32 -0700 (PDT) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m2JKQW50018486; Wed, 19 Mar 2008 13:26:32 -0700 (PDT) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m2JKQW9I018485; Wed, 19 Mar 2008 13:26:32 -0700 (PDT) Date: Wed, 19 Mar 2008 13:26:32 -0700 From: Danek Duvall Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E161D0.2090001@sun.com> To: "Garrett D'Amore" Cc: Norm Jacobs , PSARC-ext@sun.com Message-id: <20080319202632.GA29238@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> <47E15E68.4070708@Sun.COM> <47E161D0.2090001@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 446 On Wed, Mar 19, 2008 at 11:56:16AM -0700, Garrett D'Amore wrote: > But I think to declare something Obsolete you need to have a non-Obsolete > alternative (i.e. pkg-config) already in place. Where did that requirement come from? Not everything that gets removed from the system will ever have a replacement. And even if it did, it needn't be ready for business at the time of Obsolescence (although the two interfaces should overlap). Danek From Nicolas.Williams@sun.com Wed Mar 19 13:44:25 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JKiOs6000030 for ; Wed, 19 Mar 2008 13:44:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2JKiBKo012050; Thu, 20 Mar 2008 04:44:20 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ00801W9UKT00@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 14:44:18 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ00M9GW9TJI80@brm-avmta-1.central.sun.com>; Wed, 19 Mar 2008 14:44:17 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m2JKiHcR019711; Wed, 19 Mar 2008 15:44:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m2JKiHSt019710; Wed, 19 Mar 2008 15:44:17 -0500 (CDT) Date: Wed, 19 Mar 2008 15:44:17 -0500 From: Nicolas Williams Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E15E68.4070708@Sun.COM> To: Norm Jacobs Cc: "Garrett D'Amore" , PSARC-ext@sun.com Mail-followup-to: Norm Jacobs , Garrett D'Amore , PSARC-ext@sun.com Message-id: <20080319204417.GX16998@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> <47E15E68.4070708@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 793 On Wed, Mar 19, 2008 at 01:41:44PM -0500, Norm Jacobs wrote: > The point of raising the stability of the interfaces is to save anyone > wanting to use the CUPS APIs the trouble of having to file a contract to > use them. If they have to file one to use cups-config in order to > discover the interfaces through the GNU auto* koolaid, it kind of > refutes the purpose in my mind. I can plan for the future, but I need > to accommodate the realities of today. Given what I am trying to > acheive, perhaps "Uncommitted Obsolete" would be more appropriate. The *-config files are needed only at build time, and if they are to be replaced with /usr/lib/pkgconfig/*.pc, then I don't see why *-config can't be made Obsolete Volatile. Built software certainly won't needed them. Nico -- From gdamore@sun.com Wed Mar 19 14:43:02 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JLh2Re003167 for ; Wed, 19 Mar 2008 14:43:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2JLh1Md018303 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Mar 2008 14:43:02 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ0032RYZPKY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 14:43:02 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ000YWYZPF450@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 14:43:01 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2JLh0Kg028251 for ; Wed, 19 Mar 2008 14:43:00 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXZ00701YEKXO00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 14:43:00 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXZ008LZYZL78G0@fe-sfbay-09.sun.com>; Wed, 19 Mar 2008 14:42:57 -0700 (PDT) Date: Wed, 19 Mar 2008 14:40:05 -0700 From: "Garrett D'Amore" Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E17682.3080501@Sun.Com> Sender: Garrett.Damore@sun.com To: John Plocher Cc: Norm Jacobs , PSARC-ext@sun.com Message-id: <47E18835.5090605@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> <47E15E68.4070708@Sun.COM> <47E17682.3080501@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 330 John Plocher wrote: > > From an ARC process standpoint, maybe we should expand the > definition of Volatile to include the assertion that > Volatile implies a Consolidation Private level of > cross-Project sharing. I think this is an excellent idea, if it doesn't already imply that. -- Garrett > > -John > > > > From gdamore@sun.com Wed Mar 19 14:45:27 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JLjQFn003285 for ; Wed, 19 Mar 2008 14:45:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2JLjKia007545 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Mar 2008 05:45:25 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXZ0030LZ3NO900@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 19 Mar 2008 14:45:23 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXZ000RFZ3MFC60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 19 Mar 2008 14:45:22 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2JLjHHG028552 for ; Wed, 19 Mar 2008 14:45:22 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXZ00701YEKXO00@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 19 Mar 2008 14:45:19 -0700 (PDT) Received: from [192.168.251.106] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXZ008CHZ3A78I0@fe-sfbay-09.sun.com>; Wed, 19 Mar 2008 14:45:10 -0700 (PDT) Date: Wed, 19 Mar 2008 14:42:18 -0700 From: "Garrett D'Amore" Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <20080319202632.GA29238@zruty.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Danek Duvall Cc: Norm Jacobs , PSARC-ext@sun.com Message-id: <47E188BA.6060003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> <47E15E68.4070708@Sun.COM> <47E161D0.2090001@sun.com> <20080319202632.GA29238@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071023) Status: RO Content-Length: 734 Danek Duvall wrote: > On Wed, Mar 19, 2008 at 11:56:16AM -0700, Garrett D'Amore wrote: > > >> But I think to declare something Obsolete you need to have a non-Obsolete >> alternative (i.e. pkg-config) already in place. >> > > Where did that requirement come from? Not everything that gets removed > from the system will ever have a replacement. And even if it did, it > needn't be ready for business at the time of Obsolescence (although the two > interfaces should overlap). > Well, I don't know if there is any written rule. But it seems poor form to declare something obsolete without a replacement -- UNLESS the intention is to provide *no* replacement (e.g. removal of Wildcat support). -- Garrett > Danek > From Mike.Oliver@sun.com Wed Mar 19 15:12:23 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2JMCNQU004225 for ; Wed, 19 Mar 2008 15:12:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2JMCL2p043849 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 19 Mar 2008 16:12:22 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY000H330CML700@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 15:12:22 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY0004K70CKBAA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 15:12:20 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2JMCJbA021941 for ; Wed, 19 Mar 2008 15:12:19 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXZ00501Z1WIT00@fe-sfbay-10.sun.com> (original mail from Mike.Oliver@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 19 Mar 2008 15:12:19 -0700 (PDT) Received: from [129.145.154.112] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JY000G1O0C975H0@fe-sfbay-10.sun.com>; Wed, 19 Mar 2008 15:12:10 -0700 (PDT) Date: Wed, 19 Mar 2008 15:12:09 -0700 From: Mike Oliver Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E18835.5090605@sun.com> Sender: Mike.Oliver@sun.com To: "Garrett D'Amore" Cc: Norm Jacobs , PSARC-ext@sun.com Message-id: <47E18FB9.1040103@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> <47E15E68.4070708@Sun.COM> <47E17682.3080501@Sun.Com> <47E18835.5090605@sun.com> User-Agent: Thunderbird 2.0.0.13pre (X11/20080316) Status: RO Content-Length: 876 Garrett D'Amore wrote: > John Plocher wrote: >> >> From an ARC process standpoint, maybe we should expand the >> definition of Volatile to include the assertion that >> Volatile implies a Consolidation Private level of >> cross-Project sharing. > > I think this is an excellent idea, if it doesn't already imply that. It already explicitly means that (modulo quibbling over the meaning of "should" and "is") when applied to Sun products. From the definition of "Volatile" in the Interface Taxonomy doc at : Sun products should consider Volatile interfaces as equivalent to Consolidation Private. A contract is required for use of these interfaces outside of the supplying consolidation. Sorry, I've no idea whether or where that doc is accessible from outside Sun. Mike. -- mike.oliver@sun.com From gww@eng.sun.com Wed Mar 19 19:58:55 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2K2wsL1011360 for ; Wed, 19 Mar 2008 19:58:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2K2wmVd026881; Thu, 20 Mar 2008 02:58:52 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY000H0FDM28I00@nwk-avmta-2.sfbay.sun.com>; Wed, 19 Mar 2008 19:58:50 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY0008WVDM2LW90@nwk-avmta-2.sfbay.sun.com>; Wed, 19 Mar 2008 19:58:50 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2K2wnQB041144; Wed, 19 Mar 2008 19:58:49 -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 m2K3x2Hf005561; Wed, 19 Mar 2008 19:59:02 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m2K3x2oh005560; Wed, 19 Mar 2008 19:59:02 -0800 (PST) Date: Wed, 19 Mar 2008 19:59:02 -0800 (PST) From: Gary Winiger Subject: Re: CUPS 1.3.6 [PSARC/2008/130] To: Danek.Duvall@sun.com, gdamore@sun.com Cc: Norm.Jacobs@sun.com, PSARC-ext@sun.com Message-id: <200803200359.m2K3x2oh005560@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 760 > >> But I think to declare something Obsolete you need to have a non-Obsolete > >> alternative (i.e. pkg-config) already in place. > >> > > > > Where did that requirement come from? Not everything that gets removed > > from the system will ever have a replacement. And even if it did, it > > needn't be ready for business at the time of Obsolescence (although the two > > interfaces should overlap). > > > > Well, I don't know if there is any written rule. But it seems poor form > to declare something obsolete without a replacement -- UNLESS the > intention is to provide *no* replacement (e.g. removal of Wildcat support). See the C team/ SPAC EOF rules. This is generally only an ARC issues if it affects dependent components. Gary.. From storycrafter@gmail.com Thu Mar 20 08:31:31 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2KFVVpF001695 for ; Thu, 20 Mar 2008 08:31:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2KFVUP8015012 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Mar 2008 08:31:31 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY100D5DCGIQ400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Mar 2008 08:31:30 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY100BO0CGGFW40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Mar 2008 08:31:28 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2KFVS9N021094 for ; Thu, 20 Mar 2008 15:31:28 +0000 (GMT) Received: from mmp12es.sun.com ([160.41.209.22] [160.41.209.22]) by relay11i.sun.com with ESMTP id BT-MMP-421059 for PSARC-ext@sun.com; Thu, 20 Mar 2008 15:31:28 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.sun.com with ESMTP id BT-MMP-391709 for PSARC-ext@sun.com; Thu, 20 Mar 2008 15:31:28 +0000 (Z) Received: from wx-out-0506.google.com ([66.249.82.239] [66.249.82.239]) by relay1i.sun.com with ESMTP id BT-MMP-3649754 for PSARC-ext@sun.com; Thu, 20 Mar 2008 15:31:28 +0000 (Z) Received: by wx-out-0506.google.com with SMTP id s11so1035438wxc.17 for ; Thu, 20 Mar 2008 08:29:47 -0700 (PDT) Received: by 10.100.172.16 with SMTP id u16mr5854874ane.89.1206026987450; Thu, 20 Mar 2008 08:29:47 -0700 (PDT) Received: by 10.100.44.7 with HTTP; Thu, 20 Mar 2008 08:29:47 -0700 (PDT) Date: Thu, 20 Mar 2008 10:29:47 -0500 From: Mark Martin Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E18FB9.1040103@sun.com> To: Mike Oliver Cc: "Garrett D'Amore" , Norm Jacobs , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ejHuCPE+U5Xv19U0uG7XXQ)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=xZIAsYf4h8MYLEbB/o2Ckft4m1QmZ1WJlxKMiExXNT0=; b=iZUY3i1XwoqynKZjuvJZ2xavYI1+e8vH0XYkgsubEVmIzUtLbbbAAqm/2LXWorhK7Wxh0MfTfzR67X+Q9mKxh7tkSufIWEipdjlMilSo5kuQh+Z7UAYNSLiykNdejVe9bWaGDEbssPnVk980wrVI9rFMm6gv+7+2TSV8Jo7AOvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=D54Tj7YFop3jnwXZYGoQn4xzf8PWO0TXQUKx1sc8f1A1zEgAfVm4va1ZHAW94IPehobBnYZ0vt+39Aj73NvZK4ANHN2gj+Atx/CLGN8qU7MNEqStismKhkxpaFdoq/8WyoWHNwal/psCQt1b19kqgfarGM7yNOHaLthYrNq9QrU= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.079sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> <47E15E68.4070708@Sun.COM> <47E17682.3080501@Sun.Com> <47E18835.5090605@sun.com> <47E18FB9.1040103@sun.com> Status: RO Content-Length: 2246 --Boundary_(ID_ejHuCPE+U5Xv19U0uG7XXQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Wed, Mar 19, 2008 at 5:12 PM, Mike Oliver wrote: > > It already explicitly means that (modulo quibbling over the meaning > of "should" and "is") when applied to Sun products. From the > definition of "Volatile" in the Interface Taxonomy doc at > : > > Sun products should consider Volatile interfaces as equivalent > to Consolidation Private. A contract is required for use of > these interfaces outside of the supplying consolidation. > > Sorry, I've no idea whether or where that doc is accessible from > outside Sun. > http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ --Boundary_(ID_ejHuCPE+U5Xv19U0uG7XXQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline
On Wed, Mar 19, 2008 at 5:12 PM, Mike Oliver <Mike.Oliver@sun.com> wrote:

It already explicitly means that (modulo quibbling over the meaning
of "should" and "is") when applied to Sun products.  From the
definition of "Volatile" in the Interface Taxonomy doc at
<http://sac.eng/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp>:

  Sun products should consider Volatile interfaces as equivalent
  to Consolidation Private. A contract is required for use of
  these interfaces outside of the supplying consolidation.

Sorry, I've no idea whether or where that doc is accessible from
outside Sun.
--Boundary_(ID_ejHuCPE+U5Xv19U0uG7XXQ)-- From storycrafter@gmail.com Thu Mar 20 08:31:51 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2KFVpg9001712 for ; Thu, 20 Mar 2008 08:31:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2KFVmuj050971 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 20 Mar 2008 09:31:51 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY100213CH0PR00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Mar 2008 08:31:48 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY100H1SCGZ1RD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 20 Mar 2008 08:31:47 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2KF0xJL013583 for ; Thu, 20 Mar 2008 15:31:47 +0000 (GMT) Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay43i.sun.com with ESMTP id BT-MMP-1425954 for PSARC-ext@sun.com; Thu, 20 Mar 2008 15:31:47 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mms48es.sun.com with ESMTP id BT-MMP-321040 for PSARC-ext@sun.com; Thu, 20 Mar 2008 15:31:20 +0000 (Z) Received: from wx-out-0506.google.com ([66.249.82.225] [66.249.82.225]) by relay4i.sun.com with ESMTP id BT-MMP-36476724 for PSARC-ext@sun.com; Thu, 20 Mar 2008 15:31:20 +0000 (Z) Received: by wx-out-0506.google.com with SMTP id s11so1035921wxc.17 for ; Thu, 20 Mar 2008 08:31:20 -0700 (PDT) Received: by 10.100.172.16 with SMTP id u16mr5854874ane.89.1206026987450; Thu, 20 Mar 2008 08:29:47 -0700 (PDT) Received: by 10.100.44.7 with HTTP; Thu, 20 Mar 2008 08:29:47 -0700 (PDT) Date: Thu, 20 Mar 2008 10:29:47 -0500 From: Mark Martin Subject: Re: CUPS 1.3.6 [PSARC/2008/130] In-reply-to: <47E18FB9.1040103@sun.com> To: Mike Oliver Cc: "Garrett D'Amore" , Norm Jacobs , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vjvVUftFmwaZ6uWa/T1WZw)" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=xZIAsYf4h8MYLEbB/o2Ckft4m1QmZ1WJlxKMiExXNT0=; b=iZUY3i1XwoqynKZjuvJZ2xavYI1+e8vH0XYkgsubEVmIzUtLbbbAAqm/2LXWorhK7Wxh0MfTfzR67X+Q9mKxh7tkSufIWEipdjlMilSo5kuQh+Z7UAYNSLiykNdejVe9bWaGDEbssPnVk980wrVI9rFMm6gv+7+2TSV8Jo7AOvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=D54Tj7YFop3jnwXZYGoQn4xzf8PWO0TXQUKx1sc8f1A1zEgAfVm4va1ZHAW94IPehobBnYZ0vt+39Aj73NvZK4ANHN2gj+Atx/CLGN8qU7MNEqStismKhkxpaFdoq/8WyoWHNwal/psCQt1b19kqgfarGM7yNOHaLthYrNq9QrU= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.212sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <47E03A91.20504@Sun.COM> <47E1398C.2070902@Sun.COM> <47E1420C.7010705@sun.com> <47E1543B.5060400@Sun.COM> <47E15870.40507@sun.com> <47E15E68.4070708@Sun.COM> <47E17682.3080501@Sun.Com> <47E18835.5090605@sun.com> <47E18FB9.1040103@sun.com> Status: RO Content-Length: 2246 --Boundary_(ID_vjvVUftFmwaZ6uWa/T1WZw) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline On Wed, Mar 19, 2008 at 5:12 PM, Mike Oliver wrote: > > It already explicitly means that (modulo quibbling over the meaning > of "should" and "is") when applied to Sun products. From the > definition of "Volatile" in the Interface Taxonomy doc at > : > > Sun products should consider Volatile interfaces as equivalent > to Consolidation Private. A contract is required for use of > these interfaces outside of the supplying consolidation. > > Sorry, I've no idea whether or where that doc is accessible from > outside Sun. > http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ --Boundary_(ID_vjvVUftFmwaZ6uWa/T1WZw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline
On Wed, Mar 19, 2008 at 5:12 PM, Mike Oliver <Mike.Oliver@sun.com> wrote:

It already explicitly means that (modulo quibbling over the meaning
of "should" and "is") when applied to Sun products.  From the
definition of "Volatile" in the Interface Taxonomy doc at
<http://sac.eng/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp>:

  Sun products should consider Volatile interfaces as equivalent
  to Consolidation Private. A contract is required for use of
  these interfaces outside of the supplying consolidation.

Sorry, I've no idea whether or where that doc is accessible from
outside Sun.
--Boundary_(ID_vjvVUftFmwaZ6uWa/T1WZw)--