From sacadmin Tue Jan 29 14:48:22 2008 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0TMmMux000696; Tue, 29 Jan 2008 14:48:22 -0800 (PST) Received: (from johnf@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m0TMmMDu000692; Tue, 29 Jan 2008 14:48:22 -0800 (PST) Date: Tue, 29 Jan 2008 14:48:22 -0800 (PST) From: John Fischer Message-Id: <200801292248.m0TMmMDu000692@sac.sfbay.sun.com> To: LSARC-record@sac.sfbay.sun.com Subject: SQLite [LSARC/2008/059 FastTrack timeout 02/05/2008] Status: RO Content-Length: 553 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: SQLite 1.2. Name of Document Author/Supplier: Author: Elaine Xiong 1.3 Date of This Document: 29 January, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: JDS - Mozilla 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From John.Fischer@sun.com Tue Jan 29 15:00: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 m0TN0Sqm001173 for ; Tue, 29 Jan 2008 15:00:28 -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 m0TN0EhJ004305 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 30 Jan 2008 07:00: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 <0JVF00K27H8OBR00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 29 Jan 2008 16:00:24 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVF00K9PH8K2N00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 29 Jan 2008 16:00:20 -0700 (MST) 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 m0TN0K0X020059 for ; Tue, 29 Jan 2008 15:00:20 -0800 (PST) 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 <0JVF00G01H2F1K00@fe-sfbay-10.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 29 Jan 2008 15:00:20 -0800 (PST) Received: from [192.168.10.6] ([24.10.86.139]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVF00C17H84NK30@fe-sfbay-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 29 Jan 2008 15:00:05 -0800 (PST) Date: Tue, 29 Jan 2008 14:59:45 -0800 From: John Fischer Subject: LSARC/2008/059 - SQLite Sender: John.Fischer@sun.com To: Elaine.Xiong@sun.com, Evan.Yan@sun.com, "brian.lu" , lsarc-ext@sun.com Reply-to: John.Fischer@sun.com Message-id: <479FAFE1.5020601@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_zg3I/CHv+348TuvQnXZ2Vg)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 7374 This is a multi-part message in MIME format. --Boundary_(ID_zg3I/CHv+348TuvQnXZ2Vg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT LSARC, I am sponsoring this fast track for Elaine Xiong from the Mozilla team in Beijing. I have set the timeout for February 5th, 2008. The case materials contains this proposal. This project introduces SQLite 3.x into a Minor release of Solaris. The project includes the sqlite3, libraries, pkgconfig, header files and man page. The project is required by Firefox web browser and Thunderbird mail client. Thanks, John --Boundary_(ID_zg3I/CHv+348TuvQnXZ2Vg) Content-type: text/plain; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=proposal.txt 1. Introduction 1.1. Project/Component Working Name: SQLite 1.2. Name of Document Author/Supplier: Author: Elaine Xiong Sponsor: John Fischer 1.3. Date of This Document: 01/14/2008 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Robert Odea 1.4.4. The name of your business unit: Software 1.5. Email Aliases: 1.5.1. Responsible Manager: leo.binchy@sun.com 1.5.2. Responsible Engineer: elaine.xiong@sun.com 1.5.3. Marketing Manager: jeff.mcmeekin@sun.com 1.5.4. Interest List: brian.lu@sun.com 2. Project Summary 2.1. Project Description: SQLite is a C library that implements a small, fast, embeddable SQL database engine that supports most of SQL92, including transactions with atomic commit and rollback, subqueries, compound queries, triggers, and views. Programs that link with the SQLite library can have SQLite database access without running a separate RDBMS process. 2.2. Risks and Assumptions: SQLite is out of the support range of DBTG team only engaged in level 1 database technology, so we desktop team take responsible of shipping SQLite into Solaris. This project only proposes to fix bugs which affects Firefox3/Thunderbird3. The remainder counts on community development. 3. Business Summary 3.1. Problem Area: SQLite is utilized by Firefox3/Thunderbird3 to do all the storage which contains history and bookmarks, address books, download history and site specific preference. 3.3. Business Justification: The code for SQLite is in the public domain and is thus free for use for any purpose, commercial or private. Of level 2 database technologies for Sun products, SQLite is designed to be embedded in applications and in hardware. More and More well-known projects and companies turn to use SQLite as the in-process RDBMS. This project also fills the gap between Linux and Solaris since SQLite is released in many Linux distributions such as Unbuntu, Debian, and Fedora. 3.6. How will you know when you are done?: When it gets integrated into Solaris Neveda builds. 4. Technical Description: 4.1. Details: This project will port SQLite 3.x from the original community to Solaris. It involves shipping SQLite into Solaris Neveda, bug fixing regarding Firefox3/Thunderbird3 and performing the minor version upgrade from community. SQLite Features: - Transactions are atomic, consistent, isolated, and durable (ACID) even after system crashes and power failures. - Zero-configuration: no setup or administration needed. - Implements most of SQL92. Unsupported features of SQL92 are shown below. - FOREIGN KEY constraints - Complete trigger support - Complete ALTER TABLE support - Nested transactions - RIGHT and FULL OUTER JOIN - Writing to VIEWs - GRANT and REVOKE - A complete database is stored in a single cross-platform disk file. - Supports terabyte-sized databases and gigabyte-sized strings and blobs. - Small code footprint: less than 250KiB fully configured or less than 150KiB with optional features omitted. - Faster than popular client/server database engines for most common operations. - Simple, easy to use API. - Written in ANSI-C. - Well-commented source code with over 98% test coverage. - Available as a single ANSI-C source-code file that you can easily drop into another project. - Self-contained: no external dependencies. - Cross-platform - Sources are in the public domain. Use for any purpose. - Comes with a standalone command-line interface (CLI) client that can be used to administer SQLite databases. 4.5. Interfaces: Exported Interfaces Interface Classification Comments --------------- --------------- ----------------------- SQLite3 CLI Volatile SQLite3 API Volatile SQL92 features Volatile SQLite3 implements most of SQL92 and the unsupported features might be added in the future. /usr/bin/sqlite3 Volatile /usr/lib/libsqlite3.so Volatile /usr/lib/libsqlite3.so.0 Volatile /usr/lib/libsqlite3.so.0.8.6 Volatile /usr/lib/pkgconfig/sqlite3.pc Volatile /usr/include/sqlite3.h Volatile /usr/include/sqlite3ext.h Volatile /usr/share/man/man1/sqlite3.1 Volatile SUNWsqlite3 Uncommitted SUNWsqlite3-devel Uncommitted 4.6. Doc Impact: man page for sqlite3(1) 4.7. Admin/Config Impact: None 4.8. HA Impact: None 4.10. Packaging & Delivery: The new packages are: - SUNWsqlite3 - SUNWsqlite3-devel 4.11. Security Impact: SQLite itself as a backend storage is not encrypted or password-protected by default. Any project that uses SQLite should be aware of or enhance the security upon the specific requirement from the project purpose. A SQLite database is stored as a binary file which access control is performed by the underlying operating system based on the file's permission setting. 4.12. Dependencies: No external dependencies. 5. Reference Documents: SQLite Homepage - http://www.sqlite.org SQLite Development Page - http://www.sqlite.org/cvstrac/wiki SQL As Understood By SQLite - http://www.sqlite.org/lang.html SQLite C Interface - http://www.sqlite.org/c3ref/intro.html --Boundary_(ID_zg3I/CHv+348TuvQnXZ2Vg)-- From David.Comay@sun.com Tue Jan 29 15:18:04 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 m0TNI3bA001886 for ; Tue, 29 Jan 2008 15:18:04 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0TNHsAB004805 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Tue, 29 Jan 2008 23:18:03 GMT 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 <0JVF00G0DI22DV00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 29 Jan 2008 15:18:02 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVF00DXJI212D30@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 29 Jan 2008 15:18:01 -0800 (PST) Received: from izimbra.SFBay.Sun.COM (izimbra.SFBay.Sun.COM [129.146.226.141]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0TNI0TF008908; Tue, 29 Jan 2008 15:18:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0TNHxYN001952; Tue, 29 Jan 2008 15:18:00 -0800 (PST) Date: Tue, 29 Jan 2008 15:17:59 -0800 (PST) From: David.Comay@sun.com Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <479FAFE1.5020601@sun.com> Sender: David.Comay@sun.com To: John Fischer Cc: Elaine.Xiong@sun.com, Evan.Yan@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> Status: RO Content-Length: 758 > I am sponsoring this fast track for Elaine Xiong from the Mozilla > team in Beijing. I have set the timeout for February 5th, 2008. > The case materials contains this proposal. > > This project introduces SQLite 3.x into a Minor release of Solaris. > The project includes the sqlite3, libraries, pkgconfig, header files > and man page. The project is required by Firefox web browser and > Thunderbird mail client. I thought that the SQLite APIs CLIs and APIs were fairly stable across a release such as 3.x. Assuming that is the case, why the Volatile commitment level rather than something like Uncommitted? The former means that nothing can depend on these interfaces without a contract which makes for a fairly developer-unfriendly situation. dsc From Nicolas.Williams@sun.com Tue Jan 29 15:27:47 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 m0TNRkIx002098 for ; Tue, 29 Jan 2008 15:27:46 -0800 (PST) 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 m0TNRhVn063410; Tue, 29 Jan 2008 16:27:44 -0700 (MST) 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 <0JVF00M13II7PD00@brm-avmta-1.central.sun.com>; Tue, 29 Jan 2008 16:27:43 -0700 (MST) 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 <0JVF00KZJII62Z10@brm-avmta-1.central.sun.com>; Tue, 29 Jan 2008 16:27:42 -0700 (MST) 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 m0TNRg44015930; Tue, 29 Jan 2008 17:27:42 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0TNRgYd015929; Tue, 29 Jan 2008 17:27:42 -0600 (CST) Date: Tue, 29 Jan 2008 17:27:42 -0600 From: Nicolas Williams Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <479FAFE1.5020601@sun.com> To: John Fischer Cc: Elaine.Xiong@sun.com, Evan.Yan@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: <20080129232741.GE15877@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@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: 1636 On Tue, Jan 29, 2008 at 02:59:45PM -0800, John Fischer wrote: > SQLite3 CLI Volatile > SQLite3 API Volatile > SQL92 features Volatile SQLite3 implements most > of SQL92 and the unsupported > features might be added in > the future. > /usr/bin/sqlite3 Volatile > /usr/lib/libsqlite3.so Volatile > /usr/lib/libsqlite3.so.0 Volatile > /usr/lib/libsqlite3.so.0.8.6 Volatile > /usr/lib/pkgconfig/sqlite3.pc Volatile > /usr/include/sqlite3.h Volatile > /usr/include/sqlite3ext.h Volatile > /usr/share/man/man1/sqlite3.1 Volatile > SUNWsqlite3 Uncommitted > SUNWsqlite3-devel Uncommitted Excellent. For the record, Dr. Hipp recommends that all but simple apps be statically linked with SQLite: http://www.mail-archive.com/sqlite-users@sqlite.org/msg30561.html Of course, for all SQLite consumers in Solaris we can and should use dynamic linking. But we should consider providing a libsqlite3.a for third parties. We could say: if you want libsqlite3.a, then you build it yourself. Or we could just deliver libsqlite3.a. I don't care much which choice you make; perhaps you've already chosen the former, in which case there's no need to reply. In any case Volatile denotes the need to build your own if you want stability. Cheers, Nico -- From Nicolas.Williams@sun.com Tue Jan 29 16:00:23 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 m0U00NJG003457 for ; Tue, 29 Jan 2008 16:00:23 -0800 (PST) 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 m0U00KKT026541; Tue, 29 Jan 2008 16:00:20 -0800 (PST) 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 <0JVF00K53K0KIO00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Jan 2008 16:00:20 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVF00DEXK0I2C80@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Jan 2008 16:00:19 -0800 (PST) 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 m0U00FbN015968; Tue, 29 Jan 2008 18:00:15 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0U00FeO015967; Tue, 29 Jan 2008 18:00:15 -0600 (CST) Date: Tue, 29 Jan 2008 18:00:15 -0600 From: Nicolas Williams Subject: Re: LSARC/2008/059 - SQLite In-reply-to: To: David.Comay@sun.com Cc: Elaine.Xiong@sun.com, Evan.Yan@sun.com, "brian.lu" , John Fischer , lsarc-ext@sun.com Message-id: <20080130000014.GH15877@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080129233410.GG15877@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: 1364 [Adding the list again.] On Tue, Jan 29, 2008 at 03:46:33PM -0800, David.Comay@Sun.COM wrote: > >>I thought that the SQLite APIs CLIs and APIs were fairly stable across > >>a release such as 3.x. Assuming that is the case, why the Volatile > >>commitment level rather than something like Uncommitted? The former > >>means that nothing can depend on these interfaces without a contract > >>which makes for a fairly developer-unfriendly situation. > > > >See my reply just now. > > So the CLIs and APIs are not stable? Volatile is really weak - can't > we do better than that? IMO the SQLite community has been very good at keeping the CLI, the API, the ABI, and the file format stable. But they've created incompatibilities such as various limits on the sizes of SQL statements, and things of that sort that we might not want to ship at micro/patch binding if the interfaces were Committed. These incompatible behaviour changes are very unlikely to affect anyone though. Perhaps the i-team could say that the CLI/API/ABI/file format are Uncommitted and say that unspecified behaviours that "rise to the level of an interface" are Volatile. I'm not sure that the ARC has ever done anything like that though. Or perhaps the i-team could just go with Uncommitted. It's certainly easier for the i-team to use Volatile. I can't fault them for it. Nico -- From David.Comay@sun.com Tue Jan 29 16:11:21 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 m0U0BLg5003967 for ; Tue, 29 Jan 2008 16:11:21 -0800 (PST) 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 m0U0BLfN010559 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Tue, 29 Jan 2008 17:11:21 -0700 (MST) 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 <0JVF00201KIXYC00@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 29 Jan 2008 17:11:21 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVF00KSYKIW2S30@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Tue, 29 Jan 2008 17:11:20 -0700 (MST) Received: from izimbra.SFBay.Sun.COM (izimbra.SFBay.Sun.COM [129.146.226.141]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0U0BIEP023986; Tue, 29 Jan 2008 16:11:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0U0BIv7002002; Tue, 29 Jan 2008 16:11:18 -0800 (PST) Date: Tue, 29 Jan 2008 16:11:18 -0800 (PST) From: David.Comay@sun.com Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <20080130000014.GH15877@Sun.COM> Sender: David.Comay@sun.com To: Nicolas Williams Cc: Elaine.Xiong@sun.com, Evan.Yan@sun.com, "brian.lu" , John Fischer , lsarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080129233410.GG15877@Sun.COM> <20080130000014.GH15877@Sun.COM> Status: RO Content-Length: 888 Thanks for the explanation of where the SQLite community has been compatible and where it has not. > Perhaps the i-team could say that the CLI/API/ABI/file format are > Uncommitted and say that unspecified behaviours that "rise to the level > of an interface" are Volatile. I'm not sure that the ARC has ever done > anything like that though. Or perhaps the i-team could just go with > Uncommitted. > > It's certainly easier for the i-team to use Volatile. I can't fault > them for it. But then we risk having a situation similar to OpenSSL where there are many consumers for a Volatile set of interfaes. In the case of OpenSSL, I know the upstream community does not apparently have a good track record of compatibility so perhaps it's warranted. But in the case of SQLite, it seems a shame to do the same for a component that does seem to "do the right thing" in this area. dsc From Nicolas.Williams@sun.com Tue Jan 29 16:26:04 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 m0U0Q3XV004141 for ; Tue, 29 Jan 2008 16:26:04 -0800 (PST) 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 m0U0PsrW013627; Wed, 30 Jan 2008 08:25:59 +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 <0JVF00N03L792200@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Jan 2008 16:25:57 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVF00DONL792FB0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Jan 2008 16:25:57 -0800 (PST) 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 m0U0PvN6015983; Tue, 29 Jan 2008 18:25:57 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0U0Pvvs015982; Tue, 29 Jan 2008 18:25:57 -0600 (CST) Date: Tue, 29 Jan 2008 18:25:56 -0600 From: Nicolas Williams Subject: Re: LSARC/2008/059 - SQLite In-reply-to: To: David.Comay@sun.com Cc: Elaine.Xiong@sun.com, Evan.Yan@sun.com, "brian.lu" , John Fischer , lsarc-ext@sun.com Message-id: <20080130002556.GI15877@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080129233410.GG15877@Sun.COM> <20080130000014.GH15877@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: 2278 On Tue, Jan 29, 2008 at 04:11:18PM -0800, David.Comay@Sun.COM wrote: > Thanks for the explanation of where the SQLite community has been > compatible and where it has not. There's much more at the main site: http://sqlite.org/news.html http://sqlite.org/oldnews.html http://sqlite.org/formatchng.html In the 3.x series the relevant compatibility notes are: http://sqlite.org/oldnews.html#2007__un_18 http://sqlite.org/oldnews.html#2007__pr_25 http://sqlite.org/oldnews.html#2005__eb_01 http://sqlite.org/oldnews.html#2005__an_21 and the ones described in http://sqlite.org/formatchng.html I think that's a track record that speaks for itself. Also, some parts of the API are deprecated and some are experimental. The API docs (which aren't manpages, BTW), are clear about the stability attributes of the various interfaces. > >Perhaps the i-team could say that the CLI/API/ABI/file format are > >Uncommitted and say that unspecified behaviours that "rise to the level > >of an interface" are Volatile. I'm not sure that the ARC has ever done > >anything like that though. Or perhaps the i-team could just go with > >Uncommitted. > > > >It's certainly easier for the i-team to use Volatile. I can't fault > >them for it. > > But then we risk having a situation similar to OpenSSL where there are > many consumers for a Volatile set of interfaes. The problem with OpenSSL is the penchant in the OpenSSL for backwards-incompatible changes to the ABI and the fact that many consumers make use of private OpenSSL interfaces. That shouldn't happen here. > In the case of > OpenSSL, I know the upstream community does not apparently have a good > track record of compatibility so perhaps it's warranted. But in the > case of SQLite, it seems a shame to do the same for a component that > does seem to "do the right thing" in this area. I don't think using Volatile does that. Using Uncommitted might encourage more third-parties to use the SQLite shipped in Solaris. From a making-Solaris-easier-to-develop-on that seems to me like the right thing to do. BTW, the filesystem locations of the CLI, header and compilation link ought to be Committed. Same with the static linking archive, if we do ship it. Nico -- From carlsonj@phorcys.east.sun.com Wed Jan 30 06:09:14 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 m0UE9D1v019765 for ; Wed, 30 Jan 2008 06:09:13 -0800 (PST) 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 m0UE8t4t021811; Wed, 30 Jan 2008 22:09:06 +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 <0JVG00L1RNB4SR00@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Jan 2008 06:09:04 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVG00JQTNB1E310@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Jan 2008 06:09:02 -0800 (PST) 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 m0UE8k0n013233; Wed, 30 Jan 2008 09:08:52 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m0UE8emQ013230; Wed, 30 Jan 2008 09:08:40 -0500 (EST) Date: Wed, 30 Jan 2008 09:08:40 -0500 From: James Carlson Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <20080130002556.GI15877@Sun.COM> To: Nicolas Williams Cc: David.Comay@sun.com, John Fischer , Evan.Yan@sun.com, Elaine.Xiong@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: <18336.34024.292952.578060@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.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080129233410.GG15877@Sun.COM> <20080130000014.GH15877@Sun.COM> <20080130002556.GI15877@Sun.COM> Status: RO Content-Length: 1752 Nicolas Williams writes: > I think that's a track record that speaks for itself. > > Also, some parts of the API are deprecated and some are experimental. > The API docs (which aren't manpages, BTW), are clear about the stability > attributes of the various interfaces. In that case, we should make our stability attributes match the ones advertised by the software authors. Use "Uncommitted" or better for the things that are in fact stable, and "Volatile" and "Obsolete" for the experimental and deprecated parts. Just pass the upstream guarantees to the downstream users. I don't see a good reason to make things hard on future projects that might want to use these interfaces by making a lesser promise to Solaris users than the software author does. (It doesn't matter whether the documentation is in man page format, so I'm not sure I understand your parenthetic comment. Care to elaborate?) > I don't think using Volatile does that. Using Uncommitted might > encourage more third-parties to use the SQLite shipped in Solaris. From > a making-Solaris-easier-to-develop-on that seems to me like the right > thing to do. I certainly agree with that. > BTW, the filesystem locations of the CLI, header and compilation link > ought to be Committed. Same with the static linking archive, if we do > ship it. Indeed. The interfaces table is unclear. I *think* what was actually meant was that the interfaces provided by the CLI are Volatile, and not that the file system path itself was. But I can't tell. :-/ -- 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 Nicolas.Williams@sun.com Wed Jan 30 08:33:02 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 m0UGX1xn021930 for ; Wed, 30 Jan 2008 08:33:02 -0800 (PST) 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 m0UGWlFE016746; Thu, 31 Jan 2008 00:32:54 +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 <0JVG0064FTYR9H00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jan 2008 08:32:51 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVG0018NTYH4C30@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jan 2008 08:32:42 -0800 (PST) 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 m0UGWfVW016653; Wed, 30 Jan 2008 10:32:41 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0UGWfdR016652; Wed, 30 Jan 2008 10:32:41 -0600 (CST) Date: Wed, 30 Jan 2008 10:32:41 -0600 From: Nicolas Williams Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <18336.34024.292952.578060@gargle.gargle.HOWL> To: James Carlson Cc: David.Comay@sun.com, John Fischer , Evan.Yan@sun.com, Elaine.Xiong@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: <20080130163240.GQ15877@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080129233410.GG15877@Sun.COM> <20080130000014.GH15877@Sun.COM> <20080130002556.GI15877@Sun.COM> <18336.34024.292952.578060@gargle.gargle.HOWL> 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: 1897 On Wed, Jan 30, 2008 at 09:08:40AM -0500, James Carlson wrote: > Nicolas Williams writes: > > I think that's a track record that speaks for itself. > > > > Also, some parts of the API are deprecated and some are experimental. > > The API docs (which aren't manpages, BTW), are clear about the stability > > attributes of the various interfaces. > > In that case, we should make our stability attributes match the ones > advertised by the software authors. Use "Uncommitted" or better for > the things that are in fact stable, and "Volatile" and "Obsolete" for > the experimental and deprecated parts. Just pass the upstream > guarantees to the downstream users. I agree in this specific case, but should we generally do this where possible? The upstream community may have an interface stability taxonomy that is roughly compatible with ours, and maybe even a similar release binding taxonomy, but it's unlikely that their releases will be timed at all with ours. Or is that not a concern because if the upstream community makes "major" releases then we can just ship multiple versions of it in the next micro/patch release of Solaris (or OpenSolaris release vehicles)? Multiple versions of libraries can be problematic, after all, though I believe in most cases there's always reasonable guidance that can be given to avoid DLL hell. Is there precedent to set here? > I don't see a good reason to make things hard on future projects that > might want to use these interfaces by making a lesser promise to > Solaris users than the software author does. > > (It doesn't matter whether the documentation is in man page format, so > I'm not sure I understand your parenthetic comment. Care to > elaborate?) (I was worried that using anything other than Volatile might mean that the i-team would have to provide manpages, but I don't think that'd be the case. Can you confirm?) Nico -- From carlsonj@phorcys.east.sun.com Wed Jan 30 08:56:03 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 m0UGu25i022999 for ; Wed, 30 Jan 2008 08:56:03 -0800 (PST) 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 m0UGtiFG027661; Thu, 31 Jan 2008 00:55:57 +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 <0JVG00809V159W00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jan 2008 08:55:53 -0800 (PST) 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 <0JVG001VIV144C40@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jan 2008 08:55:52 -0800 (PST) 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 m0UGtmcd014055; Wed, 30 Jan 2008 11:55:52 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m0UGtj7a014052; Wed, 30 Jan 2008 11:55:45 -0500 (EST) Date: Wed, 30 Jan 2008 11:55:33 -0500 From: James Carlson Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <20080130163240.GQ15877@Sun.COM> To: Nicolas Williams Cc: John Fischer , "brian.lu" , Evan.Yan@sun.com, lsarc-ext@sun.com, Elaine.Xiong@sun.com Message-id: <18336.44037.231006.524428@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.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080129233410.GG15877@Sun.COM> <20080130000014.GH15877@Sun.COM> <20080130002556.GI15877@Sun.COM> <18336.34024.292952.578060@gargle.gargle.HOWL> <20080130163240.GQ15877@Sun.COM> Status: RO Content-Length: 3037 Nicolas Williams writes: > On Wed, Jan 30, 2008 at 09:08:40AM -0500, James Carlson wrote: > > In that case, we should make our stability attributes match the ones > > advertised by the software authors. Use "Uncommitted" or better for > > the things that are in fact stable, and "Volatile" and "Obsolete" for > > the experimental and deprecated parts. Just pass the upstream > > guarantees to the downstream users. > > I agree in this specific case, but should we generally do this where > possible? > > The upstream community may have an interface stability taxonomy that is > roughly compatible with ours, and maybe even a similar release binding > taxonomy, but it's unlikely that their releases will be timed at all > with ours. Unless that upstream is somehow committing directly to the local workspaces used to build the bits that appear in our releases, I don't see how that's a problem. > Or is that not a concern because if the upstream community makes "major" > releases then we can just ship multiple versions of it in the next > micro/patch release of Solaris (or OpenSolaris release vehicles)? > Multiple versions of libraries can be problematic, after all, though I > believe in most cases there's always reasonable guidance that can be > given to avoid DLL hell. In extreme cases, and where it was felt to be necessary, we've done exactly that. > Is there precedent to set here? I honestly don't see anything new here. These issues come up from time to time, and the answers are roughly the same. A good example of a similar case was with BIND (aka "named"). The submitter originally wanted to make it all External ("Volatile") on the theory that it's open source, we don't control it, we don't know what it is, and so on. It turns out that none of this was in fact true, and the desire to do this was just an attempt to avoid a bit of necessary work. The upstream supplier *DID* in fact separate the interfaces neatly into "we won't change," "we might change," and "we're certain to change" classes, and it was easy to map those into appropriate guarantees for Sun customers -- meaning, interface stability levels. Slapping on the "Volatile" label looks like an easy fix, but it really just pushes the work onto somebody else, and that's not quite fair. > > (It doesn't matter whether the documentation is in man page format, so > > I'm not sure I understand your parenthetic comment. Care to > > elaborate?) > > (I was worried that using anything other than Volatile might mean that > the i-team would have to provide manpages, but I don't think that'd be > the case. Can you confirm?) The official Solaris documentation is in man pages, but we've certainly made many exceptions in the past where the upstream provider doesn't support this. A good example of it was PKCS#11. -- 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 Nicolas.Williams@sun.com Wed Jan 30 09:46:15 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 m0UHkEXv025330 for ; Wed, 30 Jan 2008 09:46:15 -0800 (PST) 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 m0UHk65I003836; Wed, 30 Jan 2008 09:46:11 -0800 (PST) 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 <0JVG00I4RXCZXI00@brm-avmta-1.central.sun.com>; Wed, 30 Jan 2008 10:46:11 -0700 (MST) 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 <0JVG005DCXCXA5C0@brm-avmta-1.central.sun.com>; Wed, 30 Jan 2008 10:46:10 -0700 (MST) 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 m0UHk66e016721; Wed, 30 Jan 2008 11:46:06 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0UHk6nX016720; Wed, 30 Jan 2008 11:46:06 -0600 (CST) Date: Wed, 30 Jan 2008 11:46:06 -0600 From: Nicolas Williams Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <18336.44037.231006.524428@gargle.gargle.HOWL> To: James Carlson Cc: John Fischer , "brian.lu" , Evan.Yan@sun.com, lsarc-ext@sun.com, Elaine.Xiong@sun.com Message-id: <20080130174605.GR15877@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080129233410.GG15877@Sun.COM> <20080130000014.GH15877@Sun.COM> <20080130002556.GI15877@Sun.COM> <18336.34024.292952.578060@gargle.gargle.HOWL> <20080130163240.GQ15877@Sun.COM> <18336.44037.231006.524428@gargle.gargle.HOWL> 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: 2513 On Wed, Jan 30, 2008 at 11:55:33AM -0500, James Carlson wrote: > Nicolas Williams writes: > > On Wed, Jan 30, 2008 at 09:08:40AM -0500, James Carlson wrote: > > > Is there precedent to set here? > > I honestly don't see anything new here. These issues come up from > time to time, and the answers are roughly the same. > > A good example of a similar case was with BIND (aka "named"). The > submitter originally wanted to make it all External ("Volatile") on > the theory that it's open source, we don't control it, we don't know > what it is, and so on. > > It turns out that none of this was in fact true, and the desire to do > this was just an attempt to avoid a bit of necessary work. The > upstream supplier *DID* in fact separate the interfaces neatly into > "we won't change," "we might change," and "we're certain to change" > classes, and it was easy to map those into appropriate guarantees for > Sun customers -- meaning, interface stability levels. > > Slapping on the "Volatile" label looks like an easy fix, but it really > just pushes the work onto somebody else, and that's not quite fair. OK, then IMO we should use Uncommitted or even Committed for much of the SQLite 3.x CLI and API. We should probably have some warning in the docs about the possibility of revs where creating *new* databases or using new features may result in backwards-incompatible database formats (since that's the sort of incompatibility that's been introduced in the SQLite 3.x train). Should we include a static link archive? Or should we exhort developers to build their own when they want to avoid all possible risk? (Remember, Dr. Hipp recommends statically linking libsqlite into many apps.) IMO, yes, even if it means building libsqlite twice during the SFW consolidation build (I assume it will go into SFW). I'm not an ARC member, so my requests here can be freely ignored by the i-team. Feel free to ask them for better-than-Volatile classifications. > > (I was worried that using anything other than Volatile might mean that > > the i-team would have to provide manpages, but I don't think that'd be > > the case. Can you confirm?) > > The official Solaris documentation is in man pages, but we've > certainly made many exceptions in the past where the upstream provider > doesn't support this. A good example of it was PKCS#11. Thanks. (BTW, the SQLite HTML docs are also distributed as a tar ball, and could be shipped in /usr/share; including them is probably a good idea.) Nico -- From james.gates@sun.com Wed Jan 30 11:45: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 m0UJjbCt013579 for ; Wed, 30 Jan 2008 11:45:37 -0800 (PST) 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 m0UJjKUB005048 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 31 Jan 2008 03:45: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 <0JVH00F0P2VWSC00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 11:45:32 -0800 (PST) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVH0073M2VUZAE0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 11:45:31 -0800 (PST) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0UJjRgS029005; Wed, 30 Jan 2008 19:45:27 +0000 (GMT) Received: from [192.168.1.100] (vpn-129-150-66-161.East.Sun.COM [129.150.66.161]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m0UJj2UX001441; Wed, 30 Jan 2008 19:45:09 +0000 (GMT) Date: Wed, 30 Jan 2008 14:44:31 -0500 From: James Gates Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <479FAFE1.5020601@sun.com> To: John.Fischer@sun.com Cc: Elaine.Xiong@sun.com, Evan.Yan@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: <47A0D39F.1010204@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 8720 The compatibility information at http://sqlite.org/formatchng.html states that on disk file formats can change (albeit rarely) between major versions (first digit of version number). "When this happens and you must convert the contents of your databases into a portable ASCII representation using the old version of the library then reload the data using the new version of the library." In the future I assume we will want to update the version of SQLite shipped with Solaris? If there is an on disk format change all users will need to migrate their databases, which requires both the old & new versions of the library to be available. I don't see any mention or consideration for this in the case notes. That said, it seems that maybe all the path & package names in the interface table are suffixed (or include) with the major version. Is that right? When you integrate SQLite version 4.x will it be shipped in package SUNWsqlite4, and will the library be called /usr/lib/libsqlite4.so? If so, then it's possible the product is already future proof wrt. multiple major versions? If there's any name clashes between files from different versions, then you need to consider locating them somewhere other than /usr/bin, /usr/lib, /usr/include, etc. John Fischer wrote: > LSARC, > > I am sponsoring this fast track for Elaine Xiong from the Mozilla > team in Beijing. I have set the timeout for February 5th, 2008. > The case materials contains this proposal. > > This project introduces SQLite 3.x into a Minor release of Solaris. > The project includes the sqlite3, libraries, pkgconfig, header files > and man page. The project is required by Firefox web browser and > Thunderbird mail client. > > Thanks, > > John > > > ------------------------------------------------------------------------ > > > 1. Introduction > 1.1. Project/Component Working Name: > > SQLite > > 1.2. Name of Document Author/Supplier: > > Author: Elaine Xiong > Sponsor: John Fischer > > 1.3. Date of This Document: > > 01/14/2008 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC > 1.4.2. The ARC(s) you expect to review your project: LSARC > 1.4.3. The Director/VP who is "Sponsoring" this project: Robert Odea > 1.4.4. The name of your business unit: Software > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: leo.binchy@sun.com > 1.5.2. Responsible Engineer: elaine.xiong@sun.com > 1.5.3. Marketing Manager: jeff.mcmeekin@sun.com > 1.5.4. Interest List: brian.lu@sun.com > > 2. Project Summary > 2.1. Project Description: > > SQLite is a C library that implements a small, fast, embeddable SQL > database engine that supports most of SQL92, including transactions > with atomic commit and rollback, subqueries, compound queries, > triggers, and views. Programs that link with the SQLite library can > have SQLite database access without running a separate RDBMS process. > > 2.2. Risks and Assumptions: > > SQLite is out of the support range of DBTG team only engaged in level > 1 database technology, so we desktop team take responsible of shipping > SQLite into Solaris. This project only proposes to fix bugs which > affects Firefox3/Thunderbird3. The remainder counts on community > development. > > 3. Business Summary > 3.1. Problem Area: > > SQLite is utilized by Firefox3/Thunderbird3 to do all the storage > which contains history and bookmarks, address books, download > history and site specific preference. > > 3.3. Business Justification: > > The code for SQLite is in the public domain and is thus free for use > for any purpose, commercial or private. > > Of level 2 database technologies for Sun products, SQLite is designed > to be embedded in applications and in hardware. More and More well-known > projects and companies turn to use SQLite as the in-process RDBMS. This > project also fills the gap between Linux and Solaris since SQLite is > released in many Linux distributions such as Unbuntu, Debian, and Fedora. > > 3.6. How will you know when you are done?: > > When it gets integrated into Solaris Neveda builds. > > 4. Technical Description: > > 4.1. Details: > > This project will port SQLite 3.x from the original community to > Solaris. It involves shipping SQLite into Solaris Neveda, bug fixing > regarding Firefox3/Thunderbird3 and performing the minor version > upgrade from community. > > SQLite Features: > > - Transactions are atomic, consistent, isolated, and durable (ACID) > even after system crashes and power failures. > - Zero-configuration: no setup or administration needed. > - Implements most of SQL92. Unsupported features of SQL92 are > shown below. > - FOREIGN KEY constraints > - Complete trigger support > - Complete ALTER TABLE support > - Nested transactions > - RIGHT and FULL OUTER JOIN > - Writing to VIEWs > - GRANT and REVOKE > - A complete database is stored in a single cross-platform disk file. > - Supports terabyte-sized databases and gigabyte-sized strings and blobs. > - Small code footprint: less than 250KiB fully configured or less than > 150KiB with optional features omitted. > - Faster than popular client/server database engines for most common > operations. > - Simple, easy to use API. > - Written in ANSI-C. > - Well-commented source code with over 98% test coverage. > - Available as a single ANSI-C source-code file that you can easily drop > into another project. > - Self-contained: no external dependencies. > - Cross-platform > - Sources are in the public domain. Use for any purpose. > - Comes with a standalone command-line interface (CLI) client that can > be used to administer SQLite databases. > > 4.5. Interfaces: > > Exported Interfaces > Interface Classification Comments > --------------- --------------- ----------------------- > SQLite3 CLI Volatile > SQLite3 API Volatile > SQL92 features Volatile SQLite3 implements most > of SQL92 and the unsupported > features might be added in > the future. > /usr/bin/sqlite3 Volatile > /usr/lib/libsqlite3.so Volatile > /usr/lib/libsqlite3.so.0 Volatile > /usr/lib/libsqlite3.so.0.8.6 Volatile > /usr/lib/pkgconfig/sqlite3.pc Volatile > /usr/include/sqlite3.h Volatile > /usr/include/sqlite3ext.h Volatile > /usr/share/man/man1/sqlite3.1 Volatile > SUNWsqlite3 Uncommitted > SUNWsqlite3-devel Uncommitted > > > 4.6. Doc Impact: > > man page for sqlite3(1) > > 4.7. Admin/Config Impact: > > None > > 4.8. HA Impact: > > None > > 4.10. Packaging & Delivery: > > The new packages are: > - SUNWsqlite3 > - SUNWsqlite3-devel > > 4.11. Security Impact: > > SQLite itself as a backend storage is not encrypted or > password-protected by default. Any project that uses SQLite > should be aware of or enhance the security upon the specific > requirement from the project purpose. A SQLite database is > stored as a binary file which access control is performed by > the underlying operating system based on the file's permission > setting. > > 4.12. Dependencies: > > No external dependencies. > > 5. Reference Documents: > SQLite Homepage - http://www.sqlite.org > SQLite Development Page - http://www.sqlite.org/cvstrac/wiki > SQL As Understood By SQLite - http://www.sqlite.org/lang.html > SQLite C Interface - http://www.sqlite.org/c3ref/intro.html From Brian.Cameron@sun.com Wed Jan 30 13:52:03 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 m0ULq28C021712 for ; Wed, 30 Jan 2008 13:52:02 -0800 (PST) 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 m0ULpppq023199 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 31 Jan 2008 05:52:01 +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 <0JVH00C0Z8QMOZ00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 13:51:58 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVH000Y68QCIQ80@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 13:51:48 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0ULpmkl023326 for ; Wed, 30 Jan 2008 21:51:48 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVH007018DQA300@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 14:51:47 -0700 (MST) Received: from [192.168.1.191] ([200.78.19.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVH002DF8Q9CM90@mail-amer.sun.com>; Wed, 30 Jan 2008 14:51:46 -0700 (MST) Date: Wed, 30 Jan 2008 15:51:47 -0600 From: Brian Cameron Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <20080130163240.GQ15877@Sun.COM> Sender: Brian.Cameron@sun.com To: Nicolas Williams Cc: James Carlson , David.Comay@sun.com, John Fischer , Evan.Yan@sun.com, Elaine.Xiong@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: <47A0F173.6050903@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080129233410.GG15877@Sun.COM> <20080130000014.GH15877@Sun.COM> <20080130002556.GI15877@Sun.COM> <18336.34024.292952.578060@gargle.gargle.HOWL> <20080130163240.GQ15877@Sun.COM> User-Agent: Thunderbird 2.0.0.4 (X11/20070814) Status: RO Content-Length: 2717 >>> Also, some parts of the API are deprecated and some are experimental. >>> The API docs (which aren't manpages, BTW), are clear about the stability >>> attributes of the various interfaces. >> In that case, we should make our stability attributes match the ones >> advertised by the software authors. Use "Uncommitted" or better for >> the things that are in fact stable, and "Volatile" and "Obsolete" for >> the experimental and deprecated parts. Just pass the upstream >> guarantees to the downstream users. > > I agree in this specific case, but should we generally do this where > possible? > > The upstream community may have an interface stability taxonomy that is > roughly compatible with ours, and maybe even a similar release binding > taxonomy, but it's unlikely that their releases will be timed at all > with ours. I don't think external interface stability levels need to match Sun's stability levels. The GNOME community, for example, provides ABI compatibility for all libraries in the "GNOME Platform". However, we only support a subset of these as Committed in Solaris. This is for several reasons: - We feel a good GNOME application should be written with just the libraries we recommend - The JDS team is not interested in supporting the other libraries at a "Committed" or "Stable" level. - Some of the libraries (but not all) which we exclude have future planned deprecation dates. > Or is that not a concern because if the upstream community makes "major" > releases then we can just ship multiple versions of it in the next > micro/patch release of Solaris (or OpenSolaris release vehicles)? > Multiple versions of libraries can be problematic, after all, though I > believe in most cases there's always reasonable guidance that can be > given to avoid DLL hell. That is also a very real concern. Does Sun want to restrict what we can do in the future if the external community breaks ABI or has a different understanding of what stability means than we do? >> I don't see a good reason to make things hard on future projects that >> might want to use these interfaces by making a lesser promise to >> Solaris users than the software author does. >> >> (It doesn't matter whether the documentation is in man page format, so >> I'm not sure I understand your parenthetic comment. Care to >> elaborate?) > > (I was worried that using anything other than Volatile might mean that > the i-team would have to provide manpages, but I don't think that'd be > the case. Can you confirm?) I believe Volatile interfaces (as well as Uncommitted and Committed ones) are supposed to have manpages. Only private interfaces can avoid manpage documentation, I believe. Brian From Nicolas.Williams@sun.com Wed Jan 30 14:56:46 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 m0UMujsq026034 for ; Wed, 30 Jan 2008 14:56:46 -0800 (PST) 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 m0UMuJxf017374; Thu, 31 Jan 2008 06:56:36 +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 <0JVH00J07BQ94C00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jan 2008 14:56:33 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVH0007IBQ8IHD0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jan 2008 14:56:32 -0800 (PST) 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 m0UMuWSr017026; Wed, 30 Jan 2008 16:56:32 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0UMuVpv017025; Wed, 30 Jan 2008 16:56:31 -0600 (CST) Date: Wed, 30 Jan 2008 16:56:31 -0600 From: Nicolas Williams Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <47A0F173.6050903@sun.com> To: Brian Cameron Cc: James Carlson , David.Comay@sun.com, John Fischer , Evan.Yan@sun.com, Elaine.Xiong@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: <20080130225631.GF15877@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080129233410.GG15877@Sun.COM> <20080130000014.GH15877@Sun.COM> <20080130002556.GI15877@Sun.COM> <18336.34024.292952.578060@gargle.gargle.HOWL> <20080130163240.GQ15877@Sun.COM> <47A0F173.6050903@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: 1522 On Wed, Jan 30, 2008 at 03:51:47PM -0600, Brian Cameron wrote: > >Or is that not a concern because if the upstream community makes "major" > >releases then we can just ship multiple versions of it in the next > >micro/patch release of Solaris (or OpenSolaris release vehicles)? > >Multiple versions of libraries can be problematic, after all, though I > >believe in most cases there's always reasonable guidance that can be > >given to avoid DLL hell. > > That is also a very real concern. Does Sun want to restrict what we > can do in the future if the external community breaks ABI or has a > different understanding of what stability means than we do? No, that's what would happen here. If SQLite breaks compat we either ship multiple versions or hold back from upgrading until the next minor release of Solaris. We'd cross this bridge when we came to it, if we had to. > >(I was worried that using anything other than Volatile might mean that > >the i-team would have to provide manpages, but I don't think that'd be > >the case. Can you confirm?) > > I believe Volatile interfaces (as well as Uncommitted and Committed > ones) are supposed to have manpages. Only private interfaces can > avoid manpage documentation, I believe. James explained that this is not quite so. I think we would need a manpage for libsqlite with a URL to the actual docs, and a list of interface stabilities for the various functions ("these are Uncommitted," "these are Obsolete Volatile" and "the rest are Volatile"). Nico -- From David.Comay@sun.com Wed Jan 30 15:48:09 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 m0UNm8i0027884 for ; Wed, 30 Jan 2008 15:48:09 -0800 (PST) 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 m0UNm2M1007805 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Thu, 31 Jan 2008 07:48:07 +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 <0JVH00003E44XM00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Wed, 30 Jan 2008 15:48:04 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVH00M6WE43UR20@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Wed, 30 Jan 2008 15:48:03 -0800 (PST) Received: from izimbra.SFBay.Sun.COM (izimbra.SFBay.Sun.COM [129.146.226.141]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0UNm19Y040547; Wed, 30 Jan 2008 15:48:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by izimbra.SFBay.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m0UNm1wL003586; Wed, 30 Jan 2008 15:48:01 -0800 (PST) Date: Wed, 30 Jan 2008 15:48:00 -0800 (PST) From: David.Comay@sun.com Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <20080130225631.GF15877@Sun.COM> Sender: David.Comay@sun.com To: Nicolas Williams Cc: Brian Cameron , James Carlson , John Fischer , Evan.Yan@sun.com, Elaine.Xiong@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080129233410.GG15877@Sun.COM> <20080130000014.GH15877@Sun.COM> <20080130002556.GI15877@Sun.COM> <18336.34024.292952.578060@gargle.gargle.HOWL> <20080130163240.GQ15877@Sun.COM> <47A0F173.6050903@sun.com> <20080130225631.GF15877@Sun.COM> Status: RO Content-Length: 424 > James explained that this is not quite so. I think we would need a > manpage for libsqlite with a URL to the actual docs, and a list of > interface stabilities for the various functions ("these are > Uncommitted," "these are Obsolete Volatile" and "the rest are > Volatile"). This is in fact what generally is done in SFW, particularly for components that deliver their documentation via HTML or some other format. dsc From carlsonj@phorcys.east.sun.com Thu Jan 31 05:06:52 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 m0VD6qlJ016038 for ; Thu, 31 Jan 2008 05:06:52 -0800 (PST) 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 m0VD6lwi063865; Thu, 31 Jan 2008 06:06:48 -0700 (MST) 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 <0JVI00I03F3BX700@nwk-avmta-2.sfbay.sun.com>; Thu, 31 Jan 2008 05:06:47 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVI0061PF3A0UD0@nwk-avmta-2.sfbay.sun.com>; Thu, 31 Jan 2008 05:06:47 -0800 (PST) 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 m0VD6k47018010; Thu, 31 Jan 2008 08:06:46 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m0VD6kiV018007; Thu, 31 Jan 2008 08:06:46 -0500 (EST) Date: Thu, 31 Jan 2008 08:06:46 -0500 From: James Carlson Subject: Re: LSARC/2008/059 - SQLite In-reply-to: To: David.Comay@sun.com Cc: Nicolas Williams , Brian Cameron , John Fischer , Evan.Yan@sun.com, Elaine.Xiong@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: <18337.51174.281916.816962@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.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080129233410.GG15877@Sun.COM> <20080130000014.GH15877@Sun.COM> <20080130002556.GI15877@Sun.COM> <18336.34024.292952.578060@gargle.gargle.HOWL> <20080130163240.GQ15877@Sun.COM> <47A0F173.6050903@sun.com> <20080130225631.GF15877@Sun.COM> Status: RO Content-Length: 1714 David.Comay@Sun.COM writes: > > James explained that this is not quite so. I think we would need a > > manpage for libsqlite with a URL to the actual docs, and a list of > > interface stabilities for the various functions ("these are > > Uncommitted," "these are Obsolete Volatile" and "the rest are > > Volatile"). > > This is in fact what generally is done in SFW, particularly for > components that deliver their documentation via HTML or some other > format. Right. If you look at the interface taxonomy, it only says that you have to have some kind of documentation for public (Committed, Uncommitted, Volatile) interfaces. Adequate customer documentation must exist for all Public interfaces. It is strongly preferred that manual pages exist for all Public interfaces (supported on Solaris), even if only significant content of those pages are SYNOPSIS and ATTRIBUTES sections and a textual pointer to other documentation. Independent of the form of documentation delivery, the interface taxonomy commitment level must be presented to the consumer. The usual rule is that Committed gets a man page, Uncommitted gets a man page with warnings, and Volatile might not have a man page entry at all, but instead could have a white paper, blog entry, or some other less definitive specification. Private intentionally doesn't have documentation, and if it does (because the interface is particularly "noticeable"), then it just says "no user serviceable parts inside." -- 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 Nicolas.Williams@sun.com Thu Jan 31 10:20:54 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 m0VIKsFw028219 for ; Thu, 31 Jan 2008 10:20:54 -0800 (PST) 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 m0VIKpPt006526; Thu, 31 Jan 2008 10:20:52 -0800 (PST) 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 <0JVI00705TMRNO00@nwk-avmta-2.sfbay.sun.com>; Thu, 31 Jan 2008 10:20:51 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVI00K4ZTMQS6F0@nwk-avmta-2.sfbay.sun.com>; Thu, 31 Jan 2008 10:20:50 -0800 (PST) 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 m0VIKnZF017477; Thu, 31 Jan 2008 12:20:49 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m0VIKnTP017476; Thu, 31 Jan 2008 12:20:49 -0600 (CST) Date: Thu, 31 Jan 2008 12:20:49 -0600 From: Nicolas Williams Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <479FAFE1.5020601@sun.com> To: John Fischer Cc: Elaine.Xiong@sun.com, Evan.Yan@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: <20080131182049.GA15877@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@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: 2339 On Tue, Jan 29, 2008 at 02:59:45PM -0800, John Fischer wrote: > 4.5. Interfaces: > > Exported Interfaces > Interface Classification Comments > --------------- --------------- ----------------------- > SQLite3 CLI Volatile > SQLite3 API Volatile > SQL92 features Volatile SQLite3 implements most > of SQL92 and the unsupported > features might be added in > the future. I would like the actual classification to be better than Volatile for any SQLite 3.x interfaces that are stable according to the SQLite 3.x documentation (i.e., not explicitly called out as obsolete or experimental). I don't think all those interfaces need be listed here. Just the version of SQLite 3.x from whose documentation the stabilities will be derived and the algorithm (e.g., "stable in SQLite -> Uncommitted, or even Committed; obsolete in SQLite -> Obsolete Volatile; experimental in SQLite -> Volatile; private in SQLite -> Project Private") will do, methinks. I'm not an ARC member. Will an ARC member make this request on my behalf? > /usr/bin/sqlite3 Volatile > /usr/lib/libsqlite3.so Volatile > /usr/lib/libsqlite3.so.0 Volatile > /usr/lib/libsqlite3.so.0.8.6 Volatile ^^^^^ What's "0.8.6"? > /usr/lib/pkgconfig/sqlite3.pc Volatile > /usr/include/sqlite3.h Volatile > /usr/include/sqlite3ext.h Volatile > /usr/share/man/man1/sqlite3.1 Volatile All the above path names should be Committed, except the versioned .so paths. I'm not an ARC member. Will an ARC member make this request on my behalf? > 4.6. Doc Impact: > > man page for sqlite3(1) There should be a manpage for the library as well (the actual functions types and macros need not be documented in any manpages though). Will the SQLite3.x HTML documentation be delivered as well? I think that would be useful. I'm not an ARC member. Will an ARC member make this request on my behalf? Thanks, Nico -- From John.Plocher@sun.com Thu Jan 31 11:19:22 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 m0VJJLdq000343 for ; Thu, 31 Jan 2008 11:19:21 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0VJJJM5008362 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 31 Jan 2008 19:19:20 GMT 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 <0JVI0030JWC6D100@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 31 Jan 2008 12:19:18 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVI00F4WWC3OC80@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 31 Jan 2008 12:19:15 -0700 (MST) 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 m0VJJF9S009765 for ; Thu, 31 Jan 2008 11:19:15 -0800 (PST) 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 <0JVI00N01W4K0E00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 31 Jan 2008 11:19:15 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVI00MLXWC105B0@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 31 Jan 2008 11:19:14 -0800 (PST) Date: Thu, 31 Jan 2008 11:19:13 -0800 From: John Plocher Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <20080131182049.GA15877@Sun.COM> Sender: John.Plocher@sun.com To: Nicolas Williams Cc: John Fischer , Evan.Yan@sun.com, Elaine.Xiong@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: <47A21F31.40809@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 259 Nicolas Williams wrote: > Just the > version of SQLite 3.x from whose documentation the stabilities will be > derived and the algorithm ... > > I'm not an ARC member. Will an ARC member make this request on my > behalf? Done - what he said :-) -John From Elaine.Xiong@sun.com Fri Feb 1 00:39: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 m118dNnX024586 for ; Fri, 1 Feb 2008 00:39:23 -0800 (PST) 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 m118dIYi035784 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 01:39:23 -0700 (MST) 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 <0JVJ00817XDLAM00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 00:39:21 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVJ002UDXDKN9A0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 00:39:21 -0800 (PST) Received: from fe-apac-04.sun.com (fe-apac-04.sun.com [192.18.19.175] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m118dLND000148 for ; Fri, 01 Feb 2008 08:39:21 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JVJ00I01XBTBN00@mail-apac.sun.com> (original mail from Elaine.Xiong@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 16:39:19 +0800 (SGT) Received: from [129.158.217.86] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JVJ004PZXDIAR10@mail-apac.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 16:39:19 +0800 (SGT) Date: Fri, 01 Feb 2008 16:37:08 +0800 From: Elaine Xiong Subject: Re: LSARC/2008/059 - SQLite In-reply-to: <20080131182049.GA15877@Sun.COM> Sender: Elaine.Xiong@sun.com To: Nicolas Williams Cc: John Fischer , Evan.Yan@sun.com, "brian.lu" , lsarc-ext@sun.com Message-id: <47A2DA34.5060807@sun.com> MIME-version: 1.0 Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071009) Status: RO Content-Length: 3917 Please see my comments inline.

Best Regards,
Elaine

Nicolas Williams wrote: 
On Tue, Jan 29, 2008 at 02:59:45PM -0800, John Fischer wrote:
  
    4.5. Interfaces:
                 
         Exported Interfaces
        Interface               Classification            Comments
    ---------------             ---------------    -----------------------
    SQLite3 CLI                     Volatile
    SQLite3 API                     Volatile
    SQL92 features                  Volatile       SQLite3 implements most 
                                                   of SQL92 and the unsupported 
                                                   features might be added in 
                                                   the future.
    

I would like the actual classification to be better than Volatile for
any SQLite 3.x interfaces that are stable according to the SQLite 3.x
documentation (i.e., not explicitly called out as obsolete or
experimental).
We browser team have no resource to support SQLite 3.x as higher levels than "Volatile". 
If any other team wants to use these pkgs they should fix SQLite bugs found in their products. We browser team doesn't have resources to fix such kind of bugs. We need to point this out in the contracts. So that's why we choose "Volatile". For the APIs stable or not , we would give a link in the manpage.
I don't think all those interfaces need be listed here.  Just the
version of SQLite 3.x from whose documentation the stabilities will be
derived and the algorithm (e.g., "stable in SQLite -> Uncommitted, or
even Committed; obsolete in SQLite -> Obsolete Volatile; experimental in
SQLite -> Volatile; private in SQLite -> Project Private") will do,
methinks.

I'm not an ARC member.  Will an ARC member make this request on my
behalf?

  
    /usr/bin/sqlite3                Volatile      
    /usr/lib/libsqlite3.so          Volatile       
    /usr/lib/libsqlite3.so.0        Volatile       
    /usr/lib/libsqlite3.so.0.8.6    Volatile       
    
                             ^^^^^
What's "0.8.6"?
It's a library version.

  

    
    /usr/lib/pkgconfig/sqlite3.pc   Volatile
    /usr/include/sqlite3.h          Volatile
    /usr/include/sqlite3ext.h       Volatile    
    /usr/share/man/man1/sqlite3.1   Volatile
    

  

  

All the above path names should be Committed, except the versioned .so
paths.

I'm not an ARC member.  Will an ARC member make this request on my
behalf?

  

  

    
    4.6. Doc Impact:

         man page for sqlite3(1)
    

  

  

There should be a manpage for the library as well (the actual functions
types and macros need not be documented in any manpages though).

Will the SQLite3.x HTML documentation be delivered as well?  I think
that would be useful.
  



We don't ship the HTML docs.



  
I'm not an ARC member.  Will an ARC member make this request on my
behalf? 

Thanks,

Nico
  








From Nicolas.Williams@sun.com Fri Feb  1 01:00:47 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 m1190k1m025273
	for ; Fri, 1 Feb 2008 01:00:46 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1190Xua018448;
	Fri, 1 Feb 2008 09:00:41 GMT
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 <0JVJ00A0JYD2E400@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 01 Feb 2008 01:00:38 -0800 (PST)
Received: from binky.Central.Sun.COM ([129.153.128.104])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVJ0025VYD1MXB0@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 01 Feb 2008 01:00:38 -0800 (PST)
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 m1190Y5r019728;
 Fri, 01 Feb 2008 03:00:34 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1190Ygj019727; Fri,
 01 Feb 2008 03:00:34 -0600 (CST)
Date: Fri, 01 Feb 2008 03:00:34 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A2DA34.5060807@sun.com>
To: Elaine Xiong 
Cc: John Fischer , Evan.Yan@sun.com,
        "brian.lu" , lsarc-ext@sun.com
Message-id: <20080201090033.GA19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@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: 511


It will cost very little extra work to make a list of interfaces and
stabilities now.  And if the SQLite community sticks to its track record
to date then going with better than Volatile should cost very little
extra work to update SQLite releases in the future.

The only way this can require extra resources is if the SQLite community
lets us down.  It *could* happen.  I just don't think it likely given
their track record.

As for the library version number, I cannot tell where 0.8.6 came from.

Nico
-- 

From Elaine.Xiong@sun.com Fri Feb  1 01:46:05 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 m119k4dT025890
	for ; Fri, 1 Feb 2008 01:46:05 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m119jx0Y005619
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 09:46:03 GMT
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 <0JVK00L0A0GRRI00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 02:46:03 -0700 (MST)
Received: from sineb-mail-2.sun.com ([192.18.19.7])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK008OZ0GPH580@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 02:46:02 -0700 (MST)
Received: from fe-apac-05.sun.com
 (fe-apac-05.sun.com [192.18.19.176] (may be forged))
	by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m119k399004777	for
 ; Fri, 01 Feb 2008 09:46:03 +0000 (GMT)
Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 id <0JVK00L0109K2K00@mail-apac.sun.com>
 (original mail from Elaine.Xiong@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 17:46:01 +0800 (SGT)
Received: from [129.158.217.86] by mail-apac.sun.com
 (Sun Java System Messaging Server 6.2-6.01 (built Apr  3 2006))
 with ESMTPSA id <0JVK0037E0GOMWEQ@mail-apac.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 17:46:01 +0800 (SGT)
Date: Fri, 01 Feb 2008 17:43:50 +0800
From: Elaine Xiong 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <20080201090033.GA19708@Sun.COM>
Sender: Elaine.Xiong@sun.com
To: Nicolas Williams 
Cc: John Fischer , Evan.Yan@sun.com,
        "brian.lu" , lsarc-ext@sun.com
Message-id: <47A2E9D6.6020401@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <20080201090033.GA19708@Sun.COM>
User-Agent: Thunderbird 2.0.0.6 (X11/20071009)
Status: RO
Content-Length: 952

Nicolas Williams wrote:
> It will cost very little extra work to make a list of interfaces and
> stabilities now.  And if the SQLite community sticks to its track record
> to date then going with better than Volatile should cost very little
> extra work to update SQLite releases in the future.
>   
We will do upgrade SQLite minor releases even the interfaces are
"Volatile". Any interface marked with "Uncommitted" or "Committed" shows
no contracted needed to use it. But we do need the contracts to state
the following

We only fix bugs affecting Firefox3/Thunderbird3 and do minor upgrade.
> The only way this can require extra resources is if the SQLite community
> lets us down.  It *could* happen.  I just don't think it likely given
> their track record.
>
> As for the library version number, I cannot tell where 0.8.6 came from.
>   
It's just a share library version like /usr/lib/libgtk-x11-2.0.so.0.1200.0
> Nico
>   
Best Regards,
Elaine

From Nicolas.Williams@sun.com Fri Feb  1 08:34:14 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 m11GYDtA004137
	for ; Fri, 1 Feb 2008 08:34:14 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11GY5lU024875;
	Fri, 1 Feb 2008 16:34:09 GMT
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 <0JVK00625JCWTT00@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 09:34:08 -0700 (MST)
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 <0JVK005U3JCURF00@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 09:34:07 -0700 (MST)
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 m11GY6ZX019935;
 Fri, 01 Feb 2008 10:34:06 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m11GY679019934; Fri,
 01 Feb 2008 10:34:06 -0600 (CST)
Date: Fri, 01 Feb 2008 10:34:06 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A2E9D6.6020401@sun.com>
To: Elaine Xiong 
Cc: John Fischer , Evan.Yan@sun.com,
        "brian.lu" , lsarc-ext@sun.com
Message-id: <20080201163406.GB19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <20080201090033.GA19708@Sun.COM>
 <47A2E9D6.6020401@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: 2089

On Fri, Feb 01, 2008 at 05:43:50PM +0800, Elaine Xiong wrote:
> Nicolas Williams wrote:
> > It will cost very little extra work to make a list of interfaces and
> > stabilities now.  And if the SQLite community sticks to its track record
> > to date then going with better than Volatile should cost very little
> > extra work to update SQLite releases in the future.
> >   
> We will do upgrade SQLite minor releases even the interfaces are
> "Volatile". Any interface marked with "Uncommitted" or "Committed" shows
> no contracted needed to use it. But we do need the contracts to state
> the following
> 
> We only fix bugs affecting Firefox3/Thunderbird3 and do minor upgrade.

I don't understand what that statement has to do with interface
stability.

Also, is there anything to prevent another team from fixing SQLite bugs
(e.g., by updating to a newer release) affecting their use of SQLite?
I can't imagine that there would be.

SQLite being a level 2 DB technology for use in Sun projects it strikes
me that you cannot prevent others from fixing bugs in it since they are
free to use it, unless you make it some flavor of Private.

Now, by going with Volatile you risk some other team breaking Firefox3/
Thunderbird3 when they update SQLite.  By using stronger interface
stabilities or interface contracts you protect yourself.

Now, the likelihood of incompatible changes to SQLite (that are not
subsequently fixed) is very low, so maybe this argument is pointless,
but in either case stronger interface stability statements are better,
particularly if my forecast of SQLite stability is wrong.

> > The only way this can require extra resources is if the SQLite community
> > lets us down.  It *could* happen.  I just don't think it likely given
> > their track record.
> >
> > As for the library version number, I cannot tell where 0.8.6 came from.
> >   
> It's just a share library version like /usr/lib/libgtk-x11-2.0.so.0.1200.0

But it doesn't come from SQLite.  Why not use 1, or 5.5, or whatever
the SQLite version number is (the latest is 3.5.5)?  Why 0.8.6?

Nico
-- 

From John.Plocher@sun.com Fri Feb  1 09:13:06 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 m11HD5O0005616
	for ; Fri, 1 Feb 2008 09:13:05 -0800 (PST)
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 m11HCCZ5016084
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Sat, 2 Feb 2008 01:13:04 +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 <0JVK00A22L5OPV00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 09:13:00 -0800 (PST)
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 <0JVK00057L5NQS90@nwk-avmta-1.sfbay.Sun.COM> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 09:12:59 -0800 (PST)
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 m11HCxQv029530	for
 ; Fri, 01 Feb 2008 09:12:59 -0800 (PST)
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 <0JVK00G01KNJNX00@fe-sfbay-10.sun.com>
 (original mail from John.Plocher@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 09:12:59 -0800 (PST)
Received: from [192.168.168.4] ([208.74.177.212])
 by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JVK00GDJL582M50@fe-sfbay-10.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 09:12:45 -0800 (PST)
Date: Fri, 01 Feb 2008 09:12:44 -0800
From: John Plocher 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A2DA34.5060807@sun.com>
Sender: John.Plocher@sun.com
To: Elaine Xiong 
Cc: Nicolas Williams ,
        John Fischer , Evan.Yan@sun.com,
        "brian.lu" , lsarc-ext@sun.com
Message-id: <47A3530C.6010808@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
Status: RO
Content-Length: 702

Elaine Xiong wrote:
> We browser team have no resource to support SQLite 3.x as higher levels 
> than "Volatile". 

The interface taxonomy is NOT an indication of Sun Support levels (i.e.,
backline, service, sustaining), but instead an indication of how Sun will
manage future interface evolution.  For projects that come from the outside,
we are setting a combination of expectations:

	We will follow the providing community's lead

	We reflect what that community promises

	We will provide a best effort to adhere to these expectations
	  in the face of unexpected community changes by factoring them
	  into our decisions whether and when to adopt newer versions
	  from the community.

   -John


From Brian.Cameron@sun.com Fri Feb  1 11:49:39 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 m11JndIA013836
	for ; Fri, 1 Feb 2008 11:49:39 -0800 (PST)
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 m11Jnc1C039289
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 12:49:38 -0700 (MST)
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 <0JVK00M09SEQ2X00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 12:49:38 -0700 (MST)
Received: from brmea-mail-3.sun.com ([192.18.98.34])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK005WDSEPRGC0@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 12:49:37 -0700 (MST)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m11JnbwL008899	for
 ; Fri, 01 Feb 2008 19:49:37 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVK00H01PZKA800@mail-amer.sun.com>
 (original mail from Brian.Cameron@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 12:49:37 -0700 (MST)
Received: from [192.168.1.77] ([189.147.109.48])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JVK003KFSEDIP10@mail-amer.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 12:49:27 -0700 (MST)
Date: Fri, 01 Feb 2008 13:49:29 -0600
From: Brian Cameron 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3530C.6010808@Sun.Com>
Sender: Brian.Cameron@sun.com
To: John Plocher 
Cc: Elaine Xiong ,
        Nicolas Williams ,
        John Fischer , Evan.Yan@sun.com,
        "brian.lu" , lsarc-ext@sun.com
Message-id: <47A377C9.3030808@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
User-Agent: Thunderbird 2.0.0.9 (X11/20080128)
Status: RO
Content-Length: 1255


Elaine/John:

>> We browser team have no resource to support SQLite 3.x as higher 
>> levels than "Volatile". 
> 
> The interface taxonomy is NOT an indication of Sun Support levels (i.e.,
> backline, service, sustaining), but instead an indication of how Sun will
> manage future interface evolution.  For projects that come from the 
> outside, we are setting a combination of expectations:

I believe the main reason the JDS team wants these interfaces to be
Volatile is so that other Sun groups that wish to depend on the
interfaces sign contracts with us.  This way the JDS team can manage
the interfaces moving forward.  The JDS team does not want other
teams to depend on interfaces, then get hit by a bug, and expect
the JDS team to fix their bugs for them.

As has been pointed out, there is no reason other teams can't work
directly with the SQLite project to make it work for their needs.
If they have a contract in place with the JDS team, then they can
expect our team to work with them to help avoid problems on upgrade.

For example, we would provide them with pre-release test packages
so they can make sure their project works with the new release
before it goes into Nevada, and work with us to fix any bugs that
might be found.

Brian

From Nicolas.Williams@sun.com Fri Feb  1 12:10:00 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 m11K9xGd014766
	for ; Fri, 1 Feb 2008 12:10:00 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11K9qh4006999;
	Fri, 1 Feb 2008 20:09:53 GMT
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 <0JVK00001TCFHZ00@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 13:09:51 -0700 (MST)
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 <0JVK0051XTCERLD0@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 13:09:51 -0700 (MST)
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 m11K9oC4020147;
 Fri, 01 Feb 2008 14:09:50 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m11K9ogP020146; Fri,
 01 Feb 2008 14:09:50 -0600 (CST)
Date: Fri, 01 Feb 2008 14:09:50 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A377C9.3030808@sun.com>
To: Brian Cameron 
Cc: John Plocher , Elaine Xiong ,
        John Fischer , Evan.Yan@sun.com,
        "brian.lu" , lsarc-ext@sun.com
Message-id: <20080201200950.GJ19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@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: 1132

On Fri, Feb 01, 2008 at 01:49:29PM -0600, Brian Cameron wrote:
> I believe the main reason the JDS team wants these interfaces to be
> Volatile is so that other Sun groups that wish to depend on the
> interfaces sign contracts with us.  This way the JDS team can manage
> the interfaces moving forward.  The JDS team does not want other
> teams to depend on interfaces, then get hit by a bug, and expect
> the JDS team to fix their bugs for them.
> 
> As has been pointed out, there is no reason other teams can't work
> directly with the SQLite project to make it work for their needs.
> If they have a contract in place with the JDS team, then they can
> expect our team to work with them to help avoid problems on upgrade.

Making this Volatile does not achieve what you describe (causing others
to have to sign contracts with the JDS team).

> For example, we would provide them with pre-release test packages
> so they can make sure their project works with the new release
> before it goes into Nevada, and work with us to fix any bugs that
> might be found.

Going with Uncommitted or Committed would save you all this work.

From Nicolas.Williams@sun.com Fri Feb  1 12:22:25 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 m11KMOCU016320
	for ; Fri, 1 Feb 2008 12:22:25 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11KMCvD012055;
	Fri, 1 Feb 2008 20:22:18 GMT
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 <0JVK00503TX59V00@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 01 Feb 2008 12:22:17 -0800 (PST)
Received: from binky.Central.Sun.COM ([129.153.128.104])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK00KJFTX4BD60@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 01 Feb 2008 12:22:17 -0800 (PST)
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 m11KMG3p020158;
 Fri, 01 Feb 2008 14:22:16 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m11KMGfc020157; Fri,
 01 Feb 2008 14:22:16 -0600 (CST)
Date: Fri, 01 Feb 2008 14:22:16 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <20080201200950.GJ19708@Sun.COM>
To: Brian Cameron 
Cc: John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <20080201202216.GK19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@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: 1275

On Fri, Feb 01, 2008 at 02:09:50PM -0600, Nicolas Williams wrote:
> On Fri, Feb 01, 2008 at 01:49:29PM -0600, Brian Cameron wrote:
> > I believe the main reason the JDS team wants these interfaces to be
> > Volatile is so that other Sun groups that wish to depend on the
> > interfaces sign contracts with us.  This way the JDS team can manage
> > the interfaces moving forward.  The JDS team does not want other
> > teams to depend on interfaces, then get hit by a bug, and expect
> > the JDS team to fix their bugs for them.
> > 
> > As has been pointed out, there is no reason other teams can't work
> > directly with the SQLite project to make it work for their needs.
> > If they have a contract in place with the JDS team, then they can
> > expect our team to work with them to help avoid problems on upgrade.
> 
> Making this Volatile does not achieve what you describe (causing others
> to have to sign contracts with the JDS team).

Ah, no, that's wrong.  The taxonomy says:

    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.

It would still, however, save work to mark the stable parts of the API
as Uncommitted.

Nico
-- 

From Brian.Cameron@sun.com Fri Feb  1 12:26:10 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 m11KQAMS016359
	for ; Fri, 1 Feb 2008 12:26:10 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m11KQ60r003490
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 12:26:10 -0800 (PST)
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 <0JVK0010DU3LXT00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 13:26:09 -0700 (MST)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK005L4U3KRSD0@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 13:26:08 -0700 (MST)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m11KQ85E027781	for
 ; Fri, 01 Feb 2008 20:26:08 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVK00H01SONJ200@mail-amer.sun.com>
 (original mail from Brian.Cameron@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 13:26:08 -0700 (MST)
Received: from [192.168.1.77] ([189.147.109.48])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JVK0034KU2VGQ70@mail-amer.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 13:25:46 -0700 (MST)
Date: Fri, 01 Feb 2008 14:25:48 -0600
From: Brian Cameron 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <20080201202216.GK19708@Sun.COM>
Sender: Brian.Cameron@sun.com
To: Nicolas Williams 
Cc: John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <47A3804C.1060904@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM>
User-Agent: Thunderbird 2.0.0.9 (X11/20080128)
Status: RO
Content-Length: 377


Nicolas:

> It would still, however, save work to mark the stable parts of the API
> as Uncommitted.

What work would be saved, exactly?

Also, it would make more work if we find, in fact, the interfaces are
not as stable enough to meet Sun's understanding of "Uncommitted"
(which means that the interfaces can't change in Solars 11, but only
in Solaris 12 or later).

Brian


From Nicolas.Williams@sun.com Fri Feb  1 12:40:31 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 m11KeVm0017484
	for ; Fri, 1 Feb 2008 12:40:31 -0800 (PST)
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 m11KeSFe050978;
	Fri, 1 Feb 2008 13:40:28 -0700 (MST)
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 <0JVK0030LURF1T00@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 13:40:27 -0700 (MST)
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 <0JVK0054RURERNF0@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 13:40:26 -0700 (MST)
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 m11KeMo5020199;
 Fri, 01 Feb 2008 14:40:22 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m11KeM80020198; Fri,
 01 Feb 2008 14:40:22 -0600 (CST)
Date: Fri, 01 Feb 2008 14:40:22 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3804C.1060904@sun.com>
To: Brian Cameron 
Cc: John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <20080201204022.GM19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@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: 838

On Fri, Feb 01, 2008 at 02:25:48PM -0600, Brian Cameron wrote:
> Nicolas:
> >It would still, however, save work to mark the stable parts of the API
> >as Uncommitted.
> 
> What work would be saved, exactly?

Negotiating contracts, informing contract holders of updates.  The
trade-off is that it would require checking the release notes of SQLite
(at least) to see if any Uncommitted interfaces have changed
incompatibly.

> Also, it would make more work if we find, in fact, the interfaces are
> not as stable enough to meet Sun's understanding of "Uncommitted"
> (which means that the interfaces can't change in Solars 11, but only
> in Solaris 12 or later).

Except that the community's track record leaves little doubt that the
likelihood of this is low.  And if it happens then in the worst case
we'd have to ship multiple versions.

From carlsonj@phorcys.east.sun.com Fri Feb  1 12:43: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 m11Khdum017749
	for ; Fri, 1 Feb 2008 12:43:39 -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 m11KhTAW016589;
	Sat, 2 Feb 2008 04:43:34 +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 <0JVK00307UWJ9J00@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 13:43:31 -0700 (MST)
Received: from phorcys.east.sun.com ([129.148.174.143])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK005SVUWIRGE0@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 13:43:30 -0700 (MST)
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 m11KhUs6012540; Fri,
 01 Feb 2008 15:43:30 -0500 (EST)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m11KhTv6012537; Fri,
 01 Feb 2008 15:43:29 -0500 (EST)
Date: Fri, 01 Feb 2008 15:43:29 -0500
From: James Carlson 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3804C.1060904@sun.com>
To: Brian Cameron 
Cc: Nicolas Williams ,
        John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <18339.33905.579484.232922@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.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
Status: RO
Content-Length: 1000

Brian Cameron writes:
> Also, it would make more work if we find, in fact, the interfaces are
> not as stable enough to meet Sun's understanding of "Uncommitted"
> (which means that the interfaces can't change in Solars 11, but only
> in Solaris 12 or later).

Marking it "Uncommitted" means that you wouldn't be able to place
_incompatible_ changes into patches.

It doesn't constrain the release under development, it doesn't stop
compatible changes, and it doesn't mean that mistakes will never
happen.  (In other words, we try our best, but if breakage happens
anyway, then we consider it a bug and fix it.)

Use Volatile only if you really feel you need to ship patches that
have intentionally incompatible changes.  It's a loaded weapon aimed
squarely at the user.  :-/

-- 
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 carlsonj@phorcys.east.sun.com Fri Feb  1 12:51:50 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 m11KpnBv017895
	for ; Fri, 1 Feb 2008 12:51:49 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11Kpd1Q022032;
	Fri, 1 Feb 2008 20:51:42 GMT
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 <0JVK00803VA39E00@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 01 Feb 2008 12:51:39 -0800 (PST)
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 <0JVK00K01VA2BC80@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 01 Feb 2008 12:51:39 -0800 (PST)
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 m11Kpcmk012574; Fri,
 01 Feb 2008 15:51:38 -0500 (EST)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m11KpcOI012571; Fri,
 01 Feb 2008 15:51:38 -0500 (EST)
Date: Fri, 01 Feb 2008 15:51:37 -0500
From: James Carlson 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A377C9.3030808@sun.com>
To: Brian Cameron 
Cc: John Plocher , John Fischer ,
        "brian.lu" , lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <18339.34393.758783.340258@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.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com>
Status: RO
Content-Length: 1088

Brian Cameron writes:
> I believe the main reason the JDS team wants these interfaces to be
> Volatile is so that other Sun groups that wish to depend on the
> interfaces sign contracts with us.  This way the JDS team can manage

In that case, make them either Project or Consolidation Private.
That'll result in the most difficulty for other projects, as they'll
all need contracts.

Note that we don't review things based on "team" boundaries.  Instead,
we review them based on project and consolidation boundaries.  If the
plan was to use Volatile interfaces across consolidation boundaries
(regardless of which "team" was involved) without a contract, then
there's a problem.

> the interfaces moving forward.  The JDS team does not want other
> teams to depend on interfaces, then get hit by a bug, and expect
> the JDS team to fix their bugs for them.

Hmm.

-- 
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 Nicolas.Williams@sun.com Fri Feb  1 13:05:04 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 m11L53K2018642
	for ; Fri, 1 Feb 2008 13:05:03 -0800 (PST)
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 m11L4jF0026569;
	Fri, 1 Feb 2008 21:04:57 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 <0JVK00H1NVW81U00@nwk-avmta-2.sfbay.sun.com>; Fri,
 01 Feb 2008 13:04:56 -0800 (PST)
Received: from binky.Central.Sun.COM ([129.153.128.104])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK00B39VW7E570@nwk-avmta-2.sfbay.sun.com>; Fri,
 01 Feb 2008 13:04:55 -0800 (PST)
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 m11L4tGk020235;
 Fri, 01 Feb 2008 15:04:55 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m11L4tP5020234; Fri,
 01 Feb 2008 15:04:55 -0600 (CST)
Date: Fri, 01 Feb 2008 15:04:55 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <18339.34393.758783.340258@gargle.gargle.HOWL>
To: James Carlson 
Cc: Brian Cameron , John Fischer ,
        "brian.lu" , John Plocher ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <20080201210454.GO19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <18339.34393.758783.340258@gargle.gargle.HOWL>
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: 837

On Fri, Feb 01, 2008 at 03:51:37PM -0500, James Carlson wrote:
> Brian Cameron writes:
> > I believe the main reason the JDS team wants these interfaces to be
> > Volatile is so that other Sun groups that wish to depend on the
> > interfaces sign contracts with us.  This way the JDS team can manage
> 
> In that case, make them either Project or Consolidation Private.
> That'll result in the most difficulty for other projects, as they'll
> all need contracts.

Brian was right though: Volatile is "public and unstable for folks
outside the WOS" and "consolidation private for better-than-volatile
consumers in the WOS" (my rough translation of what the taxonomy says).
I still think it's better to go with Uncommitted, but I'll live.

I would prefer if the docs were included, I'd still like to understand
the library version number.

From carlsonj@phorcys.east.sun.com Fri Feb  1 13:13:10 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 m11LD9qC018901
	for ; Fri, 1 Feb 2008 13:13:10 -0800 (PST)
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 m11LCtD4029299;
	Fri, 1 Feb 2008 21:13:04 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 <0JVK00H09W9QFG00@nwk-avmta-2.sfbay.sun.com>; Fri,
 01 Feb 2008 13:13:02 -0800 (PST)
Received: from phorcys.east.sun.com ([129.148.174.143])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK00BCOW9PEI60@nwk-avmta-2.sfbay.sun.com>; Fri,
 01 Feb 2008 13:13:01 -0800 (PST)
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 m11LD13Y012683; Fri,
 01 Feb 2008 16:13:01 -0500 (EST)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m11LD0b5012680; Fri,
 01 Feb 2008 16:13:00 -0500 (EST)
Date: Fri, 01 Feb 2008 16:13:00 -0500
From: James Carlson 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <20080201210454.GO19708@Sun.COM>
To: Nicolas Williams 
Cc: Brian Cameron , John Fischer ,
        "brian.lu" , John Plocher ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <18339.35676.560164.816707@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.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <18339.34393.758783.340258@gargle.gargle.HOWL>
 <20080201210454.GO19708@Sun.COM>
Status: RO
Content-Length: 1589

Nicolas Williams writes:
> On Fri, Feb 01, 2008 at 03:51:37PM -0500, James Carlson wrote:
> > Brian Cameron writes:
> > > I believe the main reason the JDS team wants these interfaces to be
> > > Volatile is so that other Sun groups that wish to depend on the
> > > interfaces sign contracts with us.  This way the JDS team can manage
> > 
> > In that case, make them either Project or Consolidation Private.
> > That'll result in the most difficulty for other projects, as they'll
> > all need contracts.
> 
> Brian was right though: Volatile is "public and unstable for folks
> outside the WOS" and "consolidation private for better-than-volatile
> consumers in the WOS" (my rough translation of what the taxonomy says).
> I still think it's better to go with Uncommitted, but I'll live.

True, but if they're doing this because they're worried about making
fixes for other consumers inside the WOS, what chance does any of
those customers, enticed by the presence of this well-known but
Volatile interface, have?

My understanding of the taxonomy is that it's primarily there to allow
us to tell people how interfaces might change over time, and thus the
risks in using them, and not that we're concerned about or just unable
to support them when used.

Equating a higher (or a lower) stability level with a generic promise
of support seems like an error to me.

-- 
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 Brian.Cameron@sun.com Fri Feb  1 13:22:46 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 m11LMkVx018988
	for ; Fri, 1 Feb 2008 13:22:46 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11LMjvR002014
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 21:22:45 GMT
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 <0JVK0060BWPUGZ00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 14:22:42 -0700 (MST)
Received: from brmea-mail-3.sun.com ([192.18.98.34])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK0040SWPSM410@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:22:40 -0700 (MST)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m11LMeI2011775	for
 ; Fri, 01 Feb 2008 21:22:40 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVK00I01WPBX500@mail-amer.sun.com>
 (original mail from Brian.Cameron@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:22:40 -0700 (MST)
Received: from [192.168.1.77] ([189.147.109.48])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JVK00I83WPOIT00@mail-amer.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:22:40 -0700 (MST)
Date: Fri, 01 Feb 2008 15:22:39 -0600
From: Brian Cameron 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <20080201204022.GM19708@Sun.COM>
Sender: Brian.Cameron@sun.com
To: Nicolas Williams 
Cc: John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <47A38D9F.4060707@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM>
User-Agent: Thunderbird 2.0.0.9 (X11/20080128)
Status: RO
Content-Length: 3499


Nicolas:

> On Fri, Feb 01, 2008 at 02:25:48PM -0600, Brian Cameron wrote:
>> Nicolas:
>>> It would still, however, save work to mark the stable parts of the API
>>> as Uncommitted.
>> What work would be saved, exactly?
> 
> Negotiating contracts, informing contract holders of updates.  The
> trade-off is that it would require checking the release notes of SQLite
> (at least) to see if any Uncommitted interfaces have changed
> incompatibly.

It sounds like work is saved for people who want to use the interfaces.
Not for the JDS team.  :)  Verifying that interfaces are stable is more
work than just checking release notes, after all.

 > In that case, make them either Project or Consolidation Private.
 > That'll result in the most difficulty for other projects, as they'll
 > all need contracts.

This is also an option to consider, since this better fits our
Consolidation needs.  It also allows us to avoid concerns like I18N
support or providing manpages.

Our thinking in making the interfaces Volatile was because we didn't
want to make it so difficult for others to consider using the
interfaces, if they are okay with the risks associated with "Volatile".

Note if we make SQLite Consolidation Private, this will mean that
we will likely opt to not distribute CLI, headers, or other
interfaces that other groups or external users would likely want.
I suppose we could provide things like the headers to internal
teams with contracts.

If the database team were willing to own SQLite, I would 100% agree
with you that the interfaces should have a higher stability level.
For the JDS team to include it for JDS consolidation purposes
(e.g. Firefox), I'm not sure our team wants to be responsible for
making these interfaces available to others in an Uncommitted or
Committed fashion.  But it is worth discussing.  Perhaps the JDS
management would be willing to accept a higher stability level
if pressed.

I'd recommend pushing for the database team to own SQLite instead
of our team if we want a higher stability level.  They are the
better team to provide this degree of interface stability.  We
talked with them about this, but they didn't seem to think they had
the resources to do so.  Perhaps they might take over ownership over
time.  For now, the JDS team needs SQLite to make Firefox 3.0 run.

 > Note that we don't review things based on "team" boundaries.  Instead,
 > we review them based on project and consolidation boundaries.  If the
 > plan was to use Volatile interfaces across consolidation boundaries
 > (regardless of which "team" was involved) without a contract, then
 > there's a problem.

Sorry, I meant "consolidation" not "team".

 > Use Volatile only if you really feel you need to ship patches that
 > have intentionally incompatible changes.  It's a loaded weapon aimed
 > squarely at the user.  :-/

That's quite a metaphor.  I have also expressed concern at the fact
that 99% of the external FOSS interfaces were are brining into
Solaris are using the Volatile classification, however I am not sure
it is as serious as life and death, as you suggest.  I'm also not
sure SQLite should be the poster child to resolve this FOSS
Volatile issue.

More realistically, we probably need to be at least as good as our
competition (e.g. Linux).  If the interfaces are really Stable via
the external project, as you suggest, then our interface classification
probably does not matter, aside from affecting things like the amount of
our internal paperwork.

Brian


From Nicolas.Williams@sun.com Fri Feb  1 13:27:45 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 m11LRimP019045
	for ; Fri, 1 Feb 2008 13:27:45 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11LRVS6003677;
	Fri, 1 Feb 2008 21:27:38 GMT
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 <0JVK0060NWY0SY00@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 14:27:36 -0700 (MST)
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 <0JVK004DKWXZMC10@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 14:27:36 -0700 (MST)
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 m11LRWMr020267;
 Fri, 01 Feb 2008 15:27:32 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m11LRWkJ020266; Fri,
 01 Feb 2008 15:27:32 -0600 (CST)
Date: Fri, 01 Feb 2008 15:27:32 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <18339.35676.560164.816707@gargle.gargle.HOWL>
To: James Carlson 
Cc: Brian Cameron , John Fischer ,
        "brian.lu" , John Plocher ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <20080201212731.GQ19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <18339.34393.758783.340258@gargle.gargle.HOWL>
 <20080201210454.GO19708@Sun.COM> <18339.35676.560164.816707@gargle.gargle.HOWL>
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: 2255

On Fri, Feb 01, 2008 at 04:13:00PM -0500, James Carlson wrote:
> Nicolas Williams writes:
> > Brian was right though: Volatile is "public and unstable for folks
> > outside the WOS" and "consolidation private for better-than-volatile
> > consumers in the WOS" (my rough translation of what the taxonomy says).
> > I still think it's better to go with Uncommitted, but I'll live.
> 
> True, but if they're doing this because they're worried about making
> fixes for other consumers inside the WOS, what chance does any of
> those customers, enticed by the presence of this well-known but
> Volatile interface, have?

Also, if it really is a shared component, then I think we could say that
responsibility for updating it will be that of any team that needs an
update.  I don't see the JDS team as any more or less equal than any
other internal SQLite consumer.  If our support model is that "the team
that integrated owns it" then I'm afraid that will likely not work well
over time (among other things, teams come and go, re-orgs happen).

> My understanding of the taxonomy is that it's primarily there to allow
> us to tell people how interfaces might change over time, and thus the
> risks in using them, and not that we're concerned about or just unable
> to support them when used.

Right.  When it comes to software of external provenance we don't always
have the ability to make good judgements about interface stability.
Here we have that ability.  If we didn't could still go with Uncommitted
provided we understood there was a high likelihood that we could end up
shipping multiple versions.

> Equating a higher (or a lower) stability level with a generic promise
> of support seems like an error to me.

I agree.  This is why I think going with Uncommitted would help: it puts
a small burden on any team that would update SQLite, to decide whether
to (ship multiple versions || wait for more approrpiate release || fix
any incompatibilities).

Since shipping multiple versions is not resource-intensive, and since
the likelihood of backwards incompatible changes here is so low, I think
the best approach is Uncommitted.

If it would help, I volunteer to draw up a list {API, stability
attributes} based on the SQLite documentation.

Nico
-- 

From Nicolas.Williams@sun.com Fri Feb  1 13:34:01 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 m11LXxPn019252
	for ; Fri, 1 Feb 2008 13:34:00 -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 m11LXoaO005126;
	Sat, 2 Feb 2008 05:33:55 +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 <0JVK00719X8GAS00@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 14:33:52 -0700 (MST)
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 <0JVK004O8X8FMC10@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 14:33:51 -0700 (MST)
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 m11LXoZi020275;
 Fri, 01 Feb 2008 15:33:50 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m11LXoHQ020274; Fri,
 01 Feb 2008 15:33:50 -0600 (CST)
Date: Fri, 01 Feb 2008 15:33:50 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A38D9F.4060707@sun.com>
To: Brian Cameron 
Cc: John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <20080201213350.GR19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@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: 2096

On Fri, Feb 01, 2008 at 03:22:39PM -0600, Brian Cameron wrote:
> Nicolas:
> >On Fri, Feb 01, 2008 at 02:25:48PM -0600, Brian Cameron wrote:
> >>Nicolas:
> >>>It would still, however, save work to mark the stable parts of the API
> >>>as Uncommitted.
> >>What work would be saved, exactly?
> >
> >Negotiating contracts, informing contract holders of updates.  The
> >trade-off is that it would require checking the release notes of SQLite
> >(at least) to see if any Uncommitted interfaces have changed
> >incompatibly.
> 
> It sounds like work is saved for people who want to use the interfaces.
> Not for the JDS team.  :)  Verifying that interfaces are stable is more
> work than just checking release notes, after all.

I think checking the notes should be sufficient here.  But if the
ARC/c-team would insist on a home-grown testsuite, *then* the work of
doing better than Volatile becomes prohibitive.

> > In that case, make them either Project or Consolidation Private.
> > That'll result in the most difficulty for other projects, as they'll
> > all need contracts.
> 
> This is also an option to consider, since this better fits our
> Consolidation needs.  It also allows us to avoid concerns like I18N
> support or providing manpages.

The whole point of Indiana is to include things like SQLite that
developers *expect* to be included in an OS.  Volatile is bad enough
from that point of view.  Private would be a waste of our time.

I think I'm at the point where I'd be willing to take ownership of
SQLite here if it would make any difference.

> Our thinking in making the interfaces Volatile was because we didn't
> want to make it so difficult for others to consider using the
> interfaces, if they are okay with the risks associated with "Volatile".
> 
> Note if we make SQLite Consolidation Private, this will mean that
> we will likely opt to not distribute CLI, headers, or other
> interfaces that other groups or external users would likely want.
> I suppose we could provide things like the headers to internal
> teams with contracts.

Gaaa.  What'd be the point?

Nico
-- 

From John.Plocher@sun.com Fri Feb  1 13:40:09 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 m11Le8Jp019271
	for ; Fri, 1 Feb 2008 13:40:08 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m11Le8gn020075
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 13:40:08 -0800 (PST)
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 <0JVK00709XIWSN00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 14:40:08 -0700 (MST)
Received: from sca-es-mail-1.sun.com ([192.18.43.132])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK004YWXIVM210@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:40:07 -0700 (MST)
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 m11Le7WE001861	for
 ; Fri, 01 Feb 2008 13:40:07 -0800 (PST)
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 <0JVK00C01XAGWK00@fe-sfbay-10.sun.com>
 (original mail from John.Plocher@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 13:40:07 -0800 (PST)
Received: from [192.168.168.4] ([208.74.177.212])
 by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JVK004IMXIOIP50@fe-sfbay-10.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 13:40:01 -0800 (PST)
Date: Fri, 01 Feb 2008 13:40:00 -0800
From: John Plocher 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A377C9.3030808@sun.com>
Sender: John.Plocher@sun.com
To: Brian Cameron 
Cc: Elaine Xiong ,
        Nicolas Williams ,
        John Fischer , Evan.Yan@sun.com,
        "brian.lu" , lsarc-ext@sun.com
Message-id: <47A391B0.5070006@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
Status: RO
Content-Length: 1793

Brian Cameron wrote:
 > The JDS team does not want other
 > teams to depend on interfaces, then get hit by a bug, and expect
 > the JDS team to fix their bugs for them.

If the JDS team is the one integrating the feature, it is already
in the position of being involved with fixing bugs found.  It sounds
like you are just trying to make sure that your bugfix expectations
are:
	JDS team will fix bugs that impact firefox,
	other teams will need to provide fixes for bugs that
	affect them but not firefox,
	otherwise, you will need to wait until the external
	community fixes the bug.

This is a reasonable thing to say; it just needs to be said in
a way that doesn't distort/abuse the interface taxonomy.

The feedback is that this is actually much more stable than you
imply by using Volatile; we should be reflecting that expectation
to our customers AND our internal developers.

 > As has been pointed out, there is no reason other teams can't work
 > directly with the SQLite project to make it work for their needs.
 > If they have a contract in place with the JDS team, then they can
 > expect our team to work with them to help avoid problems on upgrade.

Contract or not, since your team is putting it into Solaris, you
are already committed to work with them to help avoid problems
on the upgrade.  Changing Committed to Contracted Volatile doesn't
actually change the amount and type of work that you already are
going to need to perform...

 > For example, we would provide them with pre-release test packages
 > so they can make sure their project works with the new release
 > before it goes into Nevada, and work with us to fix any bugs that
 > might be found.

You should be doing that anyways, especially if there are
incompatibilities that need to be managed...

   -John


From Brian.Cameron@sun.com Fri Feb  1 13:58:54 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 m11LwsLt020247
	for ; Fri, 1 Feb 2008 13:58:54 -0800 (PST)
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 m11Lwr2t009875
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 13:58:53 -0800 (PST)
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 <0JVK00907YE58C00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 14:58:53 -0700 (MST)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK004QGYE5MN20@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:58:53 -0700 (MST)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m11LwrDF029275	for
 ; Fri, 01 Feb 2008 21:58:53 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVK00K01Y2HG400@mail-amer.sun.com>
 (original mail from Brian.Cameron@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:58:53 -0700 (MST)
Received: from [192.168.1.77] ([189.147.109.48])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JVK00N1CYE04430@mail-amer.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:58:52 -0700 (MST)
Date: Fri, 01 Feb 2008 15:58:51 -0600
From: Brian Cameron 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A391B0.5070006@Sun.Com>
Sender: Brian.Cameron@sun.com
To: John Plocher 
Cc: Elaine Xiong ,
        Nicolas Williams ,
        John Fischer , Evan.Yan@sun.com,
        "brian.lu" , lsarc-ext@sun.com
Message-id: <47A3961B.7060402@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <47A391B0.5070006@Sun.Com>
User-Agent: Thunderbird 2.0.0.9 (X11/20080128)
Status: RO
Content-Length: 3330


John:

> If the JDS team is the one integrating the feature, it is already
> in the position of being involved with fixing bugs found.  It sounds
> like you are just trying to make sure that your bugfix expectations
> are:
>     JDS team will fix bugs that impact firefox,
>     other teams will need to provide fixes for bugs that
>     affect them but not firefox,
>     otherwise, you will need to wait until the external
>     community fixes the bug.

The JDS team would likely be willing to help fix bugs that affect
other consolidations, but we would prefer contracts in place so we
can keep track of who is actually using these interfaces.  And so
we can be more proactive in helping evaluate new releases with those
other consolidations before we push updated interfaces into Nevada.

> This is a reasonable thing to say; it just needs to be said in
> a way that doesn't distort/abuse the interface taxonomy.
> 
> The feedback is that this is actually much more stable than you
> imply by using Volatile; we should be reflecting that expectation
> to our customers AND our internal developers.

I am looking forward to hearing how we should do that.

>  > As has been pointed out, there is no reason other teams can't work
>  > directly with the SQLite project to make it work for their needs.
>  > If they have a contract in place with the JDS team, then they can
>  > expect our team to work with them to help avoid problems on upgrade.
> 
> Contract or not, since your team is putting it into Solaris, you
> are already committed to work with them to help avoid problems
> on the upgrade.  Changing Committed to Contracted Volatile doesn't
> actually change the amount and type of work that you already are
> going to need to perform...

Contracts assist our team in knowing which consolidations are depending
on the interface so we can work with them before we upgrade interfaces.
Rather than finding out after their programs break.

>  > For example, we would provide them with pre-release test packages
>  > so they can make sure their project works with the new release
>  > before it goes into Nevada, and work with us to fix any bugs that
>  > might be found.
> 
> You should be doing that anyways, especially if there are
> incompatibilities that need to be managed...

I agree we would be doing that anyways.  However, without a
contract, I am unsure how our team would be aware which other
Consolidations might be using the interfaces.  If we declare the
interfaces as Uncommitted, then other consolidations do not need to
tell the JDS consolidation that they are using the interfaces.  Or
am I wrong?

Would "Contracted Uncommitted" or something convey what we want to
communicate?  Or perhaps we need two stability levels.  The stability
level promised by the external project (which is probably Uncommitted)
versus the stability level for other consolidations (which is probably
Volatile since the JDS team would like contracts)?

Or is there a different mechanism other than contracts to keep track
of who depends on an interface?

Or perhaps, after discussion, the JDS team will agree to make the
interfaces Committed if people really think that is what we should
be pushing for.  Though I think the JDS team will need to consider
how that affects resourcing before we can make that commitment.

Brian


From Brian.Cameron@sun.com Fri Feb  1 14:00:00 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 m11Lxx9M020264
	for ; Fri, 1 Feb 2008 13:59:59 -0800 (PST)
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 m11Lxurk014497
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Sat, 2 Feb 2008 05:59:58 +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 <0JVK00J0HYFWHE00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 13:59:56 -0800 (PST)
Received: from brmea-mail-1.sun.com ([192.18.98.31])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK00BMMYFVES80@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 13:59:55 -0800 (PST)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m11Lxtio008879	for
 ; Fri, 01 Feb 2008 21:59:55 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVK00901Y65WP00@mail-amer.sun.com>
 (original mail from Brian.Cameron@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:59:55 -0700 (MST)
Received: from [192.168.1.77] ([189.147.109.48])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JVK00490YFOHJ30@mail-amer.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:59:52 -0700 (MST)
Date: Fri, 01 Feb 2008 15:59:52 -0600
From: Brian Cameron 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <20080201213350.GR19708@Sun.COM>
Sender: Brian.Cameron@sun.com
To: Nicolas Williams 
Cc: John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <47A39658.9070305@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <20080201213350.GR19708@Sun.COM>
User-Agent: Thunderbird 2.0.0.9 (X11/20080128)
Status: RO
Content-Length: 459


Nicolas:

>> Note if we make SQLite Consolidation Private, this will mean that
>> we will likely opt to not distribute CLI, headers, or other
>> interfaces that other groups or external users would likely want.
>> I suppose we could provide things like the headers to internal
>> teams with contracts.
> 
> Gaaa.  What'd be the point?

That was our thinking.  I thought you were the one who suggested
Consolidation Private.  Sorry, if I was confused.

Brian

From Brian.Cameron@sun.com Fri Feb  1 14:04:47 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 m11M4lhZ020561
	for ; Fri, 1 Feb 2008 14:04:47 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11M4bMT017040
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 22:04:46 GMT
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 <0JVK00F05YNWKT00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 14:04:44 -0800 (PST)
Received: from brmea-mail-1.sun.com ([192.18.98.31])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK00K7NYNVBCE0@nwk-avmta-1.sfbay.Sun.COM> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:04:43 -0800 (PST)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m11M4hgP010679	for
 ; Fri, 01 Feb 2008 22:04:43 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVK00D01XMTKC00@mail-amer.sun.com>
 (original mail from Brian.Cameron@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:04:43 -0700 (MST)
Received: from [192.168.1.77] ([189.147.109.48])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JVK00BS8YNI2S70@mail-amer.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:04:34 -0700 (MST)
Date: Fri, 01 Feb 2008 16:04:34 -0600
From: Brian Cameron 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3961B.7060402@sun.com>
Sender: Brian.Cameron@sun.com
To: Brian Cameron 
Cc: John Plocher , Elaine Xiong ,
        Nicolas Williams ,
        John Fischer , Evan.Yan@sun.com,
        "brian.lu" , lsarc-ext@sun.com
Message-id: <47A39772.6050202@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <47A391B0.5070006@Sun.Com>
 <47A3961B.7060402@sun.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20080128)
Status: RO
Content-Length: 1699



> I agree we would be doing that anyways.  However, without a
> contract, I am unsure how our team would be aware which other
> Consolidations might be using the interfaces.  If we declare the
> interfaces as Uncommitted, then other consolidations do not need to
> tell the JDS consolidation that they are using the interfaces.  Or
> am I wrong?
> 
> Would "Contracted Uncommitted" or something convey what we want to
> communicate?  Or perhaps we need two stability levels.  The stability
> level promised by the external project (which is probably Uncommitted)
> versus the stability level for other consolidations (which is probably
> Volatile since the JDS team would like contracts)?
> 
> Or is there a different mechanism other than contracts to keep track
> of who depends on an interface?

Note the way the JDS team handles this sort of issue for GNOME is via
"man gnome-interfaces".  Please refer to that manpage.

Note this manpage contains a handy table which specifies which
interfaces are committed versus Volatile.  The table also specifies
which interfaces are "GNOME Platform" versus "GNOME Desktop".

Above the table, the manpage highlights that GNOME Platform interfaces
have an ABI commitment from the external GNOME community, so they should
be pretty stable.  However, this text also highlights that Sun treats
some of these Platform interfaces as Volatile.  This way we communicate
both Sun's and the external community interface stability levels to
our users.

Perhaps we could do something similar in the SQLite manpage to
highlight the external communities stability level versus how
Sun classifies the interface stability level?  Would this be a good
compromise?

Brian


From carlsonj@phorcys.east.sun.com Fri Feb  1 14:24:28 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 m11MOSou022383
	for ; Fri, 1 Feb 2008 14:24:28 -0800 (PST)
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 m11MOPvW014788;
	Fri, 1 Feb 2008 14:24:25 -0800 (PST)
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 <0JVK00K0BZKMH700@nwk-avmta-2.sfbay.sun.com>; Fri,
 01 Feb 2008 14:24:22 -0800 (PST)
Received: from phorcys.east.sun.com ([129.148.174.143])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVK00BCIZKJECA0@nwk-avmta-2.sfbay.sun.com>; Fri,
 01 Feb 2008 14:24:20 -0800 (PST)
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 m11MOJ6v012995; Fri,
 01 Feb 2008 17:24:19 -0500 (EST)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m11MOJCo012992; Fri,
 01 Feb 2008 17:24:19 -0500 (EST)
Date: Fri, 01 Feb 2008 17:24:19 -0500
From: James Carlson 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A38D9F.4060707@sun.com>
To: Brian Cameron 
Cc: Nicolas Williams ,
        John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <18339.39955.249969.60011@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.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
Status: RO
Content-Length: 4435

Brian Cameron writes:
> It sounds like work is saved for people who want to use the interfaces.
> Not for the JDS team.  :)  Verifying that interfaces are stable is more
> work than just checking release notes, after all.

Not necessarily.  I don't think anybody is expecting a byte-by-byte
examination of the changes that go into an imported large project.

It doesn't happen for Solaris itself, and expecting that out of
someone else doesn't seem right to me.

Instead, you're supposed to verify that (a) the _intent_ is there;
that is, the upstream doesn't actually intend to break things over
time (some other projects gleefully do this; I don't think this one
does), and (b) the bits you import are not expected to have
incompatible changes.

Everyone fully understands that accidents can and will happen, no
matter what the stability level says.  We sometimes break Committed
interfaces by accident.  When it happens, someone has to fix it.
(That "someone" is mostly a business decision -- it could be the team
that integrated it, a dedicated support group, the team that found the
problem, or someone else entirely.)

You don't need to promise to boil away the ocean to see if there might
be rusty nails and other bugs at the bottom.

> Our thinking in making the interfaces Volatile was because we didn't
> want to make it so difficult for others to consider using the
> interfaces, if they are okay with the risks associated with "Volatile".

But Volatile *IS* hard to use.  It says that the interfaces will
change without notice, possibly breaking you in a patch.  You'd have
to be either working on a trivial home directory experiment or just
daft to put up with that sort of "commitment."

Or you (the consumer) may well be assuming a higher stability level.
In other words, you know that SQLite is stable, and Sun has applied
the wrong stability level.  You chuckle at the "Volatile" label and
plow on.

If that's the case, then what violence are we doing to our other
stability promises?  What are customers to believe?

> If the database team were willing to own SQLite, I would 100% agree
> with you that the interfaces should have a higher stability level.

It's the conflation of ownership and funding with stability level that
I find distasteful in this project.  It shouldn't be this way, and it
ends up shoving cost out onto the users -- either they can't use a
perfectly good available tool (and must invest in another one with
better stability and support), or they have to negotiate a contract
for special use and worry that they're living on borrowed time.

>  > Use Volatile only if you really feel you need to ship patches that
>  > have intentionally incompatible changes.  It's a loaded weapon aimed
>  > squarely at the user.  :-/
> 
> That's quite a metaphor.  I have also expressed concern at the fact
> that 99% of the external FOSS interfaces were are brining into
> Solaris are using the Volatile classification, however I am not sure
> it is as serious as life and death, as you suggest.  I'm also not
> sure SQLite should be the poster child to resolve this FOSS
> Volatile issue.

What you're describing sounds like the "External" fiasco that we've
tried so hard to steer away from.  It sounds to me like we're not
being too successful at it.

When we know we're abusing the taxonomy, we should stop.  Even if
we're surrounded by others who are busily digging the same hole ever
deeper.

> More realistically, we probably need to be at least as good as our
> competition (e.g. Linux).  If the interfaces are really Stable via
> the external project, as you suggest, then our interface classification
> probably does not matter, aside from affecting things like the amount of
> our internal paperwork.

Our recorded stability level is what we offer to our customers and to
our internal project teams.

If we're not going to bother trying to get that right because we
"know" that it doesn't matter, then the ARC process itself also
doesn't matter.  We might as well skip it entirely if we're not going
to make a good-faith attempt at getting it right.

Waving the "Volatile" flag at everything makes a mockery of the
intended process, every bit as much as External once did.

-- 
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 Glynn.Foster@sun.com Fri Feb  1 14:47: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 m11MlshW022832
	for ; Fri, 1 Feb 2008 14:47:55 -0800 (PST)
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 m11MloeE005402
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 22:47:53 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 <0JVL00L010NRJE00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 14:47:51 -0800 (PST)
Received: from brmea-mail-2.sun.com ([192.18.98.43])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVL00BH70NQE9B0@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:47:50 -0800 (PST)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m11MloOl028385	for
 ; Fri, 01 Feb 2008 22:47:50 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVL007010NN4000@mail-amer.sun.com>
 (original mail from Glynn.Foster@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:47:50 -0700 (MST)
Received: from [192.168.4.150] ([202.65.167.210])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JVL001OG0MWV810@mail-amer.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:47:49 -0700 (MST)
Date: Sat, 02 Feb 2008 11:47:11 +1300
From: Glynn Foster 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <18339.39955.249969.60011@gargle.gargle.HOWL>
Sender: Glynn.Foster@sun.com
To: James Carlson 
Cc: Brian Cameron , John Fischer ,
        "brian.lu" , John Plocher ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <47A3A16F.8040105@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL>
User-Agent: Thunderbird 2.0.0.6 (X11/20071012)
Status: RO
Content-Length: 974



James Carlson wrote:
> Waving the "Volatile" flag at everything makes a mockery of the
> intended process, every bit as much as External once did.

I agree to an extent that an automatic classification of 'Volatile' on things
isn't the right approach. However, that said, given the strong likelihood of
wanting to continue to include software that our customers need, we do need to
start somewhere - the first rung of the ladder, so to speak.

When we first ARC'd GNOME, the team was very, very conservative in their
classification. Purposely so, given the experience level of the technology
during those early days. While you *could* argue that integration of software
should *only* happen given a full knowledge of it, that argument doesn't
accurately reflect the reality of the market and our customers needs. If they're
not going to get it from us, they'll sure as hell get it themselves. Let's make
it as easy as possible for them, otherwise we'll lose them.


Glynn

From John.Plocher@sun.com Fri Feb  1 14:50:58 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 m11Mow9T022847
	for ; Fri, 1 Feb 2008 14:50:58 -0800 (PST)
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 m11MovOK013367
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 15:50:57 -0700 (MST)
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 <0JVL00K030SX8500@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 14:50:57 -0800 (PST)
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 <0JVL00GDO0SXU0C0@nwk-avmta-1.sfbay.Sun.COM> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:50:57 -0800 (PST)
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 m11MouQw009001	for
 ; Fri, 01 Feb 2008 14:50:56 -0800 (PST)
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 <0JVL003010NS6V00@fe-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:50:56 -0800 (PST)
Received: from [192.168.168.4] ([208.74.177.212])
 by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JVL00DU50SWKDE0@fe-sfbay-09.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 14:50:56 -0800 (PST)
Date: Fri, 01 Feb 2008 14:50:56 -0800
From: John Plocher 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3804C.1060904@sun.com>
Sender: John.Plocher@sun.com
To: Brian Cameron 
Cc: Nicolas Williams ,
        John Fischer , "brian.lu" ,
        lsarc-ext@sun.com, evan.yan@sun.com,
        Elaine Xiong 
Message-id: <47A3A250.6070004@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
Status: RO
Content-Length: 489

Brian Cameron wrote:
> (which means that the interfaces can't change in Solars 11, but only
> in Solaris 12 or later).


What it means is that the interfaces can only change in a minor version
of the "desktop" consolidation, or whatever consolidation it really is
part of.

Not all the consolidations in a distro (or Solaris) share the same
release binding; in particular, there is no concept of a release
binding for the /entire/ distro (aka the Solaris Operating Environment).

   -John

From John.Plocher@sun.com Fri Feb  1 15:16:05 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 m11NG4bP023856
	for ; Fri, 1 Feb 2008 15:16:05 -0800 (PST)
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 m11NFRb2012520
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Sat, 2 Feb 2008 07:16:03 +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 <0JVL00M071YNQ100@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 15:15:59 -0800 (PST)
Received: from sca-es-mail-2.sun.com ([192.18.43.133])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVL00B131YMEIC0@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:15:58 -0800 (PST)
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 m11NFwWJ011537	for
 ; Fri, 01 Feb 2008 15:15:58 -0800 (PST)
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 <0JVL007011TNS000@fe-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:15:58 -0800 (PST)
Received: from [192.168.168.4] ([208.74.177.212])
 by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JVL00BU51YL9Z80@fe-sfbay-09.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:15:57 -0800 (PST)
Date: Fri, 01 Feb 2008 15:15:57 -0800
From: John Plocher 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3961B.7060402@sun.com>
Sender: John.Plocher@sun.com
To: Brian Cameron 
Cc: Elaine Xiong ,
        Nicolas Williams ,
        John Fischer , Evan.Yan@sun.com,
        "brian.lu" , lsarc-ext@sun.com
Message-id: <47A3A82D.5050402@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <47A391B0.5070006@Sun.Com>
 <47A3961B.7060402@sun.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
Status: RO
Content-Length: 2857

Brian Cameron wrote:
> The JDS team would likely be willing to help fix bugs that affect
> other consolidations, but we would prefer contracts in place so we
> can keep track of who is actually using these interfaces. 

You probably can't.  You won't get contracts from ISVs and customers
who will expect SQLite on Solaris to be just like SQLite on Linux.
If they find a bug, they will expect the SQLite community to fix it,
and for that fix to be quickly reflected in a way that will allow them
to use it on Solaris.  *That* is what you are signing up for by putting
FOSS into your product.  Making an assumption that firefox is "special",
or that Sun developers are "special" and that other consumers or developers
should be treated differently/poorly distorts both Sun's business needs
AND the usage patterns of our customers, developers and ISVs.

>> This is a reasonable thing to say; it just needs to be said in
>> a way that doesn't distort/abuse the interface taxonomy.
>>
>> The feedback is that this is actually much more stable than you
>> imply by using Volatile; we should be reflecting that expectation
>> to our customers AND our internal developers.
> 
> I am looking forward to hearing how we should do that.

Use an interface taxonomy that accurately reflects the expectations that
the community is setting for itself, have /your/ managers sign up for
whatever support levels they feel meet the needs of Sun's business
(getting resources and/or buy-in from other internal consumers if needed),
and, when confronted with bugs that you won't fix (based on the above
expectations), close them as will not fix (or whatever), just as you
would under your original proposal.


> Contracts assist our team in knowing which consolidations are depending
> on the interface so we can work with them before we upgrade interfaces.
> Rather than finding out after their programs break.

Contracts help *SUN* developers; they leave OpenSolaris developers,
ISVs and Customers out in the cold; worse, they reflect a very non-open
way of thinking.  Isn't the OpenSolaris Desktop CG /more/ than simply
the Sun GNOME development team?  Isn't there room for contributers
(like Nicolas...) to step up and help with the resource and support
load?  Just because *SUN* isn't going to support it doesn't mean that
nobody else could or would...


> I agree we would be doing that anyways.  However, without a
> contract, I am unsure how our team would be aware which other
> Consolidations might be using the interfaces.

You would do this in the context of the OS.o Desktop and ARC community
groups, where, it would be hoped, consumers of SQLite would gather
to watch the antics of their providers.  In a sense you don't need to
know who uses it IF the interfaces are, in fact, better than volatile.
Yes it is a "risk buy", but it seems justified here.

   -John


From Alan.Coopersmith@sun.com Fri Feb  1 15:21:14 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 m11NLDjC024664
	for ; Fri, 1 Feb 2008 15:21:13 -0800 (PST)
Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m11NL4CV015924
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 23:21:12 GMT
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 <0JVL0000P2791300@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 15:21:09 -0800 (PST)
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 <0JVL00L6S2785Y10@nwk-avmta-1.sfbay.Sun.COM> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:21:08 -0800 (PST)
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 m11NL8BJ013332	for
 ; Fri, 01 Feb 2008 15:21:08 -0800 (PST)
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 <0JVL00B011YW0E00@fe-sfbay-09.sun.com>
 (original mail from Alan.Coopersmith@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:21:08 -0800 (PST)
Received: from [129.146.108.211] by fe-sfbay-09.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0JVL00BTE2709ZA0@fe-sfbay-09.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 15:21:04 -0800 (PST)
Date: Fri, 01 Feb 2008 15:20:59 -0800
From: Alan Coopersmith 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3A250.6070004@Sun.Com>
Sender: Alan.Coopersmith@sun.com
To: John Plocher 
Cc: Brian Cameron ,
        Nicolas Williams ,
        John Fischer , "brian.lu" ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <47A3A95B.4030104@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
X-Enigmail-Version: 0.95.1
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <47A3A250.6070004@Sun.Com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071203)
Status: RO
Content-Length: 951

John Plocher wrote:
> Brian Cameron wrote:
>> (which means that the interfaces can't change in Solars 11, but only
>> in Solaris 12 or later).
> 
> 
> What it means is that the interfaces can only change in a minor version
> of the "desktop" consolidation, or whatever consolidation it really is
> part of.
> 
> Not all the consolidations in a distro (or Solaris) share the same
> release binding; in particular, there is no concept of a release
> binding for the /entire/ distro (aka the Solaris Operating Environment).

I know you've said that before, but I still can't believe it since release
bindings are only useful as a method of communication to customers, and
customers only see the WOS release - they have no way to find out what the
consolidation boundaries or release bindings level are, nor should they
need to know that.

-- 
	-Alan Coopersmith-           alan.coopersmith@sun.com
	 Sun Microsystems, Inc. - X Window System Engineering


From Nicolas.Williams@sun.com Fri Feb  1 15:24:19 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 m11NOJmB024822
	for ; Fri, 1 Feb 2008 15:24:19 -0800 (PST)
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 m11NOENf021788;
	Fri, 1 Feb 2008 16:24:16 -0700 (MST)
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 <0JVL000092CDA300@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 01 Feb 2008 15:24:13 -0800 (PST)
Received: from binky.Central.Sun.COM ([129.153.128.104])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVL00L232CA6910@nwk-avmta-1.sfbay.Sun.COM>; Fri,
 01 Feb 2008 15:24:10 -0800 (PST)
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 m11NO6of021457;
 Fri, 01 Feb 2008 17:24:06 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m11NO6uN021456; Fri,
 01 Feb 2008 17:24:06 -0600 (CST)
Date: Fri, 01 Feb 2008 17:24:06 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3A82D.5050402@Sun.Com>
To: John Plocher 
Cc: Brian Cameron , Elaine Xiong ,
        John Fischer , Evan.Yan@sun.com,
        "brian.lu" , lsarc-ext@sun.com
Message-id: <20080201232406.GY19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <47A391B0.5070006@Sun.Com>
 <47A3961B.7060402@sun.com> <47A3A82D.5050402@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: 1230

On Fri, Feb 01, 2008 at 03:15:57PM -0800, John Plocher wrote:
> Contracts help *SUN* developers; they leave OpenSolaris developers,
> ISVs and Customers out in the cold; worse, they reflect a very non-open
> way of thinking.  Isn't the OpenSolaris Desktop CG /more/ than simply
> the Sun GNOME development team?  Isn't there room for contributers
> (like Nicolas...) to step up and help with the resource and support
> load?  Just because *SUN* isn't going to support it doesn't mean that
> nobody else could or would...

I'm offering to help.

Also, I think fear of backwards incompatibility here would be a strong
reason to follow Dr. Hipp's advice and statically link SQLite into its
consumers.  For things in the WOS it wouldn't help because we rebuild
too often.  But mostly I think that fear of backwards incompatibility
here is overdone.

Many open source communities lack discipline when it comes to backwards
compatibility; the SQLite comunity most definitely is not amongst those.

If we ignore awesome compatibility track records, what good are they
for?  Why not go with Volatile for everything and let OpenSolaris join
the ranks of those open source communities that aren't disciplined about
compatibility?

Nico
-- 

From John.Plocher@sun.com Fri Feb  1 15:50:45 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 m11NoidG026821
	for ; Fri, 1 Feb 2008 15:50:44 -0800 (PST)
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 m11Nogji026788
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 23:50:43 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 <0JVL0010D3KG7Z00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 15:50:40 -0800 (PST)
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 <0JVL00BIQ3KEEID0@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:50:39 -0800 (PST)
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 m11Noc25016165	for
 ; Fri, 01 Feb 2008 15:50:38 -0800 (PST)
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 <0JVL00N013C40X00@fe-sfbay-10.sun.com>
 (original mail from John.Plocher@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:50:38 -0800 (PST)
Received: from [192.168.168.4] ([208.74.177.212])
 by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JVL00IIP3KDEMC0@fe-sfbay-10.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 15:50:38 -0800 (PST)
Date: Fri, 01 Feb 2008 15:50:37 -0800
From: John Plocher 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3A95B.4030104@sun.com>
Sender: John.Plocher@sun.com
To: Alan Coopersmith 
Cc: Brian Cameron ,
        Nicolas Williams ,
        John Fischer , "brian.lu" ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <47A3B04D.4040004@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <47A3A250.6070004@Sun.Com> <47A3A95B.4030104@sun.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
Status: RO
Content-Length: 2299

Alan Coopersmith wrote:
> John Plocher wrote:
>> Brian Cameron wrote:
>>> (which means that the interfaces can't change in Solars 11, but only
>>> in Solaris 12 or later).
>>
>> What it means is that the interfaces can only change in a minor version
>> of the "desktop" consolidation, or whatever consolidation it really is
>> part of.
>>
>> Not all the consolidations in a distro (or Solaris) share the same
>> release binding; in particular, there is no concept of a release
>> binding for the /entire/ distro (aka the Solaris Operating Environment).
> 
> I know you've said that before, but I still can't believe it since release
> bindings are only useful as a method of communication to customers, and
> customers only see the WOS release - they have no way to find out what the
> consolidation boundaries or release bindings level are, nor should they
> need to know that.
> 


The consumer of a consolidation release binding is not the end customer,
but the distro builder (aka RE, aka P-Team) - it is /their/ responsibility
to pick the set of consolidation instances that their customer base will
accept.  Release Taxonomy levels simply let them build self-consistent
products.  If done correctly, there is no need to expose the implementation
details (which consolidations most certainly are) to them.

Think of the various consolidations, WOS's and Products that go into Solaris
Express, Developer Edition:

	Solaris
	Sun Studio Express 6/07
	NetBeans IDE 5.5
	NetBeans Enterprise Pack 5.5
	NetBeans Visual Web Pack 5.5
	NetBeans Profiler 5.5
	PostgreSQL 8.2.4
	Java Platform, Standard Edition 6
	StarOffice 8

Many of these have regular major releases:  Studio, NetBeans and
Soffice all do it regularly...

When you dig down into the thing called "Solaris", you find the following
components/consolidations:

	Admin  	
	CNS  	
	Desktop  	
	DevPro  	
	Extra Value Dir  	
	G11N  	
	graphics  	
	Install  	
	J2Se  	
	NSPG  	
	NWS  	
	ON  	
	Orion  	
	SFW  	
	Shared  	
	SSONE  	
	SunVTS

Each one of these has its own release taxonomy value; it is safe to
say that only ON has a fixation on never doing a major release.  In
particular, DevPro, Extra Value Dir, J2Se, NWS, Orion, SSONE and
SunVTS have all had Major releases in recent releases of the Solaris
Operating Environment.

   -John

From Brian.Cameron@sun.com Fri Feb  1 16:00:37 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 m1200aGk027328
	for ; Fri, 1 Feb 2008 16:00:36 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1200VQm000398
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Sat, 2 Feb 2008 00:00:35 GMT
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 <0JVL00J0340Z7E00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 17:00:35 -0700 (MST)
Received: from brmea-mail-1.sun.com ([192.18.98.31])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVL004TR40WMB70@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 17:00:32 -0700 (MST)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1200WCC019366	for
 ; Sat, 02 Feb 2008 00:00:32 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVL001013VBR800@mail-amer.sun.com>
 (original mail from Brian.Cameron@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 17:00:32 -0700 (MST)
Received: from [192.168.1.77] ([189.147.109.48])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JVL005W040S9NF0@mail-amer.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 17:00:30 -0700 (MST)
Date: Fri, 01 Feb 2008 18:00:32 -0600
From: Brian Cameron 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <18339.39955.249969.60011@gargle.gargle.HOWL>
Sender: Brian.Cameron@sun.com
To: James Carlson 
Cc: Nicolas Williams ,
        John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <47A3B2A0.8030906@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL>
User-Agent: Thunderbird 2.0.0.9 (X11/20080128)
Status: RO
Content-Length: 6541


James:

>> It sounds like work is saved for people who want to use the interfaces.
>> Not for the JDS team.  :)  Verifying that interfaces are stable is more
>> work than just checking release notes, after all.
> 
> Not necessarily.  I don't think anybody is expecting a byte-by-byte
> examination of the changes that go into an imported large project.
> 
> It doesn't happen for Solaris itself, and expecting that out of
> someone else doesn't seem right to me.

The JDS team currently does ABI comparison for all of our Committed
interfaces.

> Instead, you're supposed to verify that (a) the _intent_ is there;
> that is, the upstream doesn't actually intend to break things over
> time (some other projects gleefully do this; I don't think this one
> does), and (b) the bits you import are not expected to have
> incompatible changes.
> 
> Everyone fully understands that accidents can and will happen, no
> matter what the stability level says.  We sometimes break Committed
> interfaces by accident.  When it happens, someone has to fix it.
> (That "someone" is mostly a business decision -- it could be the team
> that integrated it, a dedicated support group, the team that found the
> problem, or someone else entirely.)
> 
> You don't need to promise to boil away the ocean to see if there might
> be rusty nails and other bugs at the bottom.

I'm not sure it always makes sense to mark a Solaris interface as
Committed or Uncommitted just because an external community has the
"intent" for stability.

>> Our thinking in making the interfaces Volatile was because we didn't
>> want to make it so difficult for others to consider using the
>> interfaces, if they are okay with the risks associated with "Volatile".
> 
> But Volatile *IS* hard to use.  It says that the interfaces will
> change without notice, possibly breaking you in a patch.  You'd have
> to be either working on a trivial home directory experiment or just
> daft to put up with that sort of "commitment."

Volatile is only hard to use if the problem you describe actually
happens.  If the interfaces never break because the external community
has good ABI compatibility, then users depending on that interface
will probably not notice that the interface is Volatile.

> Or you (the consumer) may well be assuming a higher stability level.
> In other words, you know that SQLite is stable, and Sun has applied
> the wrong stability level.  You chuckle at the "Volatile" label and
> plow on.

If I were a customer, I would understand that Volatile means that
Sun isn't going to support me if I have problems.  If I know the
SQLite community will take care of me, then I might be agreeable
to not worrying about the lack of Sun support.

> If that's the case, then what violence are we doing to our other
> stability promises?  What are customers to believe?

Customers who need stability probably should stick with the interfaces
that are Committed/Uncommitted.  If SQLite is not marked as stable,
then there are other database options on Solaris which might be a better
choice.

Most people who use free software interfaces, however, aren't looking
for this level of stability.

>> If the database team were willing to own SQLite, I would 100% agree
>> with you that the interfaces should have a higher stability level.
> 
> It's the conflation of ownership and funding with stability level that
> I find distasteful in this project.  It shouldn't be this way, and it
> ends up shoving cost out onto the users -- either they can't use a
> perfectly good available tool (and must invest in another one with
> better stability and support), or they have to negotiate a contract
> for special use and worry that they're living on borrowed time.

The two choices you suggest aren't the only choices possible.  In fact,
most 3rd parties link in their own copies of non-committed interfaces
when they have concerns about stability.

>> That's quite a metaphor.  I have also expressed concern at the fact
>> that 99% of the external FOSS interfaces were are brining into
>> Solaris are using the Volatile classification, however I am not sure
>> it is as serious as life and death, as you suggest.  I'm also not
>> sure SQLite should be the poster child to resolve this FOSS
>> Volatile issue.
> 
> What you're describing sounds like the "External" fiasco that we've
> tried so hard to steer away from.  It sounds to me like we're not
> being too successful at it.

In my experience working with ARC, ARC seems to promote keeping
up-to-date with the FOSS community as a higher priority than worrying
about FOSS interface stability levels.  This is my understanding why
there are so many FOSS Volatile interfaces.

Perhaps that is changing?  In the past when I have suggested that
ARC get more involved with external communities to promote better
interface stability within those projects, the responses seem to be
somewhere between ambivalent and negative.

> When we know we're abusing the taxonomy, we should stop.  Even if
> we're surrounded by others who are busily digging the same hole ever
> deeper.

I'm not sure that we are abusing the taxonomy.  It depends what our
priorities are.  Are we working to build an ironclad stable software
platform based on FOSS components, or are we trying to provide a
development platform that is competitive with Linux, or what?  How
we classify FOSS interfaces should depend on what we are trying to
achieve.

>> More realistically, we probably need to be at least as good as our
>> competition (e.g. Linux).  If the interfaces are really Stable via
>> the external project, as you suggest, then our interface classification
>> probably does not matter, aside from affecting things like the amount of
>> our internal paperwork.
> 
> Our recorded stability level is what we offer to our customers and to
> our internal project teams.
> 
> If we're not going to bother trying to get that right because we
> "know" that it doesn't matter, then the ARC process itself also
> doesn't matter.  We might as well skip it entirely if we're not going
> to make a good-faith attempt at getting it right.
> 
> Waving the "Volatile" flag at everything makes a mockery of the
> intended process, every bit as much as External once did.

I have raised that concern myself.  However, I don't agree with you
that it makes Solaris or ARC a mockery.  It just means that users who
need Stability are limited from using a lot of FOSS components.  I'm
not sure that is necessarily a problem.  It depends on what we are
trying to achieve.

Brian


From Nicolas.Williams@sun.com Fri Feb  1 16:08:31 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 m1208Vtv028076
	for ; Fri, 1 Feb 2008 16:08:31 -0800 (PST)
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 m1208RZB032422;
	Fri, 1 Feb 2008 17:08:28 -0700 (MST)
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 <0JVL00J794E3BJ00@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 17:08:27 -0700 (MST)
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 <0JVL0043Z4E1MK80@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 17:08:26 -0700 (MST)
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 m1208PCQ021528;
 Fri, 01 Feb 2008 18:08:25 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1208PJL021527; Fri,
 01 Feb 2008 18:08:25 -0600 (CST)
Date: Fri, 01 Feb 2008 18:08:25 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3B2A0.8030906@sun.com>
To: Brian Cameron 
Cc: James Carlson ,
        John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <20080202000825.GA19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL> <47A3B2A0.8030906@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: 3756

On Fri, Feb 01, 2008 at 06:00:32PM -0600, Brian Cameron wrote:
> James:
> >You don't need to promise to boil away the ocean to see if there might
> >be rusty nails and other bugs at the bottom.
> 
> I'm not sure it always makes sense to mark a Solaris interface as
> Committed or Uncommitted just because an external community has the
> "intent" for stability.

Yes, yes it does always make sense to ... just because ... (and for
other reasons too).  We ship multiple versions of certain things, and
even announce our intention to when we expect incompatible change ahead
of time.

> >>Our thinking in making the interfaces Volatile was because we didn't
> >>want to make it so difficult for others to consider using the
> >>interfaces, if they are okay with the risks associated with "Volatile".
> >
> >But Volatile *IS* hard to use.  It says that the interfaces will
> >change without notice, possibly breaking you in a patch.  You'd have
> >to be either working on a trivial home directory experiment or just
> >daft to put up with that sort of "commitment."
> 
> Volatile is only hard to use if the problem you describe actually
> happens.  If the interfaces never break because the external community
> has good ABI compatibility, then users depending on that interface
> will probably not notice that the interface is Volatile.

Volatile is hard to use because it means you can break on patch, this is
true regardless of whether it ever happens.

> >Or you (the consumer) may well be assuming a higher stability level.
> >In other words, you know that SQLite is stable, and Sun has applied
> >the wrong stability level.  You chuckle at the "Volatile" label and
> >plow on.
> 
> If I were a customer, I would understand that Volatile means that
> Sun isn't going to support me if I have problems.  If I know the
> SQLite community will take care of me, then I might be agreeable
> to not worrying about the lack of Sun support.

Uncommitted or Committed wouldn't mean we fix everything.  It would mean
that in the event of incompatible SQLite releases we'll either:

 - ship multiple versions, without removing the old ones until a
   suitable release boundary

 - not ship new versions

 - fix the incompatibility ourselves

What's so difficult about this?  Particularly when we know the
likelihood of this is zero?

> >If that's the case, then what violence are we doing to our other
> >stability promises?  What are customers to believe?
> 
> Customers who need stability probably should stick with the interfaces
> that are Committed/Uncommitted.  If SQLite is not marked as stable,
> then there are other database options on Solaris which might be a better
> choice.

SQLite is the premier open source *embedded* DB.  It has a different
target audience than the other DBs that we ship.

> Most people who use free software interfaces, however, aren't looking
> for this level of stability.

But we're making a distribution where we add value.

> >>If the database team were willing to own SQLite, I would 100% agree
> >>with you that the interfaces should have a higher stability level.
> >
> >It's the conflation of ownership and funding with stability level that
> >I find distasteful in this project.  It shouldn't be this way, and it
> >ends up shoving cost out onto the users -- either they can't use a
> >perfectly good available tool (and must invest in another one with
> >better stability and support), or they have to negotiate a contract
> >for special use and worry that they're living on borrowed time.
> 
> The two choices you suggest aren't the only choices possible.  In fact,
> most 3rd parties link in their own copies of non-committed interfaces
> when they have concerns about stability.

Which means we're not adding value.


From Brian.Cameron@sun.com Fri Feb  1 16:26:18 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 m120QIrp029396
	for ; Fri, 1 Feb 2008 16:26:18 -0800 (PST)
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 m120QFCY036332
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 17:26:17 -0700 (MST)
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 <0JVL0022N57RK800@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 16:26:15 -0800 (PST)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVL00BV757PESE0@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 16:26:13 -0800 (PST)
Received: from fe-amer-09.sun.com ([192.18.109.79])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m120QDxC024030	for
 ; Sat, 02 Feb 2008 00:26:13 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVL0030153EWW00@mail-amer.sun.com>
 (original mail from Brian.Cameron@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 17:26:13 -0700 (MST)
Received: from [192.168.1.77] ([189.147.109.48])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JVL006G557NL090@mail-amer.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 17:26:13 -0700 (MST)
Date: Fri, 01 Feb 2008 18:26:15 -0600
From: Brian Cameron 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <20080202000825.GA19708@Sun.COM>
Sender: Brian.Cameron@sun.com
To: Nicolas Williams 
Cc: James Carlson ,
        John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <47A3B8A7.2010205@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL> <47A3B2A0.8030906@sun.com>
 <20080202000825.GA19708@Sun.COM>
User-Agent: Thunderbird 2.0.0.9 (X11/20080128)
Status: RO
Content-Length: 4673


Nicholas:

>> I'm not sure it always makes sense to mark a Solaris interface as
>> Committed or Uncommitted just because an external community has the
>> "intent" for stability.
> 
> Yes, yes it does always make sense to ... just because ... (and for
> other reasons too).  We ship multiple versions of certain things, and
> even announce our intention to when we expect incompatible change ahead
> of time.

You use the word "always".

In the GNOME Project, the ORBIT2 and bonobo interfaces are stable and a
part of the GNOME Platform, and covered under ABI guarantees.  In our
Solaris distro they are "Volatile".

I can point you towards many references where the GNOME community
discourages people from using these interfaces, and the GNOME community
has announced that they will, someday, deprecate the interfaces (though
they plan to continue supporting them in a stable fashion).

Also, strangely, the GNOME community claims a few components are a
part of their Platform even though they do not really have much control
over them.  Examples include external-to-GNOME dependencies such as esd
and audiofile.

Since you say "always", I guess you think such libraries should be
"Uncommitted"?  Perhaps our usage of Volatile to steer people away from
using interfaces that do not have external community support isn't the
best usage of our taxonomy, but I'm interested to hear your thoughts.

>>> Or you (the consumer) may well be assuming a higher stability level.
>>> In other words, you know that SQLite is stable, and Sun has applied
>>> the wrong stability level.  You chuckle at the "Volatile" label and
>>> plow on.
>> If I were a customer, I would understand that Volatile means that
>> Sun isn't going to support me if I have problems.  If I know the
>> SQLite community will take care of me, then I might be agreeable
>> to not worrying about the lack of Sun support.
> 
> Uncommitted or Committed wouldn't mean we fix everything.  It would mean
> that in the event of incompatible SQLite releases we'll either:
> 
>  - ship multiple versions, without removing the old ones until a
>    suitable release boundary
> 
>  - not ship new versions
> 
>  - fix the incompatibility ourselves
> 
> What's so difficult about this?  Particularly when we know the
> likelihood of this is zero?

You are much better at predicting the future than I.  I remember when
I defined the GDM configuration files as Committed.  I thought since I
was the GDM maintainer that I had good reason to expect this wouldn't
change.  Now GDM is being rewritten and I am scrambling to figure out
how this will affect our stability levels moving forward.

In free software communities, even when you have the buy-in the of
maintainer, I would never describe the risk as zero.

>>> If that's the case, then what violence are we doing to our other
>>> stability promises?  What are customers to believe?
>> Customers who need stability probably should stick with the interfaces
>> that are Committed/Uncommitted.  If SQLite is not marked as stable,
>> then there are other database options on Solaris which might be a better
>> choice.
> 
> SQLite is the premier open source *embedded* DB.  It has a different
> target audience than the other DBs that we ship.

Right, I am aware that SQLite has its niche.

>> Most people who use free software interfaces, however, aren't looking
>> for this level of stability.
> 
> But we're making a distribution where we add value.

We need to be clever about how we add value.  I'm not sure, in the big
scheme of things, that the stability level of SQLite is where we should
be focusing our energies to add value in Solaris.  Maybe it is.  I'm
not sure.

>>>> If the database team were willing to own SQLite, I would 100% agree
>>>> with you that the interfaces should have a higher stability level.
>>> It's the conflation of ownership and funding with stability level that
>>> I find distasteful in this project.  It shouldn't be this way, and it
>>> ends up shoving cost out onto the users -- either they can't use a
>>> perfectly good available tool (and must invest in another one with
>>> better stability and support), or they have to negotiate a contract
>>> for special use and worry that they're living on borrowed time.
>> The two choices you suggest aren't the only choices possible.  In fact,
>> most 3rd parties link in their own copies of non-committed interfaces
>> when they have concerns about stability.
> 
> Which means we're not adding value. 

If it turns out that the end result of this discussion is that the
Firefox team decides to add SQLite as a Consolidation Private interface,
then the only added value is Firefox 3.0.

Brian

From Nicolas.Williams@sun.com Fri Feb  1 16:37:39 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 m120bcZE029518
	for ; Fri, 1 Feb 2008 16:37:38 -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 m120bPI8011992;
	Sat, 2 Feb 2008 08:37:31 +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 <0JVL00L0D5QGZY00@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 17:37:28 -0700 (MST)
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 <0JVL004SW5QFM290@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 17:37:28 -0700 (MST)
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 m120bR65021547;
 Fri, 01 Feb 2008 18:37:27 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m120bRvv021546; Fri,
 01 Feb 2008 18:37:27 -0600 (CST)
Date: Fri, 01 Feb 2008 18:37:27 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3B8A7.2010205@sun.com>
To: Brian Cameron 
Cc: James Carlson ,
        John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <20080202003726.GB19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL> <47A3B2A0.8030906@sun.com>
 <20080202000825.GA19708@Sun.COM> <47A3B8A7.2010205@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: 679

On Fri, Feb 01, 2008 at 06:26:15PM -0600, Brian Cameron wrote:
> Nicholas:
> >But we're making a distribution where we add value.
> 
> We need to be clever about how we add value.  I'm not sure, in the big
> scheme of things, that the stability level of SQLite is where we should
> be focusing our energies to add value in Solaris.  Maybe it is.  I'm
> not sure.

Oh sure, this is no big deal, neither will the next FOSS item be a big
deal, nor the next, nor the next, ...  At this rate all FOSS in Solaris
will be Volatile.

That *could* be OK.  Be should we make that decision by default?  Or
should we consciously state this policy?

Not choosing is still choosing.

Nico
-- 

From Nicolas.Williams@sun.com Fri Feb  1 16:38:51 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 m120coRa029545
	for ; Fri, 1 Feb 2008 16:38:50 -0800 (PST)
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 m120cTPn012209;
	Sat, 2 Feb 2008 08:38:43 +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 <0JVL0030D5SI4000@nwk-avmta-2.sfbay.sun.com>; Fri,
 01 Feb 2008 16:38:42 -0800 (PST)
Received: from binky.Central.Sun.COM ([129.153.128.104])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVL002335SGUA10@nwk-avmta-2.sfbay.sun.com>; Fri,
 01 Feb 2008 16:38:40 -0800 (PST)
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 m120ceRJ021554;
 Fri, 01 Feb 2008 18:38:40 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m120ce1u021553; Fri,
 01 Feb 2008 18:38:40 -0600 (CST)
Date: Fri, 01 Feb 2008 18:38:40 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3B8A7.2010205@sun.com>
To: Brian Cameron 
Cc: James Carlson ,
        John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <20080202003840.GC19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL> <47A3B2A0.8030906@sun.com>
 <20080202000825.GA19708@Sun.COM> <47A3B8A7.2010205@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: 636

On Fri, Feb 01, 2008 at 06:26:15PM -0600, Brian Cameron wrote:
> Nicholas:
> 
> >>I'm not sure it always makes sense to mark a Solaris interface as
> >>Committed or Uncommitted just because an external community has the
> >>"intent" for stability.
> >
> >Yes, yes it does always make sense to ... just because ... (and for
> >other reasons too).  We ship multiple versions of certain things, and
> >even announce our intention to when we expect incompatible change ahead
> >of time.
> 
> You use the word "always".
> 
> [...]

Fair enough, intent is not necessarily sufficient.  Track record also
matters.  But I risk repeating myself.

From John.Plocher@sun.com Fri Feb  1 17:37:45 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 m121biMQ000180
	for ; Fri, 1 Feb 2008 17:37:44 -0800 (PST)
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 m121bis1007858
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 17:37:44 -0800 (PST)
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 <0JVL00E058IVDX00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 17:37:43 -0800 (PST)
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 <0JVL00LF98IU6760@nwk-avmta-1.sfbay.Sun.COM> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 17:37:42 -0800 (PST)
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 m121bgBg022249	for
 ; Fri, 01 Feb 2008 17:37:42 -0800 (PST)
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 <0JVL007018DR1A00@fe-sfbay-10.sun.com>
 (original mail from John.Plocher@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 17:37:42 -0800 (PST)
Received: from [192.168.168.4] ([208.74.177.212])
 by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JVL00LM58IT2740@fe-sfbay-10.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 17:37:42 -0800 (PST)
Date: Fri, 01 Feb 2008 17:37:41 -0800
From: John Plocher 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3B2A0.8030906@sun.com>
Sender: John.Plocher@sun.com
To: Brian Cameron 
Cc: James Carlson ,
        Nicolas Williams ,
        John Fischer , "brian.lu" ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <47A3C965.9030107@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL> <47A3B2A0.8030906@sun.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
Status: RO
Content-Length: 2591

Brian Cameron wrote:
> Volatile is only hard to use if the problem you describe actually
> happens.  If the interfaces never break because the external community
> has good ABI compatibility, then users depending on that interface
> will probably not notice that the interface is Volatile.

Yet they *will* need to re-validate and re-certify their stuff *EVERY*
time you release a patch, upgrade or new version, just to prove that
things that /could/ break actually didn't.  With something stronger,
they wouldn't.

If you have 10 teams that reuse your stuff, this translates into
an order of magnitude more work if you make it Volatile; /you/
may save some effort, but your local optimization ends up costing
the company 10 times as much.

I think I agree with Nicolas and DrH - statically link firefox
with SQLite and don't attempt to make a shared version that you
are unwilling or unable to properly support for general use.

> If I were a customer, I would understand that Volatile means that
> Sun isn't going to support me if I have problems.  

Braap.  That is not at all what Volatile means or implies.  Promulgating
misunderstandings based on misinformation seems to be a bad thing
to do.

Volatile means that we can and will make incompatible changes to
these interfaces in patches if we so choose.  Period.  It says
nothing at all about support levels or what we will do if you
file a bug with us.

> In my experience working with ARC, ARC seems to promote keeping
> up-to-date with the FOSS community as a higher priority than worrying
> about FOSS interface stability levels.  

E_Chicken_and_egg.  The Project teams bringing in FOSS don't seem
to be able to deal with the underlying tension between "I want to use
FOSS-thing-V-x.y.z", "customers want to have FOSS-thing-V-latest" and
"customers sometimes want what you do, but a different "x.y.z"...


> In the past when I have suggested that
> ARC get more involved with external communities to promote better
> interface stability within those projects, the responses seem to be
> somewhere between ambivalent and negative.

That is because you are suggesting a syntax error.
Instead, with the exact same result, we should get project team members
who are involved with external communities to become ARC members.


> It depends what our
> priorities are.  

The interface taxonomy is simply a mechanism to communicate long term
expectations concerning the evolutionary stability of interfaces.

The choices that a team makes about its support policies are a
different thing entirely.  Apples and Oranges, really.

   -John

From Nicolas.Williams@sun.com Fri Feb  1 17:41:20 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 m121fKZs000494
	for ; Fri, 1 Feb 2008 17:41:20 -0800 (PST)
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 m121fGXJ050012;
	Fri, 1 Feb 2008 18:41:16 -0700 (MST)
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 <0JVL004018OS9M00@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 18:41:16 -0700 (MST)
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 <0JVL004MA8ORM5B0@brm-avmta-1.central.sun.com>; Fri,
 01 Feb 2008 18:41:16 -0700 (MST)
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 m121fFmi021742;
 Fri, 01 Feb 2008 19:41:15 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m121fFwB021741; Fri,
 01 Feb 2008 19:41:15 -0600 (CST)
Date: Fri, 01 Feb 2008 19:41:15 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3C965.9030107@Sun.Com>
To: John Plocher 
Cc: Brian Cameron ,
        James Carlson ,
        John Fischer , "brian.lu" ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <20080202014115.GF19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <47A3530C.6010808@Sun.Com> <47A377C9.3030808@sun.com>
 <20080201200950.GJ19708@Sun.COM> <20080201202216.GK19708@Sun.COM>
 <47A3804C.1060904@sun.com> <20080201204022.GM19708@Sun.COM>
 <47A38D9F.4060707@sun.com> <18339.39955.249969.60011@gargle.gargle.HOWL>
 <47A3B2A0.8030906@sun.com> <47A3C965.9030107@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: 592

On Fri, Feb 01, 2008 at 05:37:41PM -0800, John Plocher wrote:
> I think I agree with Nicolas and DrH - statically link firefox
> with SQLite and don't attempt to make a shared version that you
> are unwilling or unable to properly support for general use.

In that case we could ship the header file and the .a library as
Volatile, accept the multiple copies of the thing, and live with it.

Volatile + static linking == as stable as the customer wants it.

Static linking is wasteful of VM space and bug fixing opportunities, but
I think it's a reasonable compromise in this case.

Nico
-- 

From Brian.Cameron@sun.com Fri Feb  1 18:25:55 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 m122PtB1005654
	for ; Fri, 1 Feb 2008 18:25:55 -0800 (PST)
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 m122Psfe056782
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 19:25:54 -0700 (MST)
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 <0JVL00809AR6IX00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 18:25:54 -0800 (PST)
Received: from brmea-mail-2.sun.com ([192.18.98.43])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVL002EXAR6UAF0@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 18:25:54 -0800 (PST)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m122Pr9v003509	for
 ; Sat, 02 Feb 2008 02:25:53 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVL00701AL0I700@mail-amer.sun.com>
 (original mail from Brian.Cameron@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 19:25:53 -0700 (MST)
Received: from [192.168.1.77] ([189.147.109.48])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JVL003CKAQXBM20@mail-amer.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 01 Feb 2008 19:25:53 -0700 (MST)
Date: Fri, 01 Feb 2008 20:25:48 -0600
From: Brian Cameron 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3C965.9030107@Sun.Com>
Sender: Brian.Cameron@sun.com
To: John Plocher 
Cc: James Carlson ,
        Nicolas Williams ,
        John Fischer , "brian.lu" ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <47A3D4AC.5020902@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL> <47A3B2A0.8030906@sun.com>
 <47A3C965.9030107@Sun.Com>
User-Agent: Thunderbird 2.0.0.9 (X11/20080128)
Status: RO
Content-Length: 3850


John:

> Yet they *will* need to re-validate and re-certify their stuff *EVERY*
> time you release a patch, upgrade or new version, just to prove that
> things that /could/ break actually didn't.  With something stronger,
> they wouldn't.
> 
> If you have 10 teams that reuse your stuff, this translates into
> an order of magnitude more work if you make it Volatile; /you/
> may save some effort, but your local optimization ends up costing
> the company 10 times as much.

In the past, the JDS team has upgraded interfaces from Volatile
to Committed when we have gotten enough contracts that it becomes
more efficient to manage this way, for exactly the reasons you
suggest.

It seems that to bring a new, external interface in as Volatile and
then upgrade them to more stable classifications when there are clear
users is not out-of-line with the evolutionary nature of how ARC is
supposed to work.

I am not aware of 10 teams outside of the JDS consolidation waiting in
line to use SQLite.  But, based on this discussion, I guess people
anticipate these SQLite interfaces will be heavily depended upon and
are, therefore, deserving this special attention and discussion.

> I think I agree with Nicolas and DrH - statically link firefox
> with SQLite and don't attempt to make a shared version that you
> are unwilling or unable to properly support for general use.

Let's leave it up to the project team to decide whether to make
the interfaces private or to properly support them with a higher
interface level.

>> If I were a customer, I would understand that Volatile means that
>> Sun isn't going to support me if I have problems.  
> 
> Braap.  That is not at all what Volatile means or implies.  Promulgating
> misunderstandings based on misinformation seems to be a bad thing
> to do.
> 
> Volatile means that we can and will make incompatible changes to
> these interfaces in patches if we so choose.  Period.  It says
> nothing at all about support levels or what we will do if you
> file a bug with us.

Thanks for correcting my misunderstanding.  You are, of course,
right.  That said, my point was that 3rd parties could statically
link in their own copies of SQLite if the one we ship is Volatile
and the 3rd party requires stability.  I wasn't suggesting this is
ideal.  I was just trying to point out that how we classify SQLite
doesn't restrict our users to using our version.

>> In my experience working with ARC, ARC seems to promote keeping
>> up-to-date with the FOSS community as a higher priority than worrying
>> about FOSS interface stability levels.  
> 
> E_Chicken_and_egg.  The Project teams bringing in FOSS don't seem
> to be able to deal with the underlying tension between "I want to use
> FOSS-thing-V-x.y.z", "customers want to have FOSS-thing-V-latest" and
> "customers sometimes want what you do, but a different "x.y.z"...

Whether we say it is the Project Team's fault or ARC's fault is just
finger pointing, in my opinion.  I do agree it is a chicken-and-egg
problem, though.

>> In the past when I have suggested that
>> ARC get more involved with external communities to promote better
>> interface stability within those projects, the responses seem to be
>> somewhere between ambivalent and negative.
> 
> That is because you are suggesting a syntax error.
> Instead, with the exact same result, we should get project team members
> who are involved with external communities to become ARC members.

Agreed.  That would really help.  Perhaps as we move towards a more
OpenSolaris-based world, more FOSS people will get involved.

>> It depends what our
>> priorities are.  
> 
> The interface taxonomy is simply a mechanism to communicate long term
> expectations concerning the evolutionary stability of interfaces.

Which is probably why we have so many Volatile FOSS interfaces in Solaris.

Brian

From carlsonj@phorcys.east.sun.com Mon Feb  4 05:31:36 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 m14DVZSV000365
	for ; Mon, 4 Feb 2008 05:31:36 -0800 (PST)
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 m14DVTaQ013533;
	Mon, 4 Feb 2008 21:31:30 +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 <0JVP0070XUWH3500@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 04 Feb 2008 05:31:29 -0800 (PST)
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 <0JVP0043GUWGX710@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 04 Feb 2008 05:31:28 -0800 (PST)
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 m14DVSJp008299; Mon,
 04 Feb 2008 08:31:28 -0500 (EST)
Received: (from carlsonj@localhost)
	by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m14DVRSp008296; Mon,
 04 Feb 2008 08:31:27 -0500 (EST)
Date: Mon, 04 Feb 2008 08:31:27 -0500
From: James Carlson 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3B2A0.8030906@sun.com>
To: Brian Cameron 
Cc: Nicolas Williams ,
        John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <18343.5039.948070.809532@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.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL> <47A3B2A0.8030906@sun.com>
 <47A3C965.9030107@Sun.Com> <47A3D4AC.5020902@sun.com>
 <20080202000825.GA19708@Sun.COM> <47A3B8A7.2010205@sun.com>
Status: RO
Content-Length: 10535

Brian Cameron writes:
> James:
> > It doesn't happen for Solaris itself, and expecting that out of
> > someone else doesn't seem right to me.
> 
> The JDS team currently does ABI comparison for all of our Committed
> interfaces.

Good to hear.

> > You don't need to promise to boil away the ocean to see if there might
> > be rusty nails and other bugs at the bottom.
> 
> I'm not sure it always makes sense to mark a Solaris interface as
> Committed or Uncommitted just because an external community has the
> "intent" for stability.

So what do you make of the Sun projects that use these same commitment
levels?  Would you expect a Sun team to disavow support because
they're publishing Volatile interfaces?  Or that we provide some sort
of special premium level of support for Committed interfaces?

In fact, the two are just plain unrelated.  The stability level
communicates intent: it tells people when we will likely break things,
and when we intend not to do so.  We can't possibly prevent all human
mistakes, and we can't predict the future, so it's not possible for us
to say anything more than *intent."

Whether and how a customer gets support is a separate business
decision and a matter of appropriate documentation.  It could be
through some Sun-provided on-site team.  It could be an on-demand
service.  It could be a third party with whom Sun contracts.  It could
even be some open source forum.  Perhaps even "no support at all."

I'm not buying the argument that "Volatile" can or should mean "we
won't try very hard to support this."  The ARC doesn't make or
evaluate support commitments.

> > But Volatile *IS* hard to use.  It says that the interfaces will
> > change without notice, possibly breaking you in a patch.  You'd have
> > to be either working on a trivial home directory experiment or just
> > daft to put up with that sort of "commitment."
> 
> Volatile is only hard to use if the problem you describe actually
> happens.  If the interfaces never break because the external community
> has good ABI compatibility, then users depending on that interface
> will probably not notice that the interface is Volatile.

In that case, they never were actually Volatile, and our documentation
and the ARC case that described the project were wrong.  I don't think
that getting stability levels wrong in either direction is desirable
-- making them too stable means that changes are painful for the
single interface owner, but making them too unstable means that usage
is painful for the many interface consumers.  In fact, I'd expect that
making them too unstable is higher cost in the long run, and as long
as we're not optimizing for one group.

> > Or you (the consumer) may well be assuming a higher stability level.
> > In other words, you know that SQLite is stable, and Sun has applied
> > the wrong stability level.  You chuckle at the "Volatile" label and
> > plow on.
> 
> If I were a customer, I would understand that Volatile means that
> Sun isn't going to support me if I have problems.  If I know the
> SQLite community will take care of me, then I might be agreeable
> to not worrying about the lack of Sun support.

That doesn't make sense here.  Sun is providing the SQLite packages.
There's no way that community can "take care of" anybody; it doesn't
produce the signed SUNW* packages or patches.  Sun itself will have to
do that.

If I get bits from the external community, I expect the community (or
my own internal team) to support those bits.  If I get bits from Sun,
I don't care a whit how those bits came into Sun's possession or why
Sun decided to ship them to me -- I care only that Sun's imprimatur is
on the distribution medium, and as a customer I think Sun needs to
support its product.

It's likely true that the coding work involved in supporting the
product is the community's problem.  That's Sun's business problem to
work out, and not an architectural stability issue.

> Most people who use free software interfaces, however, aren't looking
> for this level of stability.

I think that's a mistake.  Nobody likes breakage, particularly in
patches, and even with free software.

I've yet to run into someone who was even slightly thrilled to find
that something stopped working right after an upgrade.

> > What you're describing sounds like the "External" fiasco that we've
> > tried so hard to steer away from.  It sounds to me like we're not
> > being too successful at it.
> 
> In my experience working with ARC, ARC seems to promote keeping
> up-to-date with the FOSS community as a higher priority than worrying
> about FOSS interface stability levels.  This is my understanding why
> there are so many FOSS Volatile interfaces.

Keeping up-to-date doesn't mean you have to be Volatile as well.

The two aren't necessarily related.

> Perhaps that is changing?  In the past when I have suggested that
> ARC get more involved with external communities to promote better
> interface stability within those projects, the responses seem to be
> somewhere between ambivalent and negative.

I'm not sure how the OpenSolaris architectural review mechanism works
for some non-OpenSolaris project.  If those teams wanted to do so, I
don't see a problem with those folks deciding to participate in
OpenSolaris and getting their reviews here -- that'd certainly work --
but reaching out and saying in effect "we'd like to tell you how to
produce stable software" seems quite strange to me.

I don't think this ARC is the only way to produce stable software, or
that we're the only font of architectural information.  I think it's
entirely possible for other software projects to do a decent job of
engineering without necessarily needing (or even wanting) our help to
do it.

Thus, in my opinion, equating all external efforts that produce
essentially equivalent results with our lowest possible stability
level does them (and us) a substantial disservice.  They just can't be
that bad, and we can't possibly be that good.

> > When we know we're abusing the taxonomy, we should stop.  Even if
> > we're surrounded by others who are busily digging the same hole ever
> > deeper.
> 
> I'm not sure that we are abusing the taxonomy.  It depends what our
> priorities are.  Are we working to build an ironclad stable software
> platform based on FOSS components, or are we trying to provide a
> development platform that is competitive with Linux, or what?  How
> we classify FOSS interfaces should depend on what we are trying to
> achieve.

We're trying to build a system.  A big one.  Doing that requires
software architecture.

Part of software architecture is analyzing the dependencies and
stability levels *advertised* by the components.  If Jane says she'll
break her commitments in the next patch, but Sarah says she's building
on top of Jane's work, then we've got a problem.  It matters not
whether Jane promises to provide support, or Sarah says she'll
recompile every other Tuesday.  What matters is finding some way to
stabilize that dependency so that users of the software are not likely
to see the problems.

I don't think anyone here is suggesting that we ought not be
competitive with Linux.  And I agree completely that classifying FOSS
interfaces (and, actually, classifying *ALL* interfaces) should depend
on what we're trying to achieve.

If what we're trying to achieve is software that either breaks
fundamental rules of good design (by depending on things that change
in uncoordinated ways) or is useless once customers look behind the
glossy marketing materials (it has SQLite ... but Sun promises to
break it in a patch), then, by all means, lump it all in as "Volatile"
and don't worry about it.  I'd actually advocate skipping
architectural review entirely if that's what we want to achieve, as
it's a large expense with zero return for merely Volatile bits.

That's what was wrong with the "External" mess, and that's what we
were trying to avoid repeating.  FOSS != External and FOSS !=
Volatile.

> > Waving the "Volatile" flag at everything makes a mockery of the
> > intended process, every bit as much as External once did.
> 
> I have raised that concern myself.  However, I don't agree with you
> that it makes Solaris or ARC a mockery.  It just means that users who
> need Stability are limited from using a lot of FOSS components.  I'm
> not sure that is necessarily a problem.  It depends on what we are
> trying to achieve.

I am sure it's a problem.  Project teams cannot consistently come to
the ARC and say (in effect) "we're at the top of the food chain; we
depend on everyone, but nobody can ever depend on us, so we needn't
promise anything to anyone."  That's architectural death.

Brian Cameron writes:
> In the GNOME Project, the ORBIT2 and bonobo interfaces are stable and a
> part of the GNOME Platform, and covered under ABI guarantees.  In our
> Solaris distro they are "Volatile".
> 
> I can point you towards many references where the GNOME community
> discourages people from using these interfaces, and the GNOME community
> has announced that they will, someday, deprecate the interfaces (though
> they plan to continue supporting them in a stable fashion).

That sounds like "Obsolete Committed" to me.  It's an interface
they're not going to change, but that nobody new should be using
because they're planning to remove them eventually in the future.

Yes, an interface can be declared "Obsolete" when it's first
published.

(I seriously doubt that there are significant cases in the GNOME or
any other open source community that fail to fit nicely in the
existing taxonomy.  If there are, we'd certainly make room for them,
but it's not as if those stability levels were developed in a
technical vacuum.)

> In free software communities, even when you have the buy-in the of
> maintainer, I would never describe the risk as zero.

No change we ever make has zero risk.

Brian Cameron writes:
> It seems that to bring a new, external interface in as Volatile and
> then upgrade them to more stable classifications when there are clear
> users is not out-of-line with the evolutionary nature of how ARC is
> supposed to work.

It's not ... but the feedback you're getting is that when we know that
the interface is not as risky as advertised, then we're not doing
favors by claiming it is.

-- 
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 Darren.Moffat@sun.com Mon Feb  4 08:57: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 m14GvSCn007755
	for ; Mon, 4 Feb 2008 08:57:28 -0800 (PST)
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 m14GvOIq005272
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 5 Feb 2008 00:57:27 +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 <0JVQ001094FOWR00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 08:57:24 -0800 (PST)
Received: from gmp-eb-mail-1.sun.com ([192.18.6.21])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVQ0049T4FKXFD0@nwk-avmta-1.sfbay.Sun.COM> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon,
 04 Feb 2008 08:57:21 -0800 (PST)
Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11])
	by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m14GvKBo012404	for
 ; Mon, 04 Feb 2008 16:57:20 +0000 (GMT)
Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVQ006013X4G600@fe-emea-10.sun.com>
 (original mail from Darren.Moffat@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon,
 04 Feb 2008 16:57:20 +0000 (GMT)
Received: from [129.156.173.21] by fe-emea-10.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0JVQ009AV4FH5R20@fe-emea-10.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 16:57:17 +0000 (GMT)
Date: Mon, 04 Feb 2008 16:57:17 +0000
From: Darren J Moffat 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A391B0.5070006@Sun.Com>
Sender: Darren.Moffat@sun.com
To: John Plocher 
Cc: Brian Cameron , John Fischer ,
        "brian.lu" , lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <47A743ED.4060400@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <47A391B0.5070006@Sun.Com>
User-Agent: Thunderbird 2.0.0.6 (X11/20080102)
Status: RO
Content-Length: 1295

John Plocher wrote:

> Contract or not, since your team is putting it into Solaris, you
> are already committed to work with them to help avoid problems
> on the upgrade.  Changing Committed to Contracted Volatile doesn't
> actually change the amount and type of work that you already are
> going to need to perform...

Speaking from experience with OpenSSL a Contracted interface has a 
HIGHER burden on the supplier because they not only does the supplier 
need to do the analysis on wither and when to upgrade they also need to 
work with the contractees.  It also brings in a management and ARC 
member burden to sign all the new contracts.

For something that does not have a stable ABI and API, like OpenSSL, it 
might almost be worth it (I'm starting to doubt even that for OpenSSL 
now though); however for something that is known to be very stable and 
has explicit goals and past history in this area, like SQLite, Volatile 
and thus ARC contracts are an added and unnecessary burden on consumers.

If SQLite is Volatile then I'll expect a contract between Firefox 3.x 
and SQLite and that IIRC becomes a contract where (currently) the 
supplying and consuming manager are the same person (and should start to 
show the overhead of this).

"Simplify our business"

-- 
Darren J Moffat

From Nicolas.Williams@sun.com Mon Feb  4 09:23:26 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 m14HNQdd008786
	for ; Mon, 4 Feb 2008 09:23:26 -0800 (PST)
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 m14HNLT5036332;
	Mon, 4 Feb 2008 10:23:22 -0700 (MST)
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 <0JVQ00M0V5MXJ900@nwk-avmta-2.sfbay.sun.com>; Mon,
 04 Feb 2008 09:23:21 -0800 (PST)
Received: from binky.Central.Sun.COM ([129.153.128.104])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVQ00KGF5MUJD30@nwk-avmta-2.sfbay.sun.com>; Mon,
 04 Feb 2008 09:23:19 -0800 (PST)
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 m14HNIDa023033;
 Mon, 04 Feb 2008 11:23:18 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m14HNIlp023032; Mon,
 04 Feb 2008 11:23:18 -0600 (CST)
Date: Mon, 04 Feb 2008 11:23:18 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A743ED.4060400@Sun.COM>
To: Darren J Moffat 
Cc: John Plocher , John Fischer ,
        "brian.lu" , lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <20080204172318.GS19708@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <47A391B0.5070006@Sun.Com>
 <47A743ED.4060400@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: 1386

On Mon, Feb 04, 2008 at 04:57:17PM +0000, Darren J Moffat wrote:
> John Plocher wrote:
> 
> > Contract or not, since your team is putting it into Solaris, you
> > are already committed to work with them to help avoid problems
> > on the upgrade.  Changing Committed to Contracted Volatile doesn't
> > actually change the amount and type of work that you already are
> > going to need to perform...
> 
> Speaking from experience with OpenSSL a Contracted interface has a 
> HIGHER burden on the supplier because they not only does the supplier 
> need to do the analysis on wither and when to upgrade they also need to 
> work with the contractees.  It also brings in a management and ARC 
> member burden to sign all the new contracts.
> 
> For something that does not have a stable ABI and API, like OpenSSL, it 
> might almost be worth it (I'm starting to doubt even that for OpenSSL 
> now though); however for something that is known to be very stable and 
> has explicit goals and past history in this area, like SQLite, Volatile 
> and thus ARC contracts are an added and unnecessary burden on consumers.

For OpenSSL the DLL hell considerations w.r.t. shipping multiple
versions are serious enough, and DLL hell sufficiently likely, that it
is reasonable that shipping multiple versions should give us pause.  But
even so, I tend to agree: just ship multiple versions.

Nico
-- 

From Darren.Moffat@sun.com Mon Feb  4 09:28:46 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 m14HSkx4009395
	for ; Mon, 4 Feb 2008 09:28:46 -0800 (PST)
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 m14HSjIp013971
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 4 Feb 2008 09:28:45 -0800 (PST)
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 <0JVQ00N135VX1300@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 09:28:45 -0800 (PST)
Received: from gmp-eb-mail-2.sun.com ([192.18.6.24])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVQ00K8P5VVJ040@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon,
 04 Feb 2008 09:28:44 -0800 (PST)
Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11])
	by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m14HShlW005669	for
 ; Mon, 04 Feb 2008 17:28:43 +0000 (GMT)
Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVQ007015JQ8P00@fe-emea-10.sun.com>
 (original mail from Darren.Moffat@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon,
 04 Feb 2008 17:28:43 +0000 (GMT)
Received: from [129.156.173.21] by fe-emea-10.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 with ESMTPSA id <0JVQ009F45VT5R20@fe-emea-10.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 17:28:41 +0000 (GMT)
Date: Mon, 04 Feb 2008 17:28:41 +0000
From: Darren J Moffat 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <20080204172318.GS19708@Sun.COM>
Sender: Darren.Moffat@sun.com
To: Nicolas Williams 
Cc: John Plocher , John Fischer ,
        "brian.lu" , lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <47A74B49.3090107@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <47A391B0.5070006@Sun.Com>
 <47A743ED.4060400@Sun.COM> <20080204172318.GS19708@Sun.COM>
User-Agent: Thunderbird 2.0.0.6 (X11/20080102)
Status: RO
Content-Length: 546

Nicolas Williams wrote:
> For OpenSSL the DLL hell considerations w.r.t. shipping multiple
> versions are serious enough, and DLL hell sufficiently likely, that it
> is reasonable that shipping multiple versions should give us pause.  But
> even so, I tend to agree: just ship multiple versions.

Which is exactly why we still only ship one version, we have looked at 
shipping multiple versions of OpenSSL on several occasions and every 
time quickly found a process that would end up with more than one 
version in memory.

-- 
Darren J Moffat

From Brian.Cameron@sun.com Mon Feb  4 11:07:24 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 m14J7Ofx018006
	for ; Mon, 4 Feb 2008 11:07:24 -0800 (PST)
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 m14J7L30012799
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 4 Feb 2008 11:07:23 -0800 (PST)
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 <0JVQ00M0BAGAQE00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 12:07:22 -0700 (MST)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVQ006SUAG9U5B0@brm-avmta-1.central.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon,
 04 Feb 2008 12:07:21 -0700 (MST)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m14J7LKO013570	for
 ; Mon, 04 Feb 2008 19:07:21 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JVQ00E018UEOQ00@mail-amer.sun.com>
 (original mail from Brian.Cameron@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon,
 04 Feb 2008 12:07:21 -0700 (MST)
Received: from [192.168.1.64] ([189.137.195.67])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JVQ00E3QAFQC3D0@mail-amer.sun.com>; Mon,
 04 Feb 2008 12:07:06 -0700 (MST)
Date: Mon, 04 Feb 2008 13:07:03 -0600
From: Brian Cameron 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <18343.5039.948070.809532@gargle.gargle.HOWL>
Sender: Brian.Cameron@sun.com
To: James Carlson 
Cc: Nicolas Williams ,
        John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong ,
        Joseph.Kowalski@eng.sun.com
Message-id: <47A76257.6040308@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL> <47A3B2A0.8030906@sun.com>
 <47A3C965.9030107@Sun.Com> <47A3D4AC.5020902@sun.com>
 <20080202000825.GA19708@Sun.COM> <47A3B8A7.2010205@sun.com>
 <18343.5039.948070.809532@gargle.gargle.HOWL>
User-Agent: Thunderbird 2.0.0.9 (X11/20080128)
Status: RO
Content-Length: 14925


James:

I think the points raised in this case, that the SQLite community has
a good track record of interface stability is a good argument for
increasing its stability level.

That said, I have concerns with the suggestions that people are making
that *all* FOSS interfaces with the intent of stability should be at
least Uncommitted.  Or, as David Comay said previously in this thread:

 > But in general, *if* the intent is to provide a library which other
 > consumers can use, IMO it should be Uncommitted or higher.

When we were struggling to determine proper interface stability levels
for the GNOME stack, we worked closely with Joe Kowalski to determine
our plan.  With Joe's help, we decided that we needed the minimum set of
interfaces needed to write a good GNOME application needed to be
Committed.  We also decided that other interfaces, even if they are in
the GNOME Platform and have ABI compatibility guarantees, should be
Volatile unless there is real evidence that users need or depend on
them. We determined the list by reviewing what actual 3rd party ISV's
(firefox, thunderbird, Adobe Reader, RealPlayer, gimp, etc) actually
depend upon.  You can refer to the following case, where you can see
the following text in section 3:

      This interface table was compiled with the assistance and approval
      of Joe Kowalski.

      http://sac.eng.sun.com/arc/LSARC/2005/734/opinion.txt

So, since then, our stance has been that interfaces should be
Volatile unless there is a real use case that indicates users
should require the interface.

If we are saying that SQLite has a great interface stability track
record and such use cases, and therefore should not be Volatile, then
this makes sense to me.  However, if we are saying that all FOSS
interfaces with an intent to be stable should be Uncommitted or higher,
then this is a pretty big change in the way the JDS consolidation
approaches ARC.  I guess we may need to discuss this further when the
GNOME 2.22 ARC case is submitted.

>>> You don't need to promise to boil away the ocean to see if there might
>>> be rusty nails and other bugs at the bottom.
>> I'm not sure it always makes sense to mark a Solaris interface as
>> Committed or Uncommitted just because an external community has the
>> "intent" for stability.
> 
> So what do you make of the Sun projects that use these same commitment
> levels?  Would you expect a Sun team to disavow support because
> they're publishing Volatile interfaces?  Or that we provide some sort
> of special premium level of support for Committed interfaces?

I think Sun's stability levels are important.  Sun adds value by
standing behind its interfaces.

That said, I think Sun needs to be careful about what interfaces it
marks as Committed.  I think it makes the most sense for interfaces
that customers and users depend upon to be Committed.  I do not think
whether or not the external module maintainers intend Stability should
be the driving reason.

> In fact, the two are just plain unrelated.  The stability level
> communicates intent: it tells people when we will likely break things,
> and when we intend not to do so.  We can't possibly prevent all human
> mistakes, and we can't predict the future, so it's not possible for us
> to say anything more than *intent."

In a sense I agree with you.  In this discussion "track record" has
also been cited as a factor that should affect stability levels.  A
project's future "track record" is also important, and it can be hard to
predict the future.  Even projects with good track records can stumble.

Some modules are more risky than others, and some mistakes are
more expensive to fix than others.  In addition to communicating
stability levels, ARC is about managing these risks.

> Whether and how a customer gets support is a separate business
> decision and a matter of appropriate documentation.  It could be
> through some Sun-provided on-site team.  It could be an on-demand
> service.  It could be a third party with whom Sun contracts.  It could
> even be some open source forum.  Perhaps even "no support at all."
> 
> I'm not buying the argument that "Volatile" can or should mean "we
> won't try very hard to support this."  The ARC doesn't make or
> evaluate support commitments.

I agree with you.  Using "Volatile" to mean "no support" is bad
practice.  In much the same way as using "External" used to be
problematic.  However, higher interface stability levels does affect
resourcing and our ability to support interfaces.

While it may not make sense, from an architectural perspective, to
worry about support commitments, I am sure you can understand why a
project team with limited resources might want to be conservative
about the interface stability levels it signs up to.  I also think
it is perfectly reasonable for ARC to challenge proposed stability
levels when they are inappropriate.

>>> Or you (the consumer) may well be assuming a higher stability level.
>>> In other words, you know that SQLite is stable, and Sun has applied
>>> the wrong stability level.  You chuckle at the "Volatile" label and
>>> plow on.
>> If I were a customer, I would understand that Volatile means that
>> Sun isn't going to support me if I have problems.  If I know the
>> SQLite community will take care of me, then I might be agreeable
>> to not worrying about the lack of Sun support.
> 
> That doesn't make sense here.  Sun is providing the SQLite packages.
> There's no way that community can "take care of" anybody; it doesn't
> produce the signed SUNW* packages or patches.  Sun itself will have to
> do that.

When I said "take care of", I meant the customer was placing their
trust in the external communities stability guarantee and track
record rather than in Sun's stability promise.

>> Most people who use free software interfaces, however, aren't looking
>> for this level of stability.
> 
> I think that's a mistake.  Nobody likes breakage, particularly in
> patches, and even with free software.
> 
> I've yet to run into someone who was even slightly thrilled to find
> that something stopped working right after an upgrade.

Oh, I agree.  I think we are simply talking about the tension between
keeping up with the latest & greatest and keeping things stable.  I
do not think it is possible to have both all the time.  I believe there
are likely some Volatile interfaces that are needed in order to keep
up with the bleeding edge.  I think what we try to do in ARC is to
make sure that any such Volatile interfaces are not likely to create
undue problems for our users.  This can be achieved, I think, by good
documentation, and by ensuring that end-users can write the programs
they need without depending on any Volatile interfaces.  Such Volatile
interfaces should be clearly marked as being for bleeding edge users
only.

>> Perhaps that is changing?  In the past when I have suggested that
>> ARC get more involved with external communities to promote better
>> interface stability within those projects, the responses seem to be
>> somewhere between ambivalent and negative.
> 
> I'm not sure how the OpenSolaris architectural review mechanism works
> for some non-OpenSolaris project.  If those teams wanted to do so, I
> don't see a problem with those folks deciding to participate in
> OpenSolaris and getting their reviews here -- that'd certainly work --
> but reaching out and saying in effect "we'd like to tell you how to
> produce stable software" seems quite strange to me.

You misunderstand my suggestion.  I have seen numerous FOSS-related ARC
cases where all exported interfaces are Volatile be approved without
much question.  While it may be too much to expect ARC to be directly
involved with external communities, I think it would be helpful if ARC
were to ask questions to determine the degree the project team is
involved with the external community.  If this level is found to be
lacking, then ARC could recommend that this is important and give
ideas (perhaps best practices) to help the project team engage
effectively.

For example, good documentation (manpage/API docs) is an aspect of
interface stablity.  If a project is missing manpages or API docs,
then this could raise a red flag.  Perhaps ARC should encourage
the project team to work with the external community to help fix
such documentation problems.

> I don't think this ARC is the only way to produce stable software, or
> that we're the only font of architectural information.  I think it's
> entirely possible for other software projects to do a decent job of
> engineering without necessarily needing (or even wanting) our help to
> do it.

Exactly.  For example, there is FreeDesktop.org, which relates to
desktop specifications.  I would think that when ARC sees a desktop
related FOSS case, that asking questions about how the project works
with FreeDesktop would be a good question.  If the answer is "What
is FreeDesktop.org" then perhaps ARC should recommend getting more
involved or engaged with that community, etc.

> Thus, in my opinion, equating all external efforts that produce
> essentially equivalent results with our lowest possible stability
> level does them (and us) a substantial disservice.  They just can't be
> that bad, and we can't possibly be that good.

My suggestions that ARC be more aware and supportive of external
interface stability efforts have been unpopular.  However, it is
hard for me to understand how this does anybody a disservice.
Encouraging project teams to be more involved with the external
projects they work with just seems like common sense to me.

Perhaps it is not ARC's job to do such encouraging, but people seem
to agree that it benefits ARC when project teams do get so involved.
John Plocher, for example, suggested that FOSS project teams should
get more involved with ARC.  In my opinion, it make most sense for ARC
to encourage project teams as well.  In my opinion, we probably need
a holistic attitude where both ARC and Project Teams change they way
they approach things, rather than just expecting Project Teams to be
more involved.

>>> When we know we're abusing the taxonomy, we should stop.  Even if
>>> we're surrounded by others who are busily digging the same hole ever
>>> deeper.
>> I'm not sure that we are abusing the taxonomy.  It depends what our
>> priorities are.  Are we working to build an ironclad stable software
>> platform based on FOSS components, or are we trying to provide a
>> development platform that is competitive with Linux, or what?  How
>> we classify FOSS interfaces should depend on what we are trying to
>> achieve.
> 
> We're trying to build a system.  A big one.  Doing that requires
> software architecture.
> 
> Part of software architecture is analyzing the dependencies and
> stability levels *advertised* by the components.  If Jane says she'll
> break her commitments in the next patch, but Sarah says she's building
> on top of Jane's work, then we've got a problem.  It matters not
> whether Jane promises to provide support, or Sarah says she'll
> recompile every other Tuesday.  What matters is finding some way to
> stabilize that dependency so that users of the software are not likely
> to see the problems.
> 
> I don't think anyone here is suggesting that we ought not be
> competitive with Linux.  And I agree completely that classifying FOSS
> interfaces (and, actually, classifying *ALL* interfaces) should depend
> on what we're trying to achieve.
> 
> If what we're trying to achieve is software that either breaks
> fundamental rules of good design (by depending on things that change
> in uncoordinated ways) or is useless once customers look behind the
> glossy marketing materials (it has SQLite ... but Sun promises to
> break it in a patch), then, by all means, lump it all in as "Volatile"
> and don't worry about it.  I'd actually advocate skipping
> architectural review entirely if that's what we want to achieve, as
> it's a large expense with zero return for merely Volatile bits.
> 
> That's what was wrong with the "External" mess, and that's what we
> were trying to avoid repeating.  FOSS != External and FOSS !=
> Volatile.

I agree with you.  That said, I think the right solution is somewhere
in between making all FOSS interfaces Volatile and making all interfaces
"other consumers can use, IMO it should be Uncommitted or higher."

> Brian Cameron writes:
>> In the GNOME Project, the ORBIT2 and bonobo interfaces are stable and a
>> part of the GNOME Platform, and covered under ABI guarantees.  In our
>> Solaris distro they are "Volatile".
>>
>> I can point you towards many references where the GNOME community
>> discourages people from using these interfaces, and the GNOME community
>> has announced that they will, someday, deprecate the interfaces (though
>> they plan to continue supporting them in a stable fashion).
> 
> That sounds like "Obsolete Committed" to me.  It's an interface
> they're not going to change, but that nobody new should be using
> because they're planning to remove them eventually in the future.

Right, but one complication is that (for some tasks) there is no other
interface to use.  For example, Accessibility programs will continue
to require ORBit2/bonbobo until the port to using D-Bus is finished.
No visibility on how long that will take.  Perhaps this is not a
problem, though.

> Yes, an interface can be declared "Obsolete" when it's first
> published.
> 
> (I seriously doubt that there are significant cases in the GNOME or
> any other open source community that fail to fit nicely in the
> existing taxonomy.  If there are, we'd certainly make room for them,
> but it's not as if those stability levels were developed in a
> technical vacuum.)

Perhaps not in GNOME, which has a somewhat reasonable interface
stability story.  However, with the Indiana project's desire to make
an OS that is more developer friendly, I think we will likely see a
rash of ARC cases over the next few months that will be a challenge
to properly classify.  I think we're already seeing some tension, for
example, with the FOSS C++ and garbage collection ARC cases that are
starting to show up via Indiana.

> Brian Cameron writes:
>> It seems that to bring a new, external interface in as Volatile and
>> then upgrade them to more stable classifications when there are clear
>> users is not out-of-line with the evolutionary nature of how ARC is
>> supposed to work.
> 
> It's not ... but the feedback you're getting is that when we know that
> the interface is not as risky as advertised, then we're not doing
> favors by claiming it is.

In terms of SQLite, I agree 100%.  However, I have concerns with some
of the recent suggestions that all public facing interfaces need higher
stability levels.  But, we can discuss these concerns in other ARC
cases where this issues are more relevant, such as the upcoming GNOME
2.22 ARC case.

Brian


From bart.smaalders@sun.com Mon Feb  4 11:40:12 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 m14JeC1k019244
	for ; Mon, 4 Feb 2008 11:40:12 -0800 (PST)
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 m14Je85f029245;
	Mon, 4 Feb 2008 11:40:08 -0800 (PST)
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 <0JVQ00H0VBYW0400@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 04 Feb 2008 11:40:08 -0800 (PST)
Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVQ0047RBYVKGA0@nwk-avmta-1.sfbay.Sun.COM>; Mon,
 04 Feb 2008 11:40:07 -0800 (PST)
Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109])
	by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2)
 with ESMTP id m14Je6q9512724; Mon, 04 Feb 2008 11:40:06 -0800 (PST)
Date: Mon, 04 Feb 2008 11:35:28 -0800
From: Bart Smaalders 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A76257.6040308@sun.com>
To: Brian Cameron 
Cc: James Carlson ,
        John Fischer , "brian.lu" ,
        John Plocher , lsarc-ext@sun.com,
        Evan.Yan@sun.com, Elaine Xiong ,
        Joseph.Kowalski@eng.sun.com
Message-id: <47A76900.7010701@Sun.COM>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL> <47A3B2A0.8030906@sun.com>
 <47A3C965.9030107@Sun.Com> <47A3D4AC.5020902@sun.com>
 <20080202000825.GA19708@Sun.COM> <47A3B8A7.2010205@sun.com>
 <18343.5039.948070.809532@gargle.gargle.HOWL> <47A76257.6040308@sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20070924)
Status: RO
Content-Length: 938

Brian Cameron wrote:
> 
> So, since then, our stance has been that interfaces should be
> Volatile unless there is a real use case that indicates users
> should require the interface.
> 

So Joe OpenSolaris feels that inkscape would be a nice feature to add
to Solaris.... configure works, and the engineer discovers that
he's linking several libraries in usr/lib that are delivered
by JDS.  His SFW sponsor tells him that 5 of those libraries
have Volatile commitment levels, and cannot be linked with from
SFW w/o having his manager sign a contract.  He has no manager;
he's a OpenSolaris contributor.

What does he do now?

  1) figure out how to deliver into JDS?
  2) wait for us to revise the contract system to work
     with outside contributors...
  3) give up in disgust.

I think we need to rethink our processes.

- Bart





-- 
Bart Smaalders			Solaris Kernel Performance
barts@cyber.eng.sun.com		http://blogs.sun.com/barts

From John.Plocher@sun.com Mon Feb  4 12:53: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 m14Kra5v022576
	for ; Mon, 4 Feb 2008 12:53:36 -0800 (PST)
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 m14KrYlh019645
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 4 Feb 2008 12:53:35 -0800 (PST)
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 <0JVQ0000JFDBQY00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 12:53:35 -0800 (PST)
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 <0JVQ000EQFDAP700@nwk-avmta-1.sfbay.Sun.COM> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon,
 04 Feb 2008 12:53:34 -0800 (PST)
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 m14KrYpG019830	for
 ; Mon, 04 Feb 2008 12:53:34 -0800 (PST)
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 <0JVQ00L01F993B00@fe-sfbay-10.sun.com>
 (original mail from John.Plocher@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon,
 04 Feb 2008 12:53:34 -0800 (PST)
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 <0JVQ00IBQFD9U520@fe-sfbay-10.sun.com>; Mon,
 04 Feb 2008 12:53:33 -0800 (PST)
Date: Mon, 04 Feb 2008 12:53:31 -0800
From: John Plocher 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A76257.6040308@sun.com>
Sender: John.Plocher@sun.com
To: Brian Cameron 
Cc: James Carlson ,
        Nicolas Williams ,
        John Fischer , "brian.lu" ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong , Joseph.Kowalski@eng.sun.com
Message-id: <47A77B4B.9060302@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@sun.com> <20080131182049.GA15877@Sun.COM>
 <47A2DA34.5060807@sun.com> <47A3530C.6010808@Sun.Com>
 <47A377C9.3030808@sun.com> <20080201200950.GJ19708@Sun.COM>
 <20080201202216.GK19708@Sun.COM> <47A3804C.1060904@sun.com>
 <20080201204022.GM19708@Sun.COM> <47A38D9F.4060707@sun.com>
 <18339.39955.249969.60011@gargle.gargle.HOWL> <47A3B2A0.8030906@sun.com>
 <47A3C965.9030107@Sun.Com> <47A3D4AC.5020902@sun.com>
 <20080202000825.GA19708@Sun.COM> <47A3B8A7.2010205@sun.com>
 <18343.5039.948070.809532@gargle.gargle.HOWL> <47A76257.6040308@sun.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
Status: RO
Content-Length: 2421

Brian Cameron wrote:
> If we are saying that SQLite has a great interface stability track
> record and such use cases, and therefore should not be Volatile, then
> this makes sense to me.  However, if we are saying that all FOSS
> interfaces with an intent to be stable should be Uncommitted or higher,

When we reviewed GNOME way back when, we came to the reasonable
conclusion that most of what was there was poorly characterized, and
thus not ready for prime time Committed status.  This created a tension
because we were going to build a bunch of dependencies on /some/ parts
of it, and those parts really needed to be more stable than Volatile.

As a best practice, when incorporating something large and unknown,
we have found that a good 1st step is to minimize the stability
expectations; thus Joe's good advice to find the 5 to 10 things
in a FOSS component that really need to be Committed, and leave
the rest Volatile.

There are two failure modes here - too little and too much commitment.

I covered "Too little" earlier - Volatile makes it significantly
harder and costlier to depend on a component.

"Too Much" is well illustrated by an early version of BIND,
where the case submitter claimed that /everything/ in the FOSS
deliverable was Committed. Of course, when BINDv(n+1) came out,
it turned out that that was a foolish thing to do - many parts of
BIND.old were in fact obsolete, experimental or otherwise
uncommitted by the BIND community, and the new version changed
or eliminated them.  This put us in a very undesirable situation:

	our customers wanted the new version of BIND, and

	our developers wanted to deliver the new version of BIND, and

	we wanted to deploy the new version of BIND,

	BUT

	we had sprinkled dependencies on those 	"not really committed"
	interfaces throughout our own extended source tree, and couldn't
	easily update them all.

Once we know more about a component, we should be able to
make better guesses at what those committed interfaces should
be.  In cases like SQLite, where there /is/ demonstrated stability
over time AND a commitment by the supplier to value compatibility,
an "everything is Volitile" label fails the "least surprise" test :-)

> ... Sun needs to be careful about what interfaces it
> marks as Committed.  

Absolutely.  Marking too many things as Committed is just the other
end of the pendulum swing as marking too many Volatile.

   -John


From John.Fischer@sun.com Wed Feb  6 16:00:39 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 m1700cju003161
	for ; Wed, 6 Feb 2008 16:00:39 -0800 (PST)
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 m1700NSF009618
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 7 Feb 2008 08:00:37 +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 <0JVU00A01DD10W00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Wed, 06 Feb 2008 16:00:37 -0800 (PST)
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 <0JVU003MRDD05JA0@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed,
 06 Feb 2008 16:00:36 -0800 (PST)
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 m1700aq0016106	for
 ; Wed, 06 Feb 2008 16:00:36 -0800 (PST)
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 <0JVU00101DBWF800@fe-sfbay-09.sun.com>
 (original mail from John.Fischer@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed,
 06 Feb 2008 16:00:36 -0800 (PST)
Received: from [192.168.10.6] ([24.10.86.139])
 by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JVU00DC7DCNU640@fe-sfbay-09.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed,
 06 Feb 2008 16:00:24 -0800 (PST)
Date: Wed, 06 Feb 2008 16:00:15 -0800
From: John Fischer 
Subject: Re: LSARC/2008/059 SQLite
Sender: John.Fischer@sun.com
To: Elaine Xiong , Evan Yan ,
        "brian.lu" , lsarc-ext@sun.com
Reply-to: John.Fischer@sun.com
Message-id: <47AA4A0F.1000508@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
User-Agent: Thunderbird 2.0.0.4 (X11/20070622)
Status: RO
Content-Length: 173

Elaine,

I have extended the timer on this case as we need to talk
about the interface classifications.  The new timer is set
for Friday February 15th, 2008.

Thanks,

John

From jyri@buye.red.iplanet.com Thu Feb  7 17:04:24 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 m1814Nu0020862
	for ; Thu, 7 Feb 2008 17:04:24 -0800 (PST)
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 m18145Mc012012;
	Fri, 8 Feb 2008 09:04:17 +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 <0JVW0040FAZ4MT00@nwk-avmta-2.sfbay.sun.com>; Thu,
 07 Feb 2008 17:04:16 -0800 (PST)
Received: from buye.red.iplanet.com ([192.18.65.224])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVW00HR7AZ3VPC0@nwk-avmta-2.sfbay.sun.com>; Thu,
 07 Feb 2008 17:04:15 -0800 (PST)
Received: from buye.red.iplanet.com (localhost [127.0.0.1])
	by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m1814FcV007079; Thu,
 07 Feb 2008 17:04:15 -0800 (PST)
Received: (from jyri@localhost)
	by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m1814FGd007078; Thu,
 07 Feb 2008 17:04:15 -0800 (PST)
Date: Thu, 07 Feb 2008 17:04:15 -0800
From: Jyri Virkki 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3C965.9030107@Sun.Com>
To: John Plocher 
Cc: Brian Cameron ,
        James Carlson ,
        Nicolas Williams ,
        John Fischer , "brian.lu" ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong , Henry.Jen@sun.com
Message-id: <20080208010415.GK6789@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <47A3530C.6010808@Sun.Com> <47A377C9.3030808@sun.com>
 <20080201200950.GJ19708@Sun.COM> <20080201202216.GK19708@Sun.COM>
 <47A3804C.1060904@sun.com> <20080201204022.GM19708@Sun.COM>
 <47A38D9F.4060707@sun.com> <18339.39955.249969.60011@gargle.gargle.HOWL>
 <47A3B2A0.8030906@sun.com> <47A3C965.9030107@Sun.Com>
User-Agent: Mutt/1.5.11
Status: RO
Content-Length: 410

John Plocher wrote:
>
> If you have 10 teams that reuse your stuff, this translates into

For the record, there was a recent conversation about creating APR
packages (stand-alone from Apache) and there was interest in having it
use SQLite3, so there's at least one expectant consumer from a different
consolidation.


(Don't know about the other 9.)
-- 
Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems

From jyri@buye.red.iplanet.com Thu Feb  7 17:40:08 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 m181e7Bq021073
	for ; Thu, 7 Feb 2008 17:40:07 -0800 (PST)
Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11])
	by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m181duLn015260;
	Fri, 8 Feb 2008 01:40:01 GMT
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 <0JVW00E03CMJXI00@brm-avmta-1.central.sun.com>; Thu,
 07 Feb 2008 18:39:55 -0700 (MST)
Received: from buye.red.iplanet.com ([192.18.65.224])
 by brm-avmta-1.central.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JVW00LGOCMIHIE0@brm-avmta-1.central.sun.com>; Thu,
 07 Feb 2008 18:39:54 -0700 (MST)
Received: from buye.red.iplanet.com (localhost [127.0.0.1])
	by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m181dsEu007106; Thu,
 07 Feb 2008 17:39:54 -0800 (PST)
Received: (from jyri@localhost)
	by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m181dsVX007105; Thu,
 07 Feb 2008 17:39:54 -0800 (PST)
Date: Thu, 07 Feb 2008 17:39:54 -0800
From: Jyri Virkki 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <47A3B04D.4040004@Sun.Com>
To: John Plocher 
Cc: Alan Coopersmith ,
        Brian Cameron ,
        Nicolas Williams ,
        John Fischer , "brian.lu" ,
        lsarc-ext@sun.com, Evan.Yan@sun.com,
        Elaine Xiong 
Message-id: <20080208013954.GL6789@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <20080131182049.GA15877@Sun.COM> <47A2DA34.5060807@sun.com>
 <47A3530C.6010808@Sun.Com> <47A377C9.3030808@sun.com>
 <20080201200950.GJ19708@Sun.COM> <20080201202216.GK19708@Sun.COM>
 <47A3804C.1060904@sun.com> <47A3A250.6070004@Sun.Com>
 <47A3A95B.4030104@sun.com> <47A3B04D.4040004@Sun.Com>
User-Agent: Mutt/1.5.11
Status: RO
Content-Length: 778

John Plocher wrote:
>
> When you dig down into the thing called "Solaris", you find the following
> components/consolidations:
[...]
> Each one of these has its own release taxonomy value; it is safe to
> say that only ON has a fixation on never doing a major release. 

Hmm..

You're stating that SFW (to pick SFW since most open source components
are there so it matches the topic of the thread) could declare itself
a Major release every so often, independent of the Solaris release
it's going into?

In that case there's no problem marking every open source interface
Committed!  Whenever something breaks SFW can handle it by doing a
Major release.

I doubt that's what you meant but it's what the email said...

-- 
Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems

From John.Plocher@sun.com Thu Feb  7 20:00:19 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 m1840IYP024988
	for ; Thu, 7 Feb 2008 20:00:19 -0800 (PST)
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 m1840Gnq017155
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 8 Feb 2008 12:00:18 +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 <0JVW00D07J4GLR00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Thu, 07 Feb 2008 20:00:16 -0800 (PST)
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 <0JVW006DYJ4GSW70@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu,
 07 Feb 2008 20:00:16 -0800 (PST)
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 m1840GcB010823	for
 ; Thu, 07 Feb 2008 20:00:16 -0800 (PST)
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 <0JVW00001J1OE800@fe-sfbay-09.sun.com>
 (original mail from John.Plocher@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu,
 07 Feb 2008 20:00:15 -0800 (PST)
Received: from [192.168.168.4] ([208.74.177.212])
 by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JVW00BIKJ4D0L60@fe-sfbay-09.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu,
 07 Feb 2008 20:00:13 -0800 (PST)
Date: Thu, 07 Feb 2008 20:00:13 -0800
From: John Plocher 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <20080208013954.GL6789@sun.com>
Sender: John.Plocher@sun.com
To: Jyri Virkki 
Cc: lsarc-ext@sun.com
Message-id: <47ABD3CD.5090609@Sun.Com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <20080131182049.GA15877@Sun.COM> <47A2DA34.5060807@sun.com>
 <47A3530C.6010808@Sun.Com> <47A377C9.3030808@sun.com>
 <20080201200950.GJ19708@Sun.COM> <20080201202216.GK19708@Sun.COM>
 <47A3804C.1060904@sun.com> <47A3A250.6070004@Sun.Com>
 <47A3A95B.4030104@sun.com> <47A3B04D.4040004@Sun.Com>
 <20080208013954.GL6789@sun.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
Status: RO
Content-Length: 806

Jyri Virkki wrote:
> In that case there's no problem marking every open source interface
> Committed!  Whenever something breaks SFW can handle it by doing a
> Major release.
> 
> I doubt that's what you meant but it's what the email said...


That /is/ what I meant.

We do this today, sortof.  The SFW with Solaris9 did "no incompatible
change" style releases for all of the S9 update releases, then an
"update everything" release for S10, and again is doing "no incompat
change" releases for the S10updates...

This even maps to major and minor (or even minor and micro...) at
some level :-)

The key is that the release-that-contains-incompat-changes is
coordinated with a minor release of Solaris by both the SFW
consolidation keepers and the Solaris product team/Release
Engineering team
    -John



From Henry.Jen@sun.com Fri Feb  8 16:22:31 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 m190MUmI029545
	for ; Fri, 8 Feb 2008 16:22:31 -0800 (PST)
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 m190MP7O004340
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Sat, 9 Feb 2008 08:22:30 +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 <0JVY00L1H3PHNY00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Fri, 08 Feb 2008 16:22:29 -0800 (PST)
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 <0JVY00IWJ3PFB030@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 08 Feb 2008 16:22:27 -0800 (PST)
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 m190MRMd026812	for
 ; Fri, 08 Feb 2008 16:22:27 -0800 (PST)
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 <0JVY004013KFIO00@fe-sfbay-10.sun.com>
 (original mail from Henry.Jen@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 08 Feb 2008 16:22:27 -0800 (PST)
Received: from [192.168.123.103] ([71.202.141.87])
 by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb
 28 2007)) with ESMTPSA id <0JVY0094I3P7Y980@fe-sfbay-10.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri,
 08 Feb 2008 16:22:20 -0800 (PST)
Date: Fri, 08 Feb 2008 16:22:19 -0800
From: Henry Jen 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <20080208010415.GK6789@sun.com>
Sender: Henry.Jen@sun.com
To: Jyri Virkki , lsarc-ext@sun.com
Cc: John Plocher , Brian Cameron ,
        James Carlson ,
        Nicolas Williams ,
        John Fischer , "brian.lu" ,
        Evan.Yan@sun.com, Elaine Xiong 
Message-id: <47ACF23B.2050208@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <47A3530C.6010808@Sun.Com> <47A377C9.3030808@sun.com>
 <20080201200950.GJ19708@Sun.COM> <20080201202216.GK19708@Sun.COM>
 <47A3804C.1060904@sun.com> <20080201204022.GM19708@Sun.COM>
 <47A38D9F.4060707@sun.com> <18339.39955.249969.60011@gargle.gargle.HOWL>
 <47A3B2A0.8030906@sun.com> <47A3C965.9030107@Sun.Com>
 <20080208010415.GK6789@sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071203)
Status: RO
Content-Length: 1408

Jyri Virkki wrote:
> John Plocher wrote:
>> If you have 10 teams that reuse your stuff, this translates into
> 
> For the record, there was a recent conversation about creating APR
> packages (stand-alone from Apache) and there was interest in having it
> use SQLite3, so there's at least one expectant consumer from a different
> consolidation.
> 
> 

After going through the forum, I think it comes down to the question I 
was asking:

What is the right way to deliver packages into Solaris/Nevada involves 
multiple consolidations[1]?

[1] http://www.opensolaris.org/jive/thread.jspa?threadID=46072&tstart=15


Bear with me that I am not at all familiar with the internal process and 
consolidations. I worked on project JXTA, particular the C 
implementation and running Nevada on my laptop all the time. Really 
likes to have Solaris take over the developer desktop. :-) So you can 
consider me the "Joe OpenSolaris" in Bart's post.

