James, Actually, if you get the patch produced well before the GA of the Update then the patch will be included in the release and automatically installed. So anyone using the Update will see or have a chance of seeing the automatic message.
John On Thu, 2008-10-02 at 08:58, James Gates wrote: > Oh, I see. We would have to modify the community code to include a call > to syslog(3), but I don't see that as too much of a problem. > > I think the biggest issue is, for S10, this can only be issued in a > patch. So we're relying on people who don't read release notes to keep > up to date with the latest patches. Therefore there's a good chance that > no one will ever see the syslog message, but since it's technically > feasible to do, we will do it. > > > John Fischer wrote: > > James, > > > > The application warning message would be from the previous > > release. So you would need to patch an application or applications > > with the message for Solaris 10. This should occur at the > > same time as the release notes are updated. The reason why > > this is desirable is because many of the those using the > > product might not even see the release notes or read a > > man page. That is why the EOF procedures document found > > at: > > > > http://sac.sfbay/cgi-bin/bp.cgi?NAME=Obsolete-EOF.bp > > > > suggests: > > > > Where technically feasible, inclusion in the release > > where the interface is declared Obsolete of a warning > > mechanism if the interface is used. > > > > It goes on to suggest a log warning could be used. > > > > So in the Patch release of Solaris where the release note > > will be updated it would be really good and if technically > > feasible to also have a mechanism for the EOF message to > > be declared automatically. When I've Obsoleted an interface > > I have done a popup dialog because I deal with GUIs. However, > > in this case a system log or to standard error would be sufficient. > > > > Thanks, > > > > John > > > > On Thu, 2008-10-02 at 07:14, James Gates wrote: > >> John Fischer wrote: > >>> James, > >>> > >>> Sounds like a well thought out plan. > >>> > >>> Does it make sense to add to the release note which > >>> version is recommended to migrate to in the future release? > >>> So perhaps the release note might say something like: > >>> > >>> PostgreSQL version 8.2 may no longer be supported > >>> in a future release of Solaris. You may want to > >>> migrate to PostgresSQL version 8.4. > >>> > >> That makes sense. We can even include in the message a reference to our > >> upgrade tool. > >>> Also is there a command that should spit out the same > >>> message? > >> We hadn't planned to do this. > >> > >> All the 8.2 binaries are found in /usr/postgres/8.2/bin. I had > >> anticipated that this would no longer exist after an upgrade, since all > >> 8.2 packages will be removed. > >> > >> There are 3 popular commands in /usr/postgres/8.2/bin that a user would > >> call to create, start or connect to a PostgreSQL database. > >> > >> I suppose when we remove the 8.2 packages from Nevada, we could add 3 > >> scripts to /usr/postgres/8.2/bin in the 8.3 packages that print the > >> above message. And when we EOF 8.3, add similar scripts to 8.4, etc. > >>> Thanks, > >>> > >>> John > >>> > >>> > >>> On Tue, 2008-09-30 at 15:15, James Gates wrote: > >>>> I'm sponsoring this on behalf of the PostgreSQL P-Team. Timeout is set > >>>> for 8th October. Attached is a copy of the proposal, which can also be > >>>> found in the case directory. > >>>> > >>>> -- > >>>> Jim Gates Sun Microsystems > >>>> Nashua, NH, USA http://sun.com/postgresql > >>>> > >>>> ______________________________________________________________________ > >>>> Template Version: @(#)onepager.txt 1.35 07/11/07 SMI > >>>> Copyright 2007 Sun Microsystems > >>>> > >>>> 1. Introduction > >>>> 1.1. Project/Component Working Name: > >>>> EOF of PostgreSQL 8.2 in Solaris > >>>> > >>>> 1.2. Name of Document Author/Supplier: > >>>> James Gates > >>>> > >>>> 1.3. Date of This Document: > >>>> 09/30/08 > >>>> > >>>> 1.3.1. Date this project was conceived: > >>>> 09/17/08 > >>>> > >>>> 1.4. Name of Major Document Customer(s)/Consumer(s): > >>>> 1.4.1. The PAC or CPT you expect to review your project: > >>>> > >>>> Database 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: > >>>> > >>>> Chris.Armes at sun.com > >>>> > >>>> 1.4.4. The name of your business unit: > >>>> > >>>> Software/RPE > >>>> > >>>> 1.5. Email Aliases: > >>>> 1.5.1. Responsible Manager: Thulasinathan.P at sun.com > >>>> 1.5.2. Responsible Engineer: James.Gates at sun.com > >>>> 1.5.3. Marketing Manager: Wei-Chen.Chiu at sun.com > >>>> 1.5.4. Interest List: sun-postgres-pteam at sun.com > >>>> > >>>> [In the following, "8.1", "8.2", "8.3" or "8.4" without qualification > >>>> refer to the corresponding PostgreSQL version.] > >>>> > >>>> 2. Project Summary > >>>> 2.1. Project Description: > >>>> > >>>> Solaris currently includes versions 8.1, 8.2 & 8.3. It is expected > >>>> that the community will release 8.4 in Dec 2008. We plan to integrate > >>>> it into Solaris shortly after community release. > >>>> > >>>> This project proposes to announce the EOF for 8.2 in a patch > >>>> release of Solaris (i.e. Solaris 10 Update) and removal of the > >>>> feature in a minor release of Solaris (i.e. Solaris 11). > >>>> > >>>> The intention of the PostgreSQL EOL policy approved by the DB PAC > >>>> is to provide active support for the latest 2 versions integrated > >>>> with Solaris. Hence the release and integration of 8.4 triggers the > >>>> EOF & EOL of 8.2. > >>>> > >>>> Note that the ARC case to EOF 8.1 was approved on 01/15/2008 > >>>> (LSARC/2008/005). > >>>> > >>>> 2.2. Risks and Assumptions: > >>>> > >>>> If Solaris 11 is shipped without 8.2 it would force customers > >>>> still running this version to upgrade PostgreSQL immediately > >>>> if they upgrade their O/S. They might even decide not to > >>>> upgrade because of this (although I think this is unlikely). > >>>> Those customers who must continue to run 8.2 can still visit the > >>>> community website and download the freely available software. > >>>> > >>>> There is also a risk that some other Sun products depend on > >>>> 8.2; we need to ensure that these are upgraded to at least 8.3. > >>>> I have verified that no other packages in the SFWNV > >>>> consilidation are listed as depending on any of the PostgreSQL > >>>> 8.2 packages. > >>>> > >>>> 3. Business Summary > >>>> > >>>> 3.1. Problem Area: > >>>> > >>>> The PostgreSQL community release a new major version approximately > >>>> once every year. For various reasons, we need to encourage customers > >>>> to upgrade to newer versions when they become available. > >>>> > >>>> 3.2. Market/Requester: > >>>> > >>>> PostgreSQL P-Team > >>>> > >>>> 3.3. Business Justification: > >>>> > >>>> We want to reduce the amount of resources needed to support and > >>>> sustain > >>>> old versions of PostgreSQL. We also want to keep in sync with the > >>>> PostgreSQL communitys EOL policy i.e. we don't want to > >>>> be in the position of having a PostgreSQL version in Solaris that is > >>>> no longer supported and maintained by the community. > >>>> > >>>> 3.4. Competitive Analysis: > >>>> > >>>> N/A > >>>> > >>>> 3.5. Opportunity Window/Exposure: > >>>> > >>>> This needs to coincide with the integration of 8.4, so as to > >>>> ensure > >>>> that only the latest 2 versions of PostgreSQL are available/supported, > >>>> and all previous versions are EOF/EOL. > >>>> > >>>> 3.6. How will you know when you are done?: > >>>> > >>>> The project will be complete when the announcement is made in > >>>> a patch release of Solaris and when 8.2 is removed from a minor > >>>> release of Solaris. > >>>> > >>>> 4. Technical Description: > >>>> 4.1. Details: > >>>> > >>>> This project will create a release note in a Patch release of > >>>> Solaris (i.e. Solaris 10 Update). It will also remove all 8.2 > >>>> packages from a Minor release of Solaris (i.e., Solaris 11). > >>>> > >>>> The Solaris 10 Update Release Notes will be updated with the > >>>> following text: > >>>> > >>>> PostgreSQL version 8.2 may no longer be supported > >>>> in a future release. > >>>> > >>>> 4.2. Bug/RFE Number(s): > >>>> > >>>> N/A > >>>> > >>>> 4.3. In Scope: > >>>> > >>>> 4.4. Out of Scope: > >>>> > >>>> 4.5. Interfaces: > >>>> > >>>> Imported Interfaces: > >>>> Interface Stability Citation > >>>> --------- --------- ---------- > >>>> N/A > >>>> > >>>> Exported Interfaces: > >>>> Interface Classification Comments > >>>> --------------------- --------------- ------------------------ > >>>> SUNWpostgr-82-client Obsolete Package > >>>> SUNWpostgr-82-contrib Obsolete Package > >>>> SUNWpostgr-82-devel Obsolete Package > >>>> SUNWpostgr-82-docs Obsolete Package > >>>> SUNWpostgr-82-jdbc Obsolete Package > >>>> SUNWpostgr-82-libs Obsolete Package > >>>> SUNWpostgr-82-pl Obsolete Package > >>>> SUNWpostgr-82-server Obsolete Package > >>>> SUNWpostgr-82-server-data-root Obsolete Package > >>>> SUNWpostgr-82-tcl Obsolete Package > >>>> /lib/svc/method/postgresql Obselete SMF method script > >>>> /usr/postgres/8.2 Obsolete Installation location > >>>> /usr/postgres/8.2/bin Obsolete Executable location > >>>> /usr/postgres/8.2/doc Obsolete Documentation > >>>> /usr/postgres/8.2/etc Obsolete Config files > >>>> /usr/postgres/8.2/include Obsolete Header files > >>>> /usr/postgres/8.2/jdbc Obsolete JDBC driver > >>>> /usr/postgres/8.2/lib Obsolete Shared libraries > >>>> /usr/postgres/8.2/man Obsolete Manual pages > >>>> /usr/postgres/8.2/share Obsolete Localized message files > >>>> /usr/share/man/man5/postgres_82.5 Obselete Sun specific > >>>> man page > >>>> /var/postgres/8.2 Obselete Default db location > >>>> /var/svc/manifest/application/database/postgresql.xml Obselete > >>>> SMF manifest file > >>>> > >>>> Also deleted are all files under /usr/postgres/8.2/* (too > >>>> numerous to > >>>> list here). > >>>> > >>>> 4.6. Doc Impact: > >>>> > >>>> Comprehensive documentation was included with the product. This will > >>>> be removed. The only other documentation impact will be the delivery > >>>> of the release note (see section 4.1). > >>>> > >>>> 4.7. Admin/Config Impact: > >>>> > >>>> None. > >>>> > >>>> 4.8. HA Impact: > >>>> > >>>> N/A > >>>> > >>>> 4.9. I18N/L10N Impact: > >>>> > >>>> N/A > >>>> > >>>> 4.10. Packaging & Delivery: > >>>> > >>>> The packages listed in 4.5 will be deleted and will not be > >>>> included with the first release of Solaris 11. However, note > >>>> that they have been delivered with SXDE; I don't know if this > >>>> will require us to go through the full EOF process. > >>>> > >>>> Users upgrading from Solaris 10 who are running a database > >>>> under PostgreSQL 8.1 or 8.2 will have to use the upgrade > >>>> solution we > >>>> included with the 8.3 integration to upgrade to 8.3 or 8.4. > >>>> > >>>> 4.11. Security Impact: > >>>> > >>>> No impact. > >>>> > >>>> 4.12. Dependencies: > >>>> > >>>> Depends on the integration of 8.4 > >>>> > >>>> 5. Reference Documents: > >>>> > >>>> All material associated with the original ARC case to integrate > >>>> PostgreSQL 8.1 can be found at: > >>>> http://sac.sfbay.sun.com/LSARC/2005/515/ > >>>> > >>>> Material associated with the ARC case to integrate PostgreSQL > >>>> 8.2 can be found at: > >>>> http://sac.sfbay.sun.com/LSARC/2006/655/ > >>>> > >>>> Material associated with the ARC case to integrate PostgreSQL > >>>> 8.3 can be found at > >>>> http://sac.sfbay.sun.com/LSARC/2008/004 > >>>> > >>>> PostgreSQL 8.3 information can be found at: > >>>> http://www.postgresql.org/ > >>>> > >>>> 6. Resources and Schedule: > >>>> 6.1. Projected Availability: > >>>> > >>>> Can be done immediately after 8.4 is integrated. > >>>> > >>>> 6.2. Cost of Effort: > >>>> > >>>> Minimal; just removal of a component. > >>>> > >>>> 6.3. Cost of Capital Resources: > >>>> > >>>> None. > >>>> > >>>> 6.4.1. Consolidation or Component Name: > >>>> > >>>> SFW > >>>> > >>>> 6.4.3. Type of CPT Review and Approval expected: > >>>> > >>>> FastTrack > >>>> > >>>> 6.4.4. Project Boundary Conditions: > >>>> > >>>> N/A > >>>> > >>>> 6.4.5. Is this a necessary project for OEM agreements: > >>>> > >>>> No > >>>> > >>>> 6.4.6. Notes: > >>>> > >>>> 6.4.7. Target RTI Date/Release: > >>>> > >>>> ASAP after the community releases 8.4. > >>>> > >>>> 6.4.8. Target Code Design Review Date: > >>>> 6.4.9. Update approval addition: > >>>> > >>>> 6.5. ARC review type: > >>>> > >>>> FastTrack > >>>> > >>>> 6.6. ARC Exposure: > >>>> > >>>> open > >>>> > >>>> 6.6.1. Rationale: > >>>> > >>>> N/A > >>>> > >>>> 7. Prototype Availability: > >>>> 7.1. Prototype Availability: > >>>> > >>>> N/A > >>>> > >>>> 7.2. Prototype Cost: > >>>> > >>>> N/A > >> -- > >> Jim Gates Sun Microsystems > >> Nashua, NH, USA http://sun.com/postgresql > > > > -- > Jim Gates Sun Microsystems > Nashua, NH, USA http://sun.com/postgresql