I know this may sound strange, but maybe what we need is a new 
consolidation that is fully self-contained, meaning no dependency to 
other consolidation except the minimum base system(Is this ON?), then 
packages needed by multiple consolidations should simply moved to this 
consolidation.

This consolidation is now the contract between consolidations using a 
common package from it. Resource wise, whoever has a problem with a 
package, fix it. :-)

Cheers,
Henry

From jyri@buye.red.iplanet.com Wed Feb 20 15:14:21 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 m1KNELDs012232
	for ; Wed, 20 Feb 2008 15:14:21 -0800 (PST)
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 m1KNEEQv030869;
	Wed, 20 Feb 2008 16:14:17 -0700 (MST)
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 <0JWK00F0X8JS2000@nwk-avmta-2.sfbay.sun.com>; Wed,
 20 Feb 2008 15:14:16 -0800 (PST)
Received: from buye.red.iplanet.com ([192.18.65.224])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JWK00DEN8JQST20@nwk-avmta-2.sfbay.sun.com>; Wed,
 20 Feb 2008 15:14:14 -0800 (PST)
Received: from buye.red.iplanet.com (localhost [127.0.0.1])
	by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m1KNEEtD016119; Wed,
 20 Feb 2008 15:14:14 -0800 (PST)
Received: (from jyri@localhost)
	by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m1KNEE3W016118; Wed,
 20 Feb 2008 15:14:14 -0800 (PST)
Date: Wed, 20 Feb 2008 15:14:14 -0800
From: Jyri Virkki 
Subject: Re: SQLite3.x [PSARC/2008/120 FastTrack timeout 02/27/2008]
 (LSARC/2008/059)
In-reply-to: <20080220230004.GU14350@Sun.COM>
To: Jyri Virkki , Darren Kenny ,
        Nicolas Williams , psarc-ext@sun.com,
        Brian.Lu@sun.com, Elaine.Xiong@sun.com, Evan.Yan@sun.com
Message-id: <20080220231414.GL15615@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <200802172250.m1HMoKOj014674@sac.sfbay.sun.com>
 <20080220004117.GT11415@sun.com> <47BC151B.8050302@Sun.COM>
 <20080220134243.GS14350@Sun.COM> <20080220224615.GG15615@sun.com>
 <20080220230004.GU14350@Sun.COM>
User-Agent: Mutt/1.5.11
x_sac_archived: PSARC/2008/120
Status: RO
Content-Length: 837

Nicolas Williams wrote:
>
> It's my intention that either I or John Fischer will do that.  We've not
> decided when -- e.g., when this case is approved, perhaps.
> 
> The mail record for LSARC/2008/059 should already have e-mail indicating
> that the i-team ceded the case to me and that I'd either take it over or
> file a new case.

There isn't any hint yet in email log of LSARC/2008/059 that it has been
superseded nor any pointer to this new case (I just re-read it).

Should LSARC continue reviewing 2008/059?  Or should in fact it be
closed approved given it is showing a timeout date of 2/15?

Probably not, given this case, but I'm only finding out by hanging out
in psarc-ext... there isn't anything in LSARC/2008/059 record stating
LSARC should stop processing it.

-- 
Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems

From Nicolas.Williams@sun.com Wed Feb 20 15:21:47 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 m1KNLk3F012374
	for ; Wed, 20 Feb 2008 15:21:46 -0800 (PST)
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 m1KNLQiC020042;
	Thu, 21 Feb 2008 07:21:41 +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 <0JWK00H038W4E400@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 20 Feb 2008 15:21:40 -0800 (PST)
Received: from binky.Central.Sun.COM ([129.153.128.104])
 by nwk-avmta-1.sfbay.Sun.COM
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JWK00GFW8W3G400@nwk-avmta-1.sfbay.Sun.COM>; Wed,
 20 Feb 2008 15:21:39 -0800 (PST)
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 m1KNLcxo015763;
 Wed, 20 Feb 2008 17:21:38 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1KNLcvP015762; Wed,
 20 Feb 2008 17:21:38 -0600 (CST)
Date: Wed, 20 Feb 2008 17:21:38 -0600
From: Nicolas Williams 
Subject: Re: SQLite3.x [PSARC/2008/120 FastTrack timeout 02/27/2008]
 (LSARC/2008/059)
In-reply-to: <20080220231414.GL15615@sun.com>
To: Jyri Virkki 
Cc: Darren Kenny ,
        Nicolas Williams , psarc-ext@sun.com,
        Brian.Lu@sun.com, Elaine.Xiong@sun.com, Evan.Yan@sun.com,
        John Fischer 
Mail-followup-to: Jyri Virkki ,
 Darren Kenny ,
 Nicolas Williams , psarc-ext@sun.com,
 Brian.Lu@sun.com, Elaine.Xiong@sun.com, Evan.Yan@sun.com,
 John Fischer 
Message-id: <20080220232138.GW14350@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <200802172250.m1HMoKOj014674@sac.sfbay.sun.com>
 <20080220004117.GT11415@sun.com> <47BC151B.8050302@Sun.COM>
 <20080220134243.GS14350@Sun.COM> <20080220224615.GG15615@sun.com>
 <20080220230004.GU14350@Sun.COM> <20080220231414.GL15615@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: 982

On Wed, Feb 20, 2008 at 03:14:14PM -0800, Jyri Virkki wrote:
> Nicolas Williams wrote:
> >
> > It's my intention that either I or John Fischer will do that.  We've not
> > decided when -- e.g., when this case is approved, perhaps.
> > 
> > The mail record for LSARC/2008/059 should already have e-mail indicating
> > that the i-team ceded the case to me and that I'd either take it over or
> > file a new case.
> 
> There isn't any hint yet in email log of LSARC/2008/059 that it has been
> superseded nor any pointer to this new case (I just re-read it).

Hmmm, maybe those e-mails did not cc the case record.  I will send a
heads up.

> Should LSARC continue reviewing 2008/059?  Or should in fact it be
> closed approved given it is showing a timeout date of 2/15?
> 
> Probably not, given this case, but I'm only finding out by hanging out
> in psarc-ext... there isn't anything in LSARC/2008/059 record stating
> LSARC should stop processing it.

Yeah, probably not.

Nico
-- 

From Nicolas.Williams@sun.com Wed Feb 20 15:24:09 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 m1KNO8Om012424
	for ; Wed, 20 Feb 2008 15:24:09 -0800 (PST)
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 m1KNNvRO021057;
	Thu, 21 Feb 2008 07:24:06 +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 <0JWK00F05903FW00@nwk-avmta-2.sfbay.sun.com>; Wed,
 20 Feb 2008 15:24:03 -0800 (PST)
Received: from binky.Central.Sun.COM ([129.153.128.104])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JWK00DKH902SN20@nwk-avmta-2.sfbay.sun.com>; Wed,
 20 Feb 2008 15:24:03 -0800 (PST)
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 m1KNO2AS015770;
 Wed, 20 Feb 2008 17:24:02 -0600 (CST)
Received: (from nw141292@localhost)
	by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1KNO2TB015769; Wed,
 20 Feb 2008 17:24:02 -0600 (CST)
Date: Wed, 20 Feb 2008 17:24:02 -0600
From: Nicolas Williams 
Subject: Re: LSARC/2008/059 - SQLite
In-reply-to: <479FAFE1.5020601@sun.com>
To: John Fischer 
Cc: Elaine.Xiong@sun.com, Evan.Yan@sun.com, "brian.lu" ,
        lsarc-ext@sun.com
Message-id: <20080220232402.GX14350@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-PMX-Version: 5.2.0.264296
References: <479FAFE1.5020601@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: 290

Off-line Brian Cameron agreed that I could take over this case.  I've
filed:

PSARC/2008/120 SQLite3.x

which will almost certainly supercede this one.

I leave it to John Fischer to mark this one as such.  I'm not sure if we
should wait for PSARC/2008/120 to be approved.  John?

Nico
-- 

From John.Fischer@sun.com Wed Feb 20 16:30:03 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 m1L0U32A018320
	for ; Wed, 20 Feb 2008 16:30:03 -0800 (PST)
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 m1L0U2lZ018496
	for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 20 Feb 2008 16:30:03 -0800 (PST)
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 <0JWK00I1LC233V00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com
 (ORCPT lsarc-ext@sun.com); Wed, 20 Feb 2008 16:30:03 -0800 (PST)
Received: from brmea-mail-1.sun.com ([192.18.98.31])
 by nwk-avmta-2.sfbay.sun.com
 (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005))
 with ESMTP id <0JWK00DQOC23SN60@nwk-avmta-2.sfbay.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed,
 20 Feb 2008 16:30:03 -0800 (PST)
Received: from fe-amer-10.sun.com ([192.18.109.80])
	by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1L0U2nR020904	for
 ; Thu, 21 Feb 2008 00:30:02 +0000 (GMT)
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com
 (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007))
 id <0JWK00J01BNJ4E00@mail-amer.sun.com>
 (original mail from John.Fischer@Sun.COM)
 for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed,
 20 Feb 2008 17:30:02 -0700 (MST)
Received: from 129.145.154.84 ([129.145.154.84])
 by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28
 2007)) with ESMTPSA id <0JWK00LG3C1JZR50@mail-amer.sun.com> for
 lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed,
 20 Feb 2008 17:29:44 -0700 (MST)
Date: Wed, 20 Feb 2008 16:29:43 -0800
From: John Fischer 
Subject: Re: LSARC/2008/059 SQLite
In-reply-to: <47AA4A0F.1000508@sun.com>
Sender: John.Fischer@sun.com
To: Elaine Xiong 
Cc: John Fischer , Evan Yan ,
        "brian.lu" , lsarc-ext@sun.com
Reply-to: John.Fischer@sun.com
Message-id: <1203553782.63061.313.camel@sr1-umpk-34>
MIME-version: 1.0
X-Mailer: Ximian Evolution 1.4.6.301c
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-PMX-Version: 5.2.0.264296
References: <47AA4A0F.1000508@sun.com>
Status: RO
Content-Length: 368

Elaine,

This case has been superseded with PSARC 2008/120 SQLite3.x.
I am closing this case as superseded.

Thanks,

John

On Wed, 2008-02-06 at 16:00, John Fischer wrote:
> Elaine,
> 
> I have extended the timer on this case as we need to talk
> about the interface classifications.  The new timer is set
> for Friday February 15th, 2008.
> 
> Thanks,
> 
> John
>