From petede@sac.sfbay.sun.com Fri Apr 2 02:57:46 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o329vke1002643 for ; Fri, 2 Apr 2010 02:57:46 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o329vjp1025158; Fri, 2 Apr 2010 02:57:46 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0800D0PUC9M700@brm-avmta-1.central.sun.com>; Fri, 02 Apr 2010 03:57:45 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L08007GVUC9M240@brm-avmta-1.central.sun.com>; Fri, 02 Apr 2010 03:57:45 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o329vhPl001175; Fri, 02 Apr 2010 02:57:43 -0700 (PDT) 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 o329vgQw002638; Fri, 02 Apr 2010 02:57:42 -0700 (PDT) Received: (from petede@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o329vflt002634; Fri, 02 Apr 2010 02:57:42 -0700 (PDT) Date: Fri, 02 Apr 2010 02:57:42 -0700 (PDT) From: Peter Dennis Subject: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] To: PSARC-ext@sun.com Cc: lukas.rovensky@sun.com Message-id: <201004020957.o329vflt002634@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2763 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: SER removal 1.2. Name of Document Author/Supplier: Author: Lukas Rovensky 1.3 Date of This Document: 02 April, 2010 4. Technical Description 1. Introduction 1.1 Project/Component Working Name: SER removal 1.2 Name of Document Author/Supplier: Author: Lukas Rovensky 1.3 Date of This Document: 19 March, 2010 1.4 The requested release taxonomy: Patch binding for the announcement and marking as Obsolete. Minor binding for the removal. 1.5 Introduction This FastTrack will EOF the Sip Express Router (SER) and its web based interface -- SERWeb -- from Solaris Next and obsolete SER and SERWeb in Solaris 10. On November 4th 2008 a new SIP Router project was announced and joined by SER developers, [1]. This also means that SER itself is no longer developed in favour of the SIP Router, [2]. Since SER is no longer developed product it shall be removed from Solaris Next. Should a similar product be required then the SIP Router (Kamailio) may be a good candidate. 1.6 Previous Relevant ARC cases LSARC/2004/324 - sfw/SIP Proxy Server (actually still in waiting state), [3] 2. Documentation Obsoleting SER and SERWeb in Solaris 10 will be announced in release notes for Solaris 10. Interface Stability in SER man page (ser(8)) in Solaris 10 will be set to "Obsolete, External". 3. Packaging and Delivery SUNWserr, SUNWseru and SUNWserweb packages will be removed from OpenSolaris. This does mean that the renamed packages will no longer be delivered (service:network:sip:ser and service:network:sip:ser:administration). 4. Interfaces All the interfaces described below will be obsoleted in Solaris 10 and removed from OpenSolars / SNV. The following files and directories (including all their content) will be removed from OpenSolaris / SNV: /usr/sfw/sbin/ser /usr/sfw/sbin/serctl /usr/sfw/lib/ser/ /usr/sfw/share/doc/ser/ /etc/sfw/ser/ /usr/sfw/share/serweb/ 5. References [1] http://sip-router.org/2008/11/04/the-sip-router-project-launched/ [2] http://sip-router.org/ [3] http://sac.sfbay/LSARC/2004/324/ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: sfw 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@workingcode.com Fri Apr 2 05:12:10 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32CC9t9003977 for ; Fri, 2 Apr 2010 05:12:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o32CC7ff000092; Fri, 2 Apr 2010 07:12:08 -0500 (CDT) 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 <0L09005050K7Y000@brm-avmta-1.central.sun.com>; Fri, 02 Apr 2010 06:12:07 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L09007660K7LWD0@brm-avmta-1.central.sun.com>; Fri, 02 Apr 2010 06:12:07 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o32CC6Pt006721; Fri, 02 Apr 2010 12:12:06 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-3542947; Fri, 02 Apr 2010 12:12:06 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-104528922; Fri, 02 Apr 2010 12:12:05 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-42696611; Fri, 02 Apr 2010 12:12:05 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o32CC3Vq019446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 02 Apr 2010 08:12:04 -0400 (EDT) Date: Fri, 02 Apr 2010 08:12:03 -0400 From: James Carlson Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <201004020957.o329vflt002634@sac.sfbay.sun.com> To: Peter Dennis Cc: PSARC-ext@sun.com, lukas.rovensky@sun.com Message-id: <4BB5DF13.4060300@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=-0.2/5.0, scanned in 0.263sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201004020957.o329vflt002634@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1196 Peter Dennis wrote: > This FastTrack will EOF the Sip Express Router (SER) and its web based > interface -- SERWeb -- from Solaris Next and obsolete SER and SERWeb in > Solaris 10. > > On November 4th 2008 a new SIP Router project was announced and joined > by SER developers, [1]. This also means that SER itself is no longer > developed in favour of the SIP Router, [2]. I think this project is incomplete. Removal without replacement doesn't seem like the right response to having the upstream open source project merely shutting down. Instead, I'd expect that we'd at most mark Obsolete in S10, and then remove in the current release when the new, replacement project is ready, and (perhaps) there's some sort of transition story that can be told. We've got a huge number of open source bits in OpenSolaris that have either a long-dead upstream or no real maintainer to speak of. And there are others that were considered "dead" for years only to come back to life later. Why is this one special? Why does removal from OpenSolaris necessarily follow an announcement like that? -- James Carlson 42.703N 71.076W From lukas.rovensky@sun.com Fri Apr 2 05:31:03 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32CV3Wr004038 for ; Fri, 2 Apr 2010 05:31:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o32CV2qD008812 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Apr 2010 07:31:03 -0500 (CDT) 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 <0L090090N1FQUH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 02 Apr 2010 05:31:02 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L09002MI1FOP040@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 02 Apr 2010 05:31:02 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o32CV0is018501 for ; Fri, 02 Apr 2010 12:31:00 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0900H001C6SS00@fe-emea-13.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 02 Apr 2010 13:30:47 +0100 (BST) Received: from MyspulinPro.local (101-15-207-85.static.bluetone.cz [85.207.15.101]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0900BAO1F9K780@fe-emea-13.sun.com>; Fri, 02 Apr 2010 13:30:47 +0100 (BST) Date: Fri, 02 Apr 2010 14:30:45 +0200 From: Lukas Rovensky Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <4BB5DF13.4060300@workingcode.com> Sender: lukas.rovensky@sun.com To: James Carlson Cc: Peter Dennis , PSARC-ext@sun.com Message-id: <4BB5E375.5040204@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 Status: RO Content-Length: 2278 On 4/2/10 2:12 PM, James Carlson wrote: > Peter Dennis wrote: >> This FastTrack will EOF the Sip Express Router (SER) and its web based >> interface -- SERWeb -- from Solaris Next and obsolete SER and SERWeb in >> Solaris 10. >> >> On November 4th 2008 a new SIP Router project was announced and joined >> by SER developers, [1]. This also means that SER itself is no longer >> developed in favour of the SIP Router, [2]. > > I think this project is incomplete. > > Removal without replacement doesn't seem like the right response to > having the upstream open source project merely shutting down. Instead, > I'd expect that we'd at most mark Obsolete in S10, and then remove in > the current release when the new, replacement project is ready, and > (perhaps) there's some sort of transition story that can be told. > Well, the question is if any replacement is needed. I asked marketing about their opinion and they do not have a problem with removing SER without a replacement. There is no one in development working on SER and bringing a new SIP router to Solaris represents a significant effort (especially the required testing). So, without a real business justification why to have such a product in Solaris I would like to get it removed. I do not think there is a need to have a dead product in Solaris. Certainly, if there exist real business reasons why SER should be part of Solaris Next I would like to learn about these. > We've got a huge number of open source bits in OpenSolaris that have > either a long-dead upstream or no real maintainer to speak of. And > there are others that were considered "dead" for years only to come back > to life later. Why is this one special? > I do not think that SER is special but on the other side I do not see any reason why to keep SER (and perhaps the other number of huge of dead open source bits) in Solaris Next (especially "as part of the product"). Perhaps having such bits provided just "for Solaris", e.g., in /contrib makes more sense. > Why does removal from OpenSolaris necessarily follow an announcement > like that? > Because of the reasons above -- so far I am not aware of any reasons why to have a SIP router-like product part of Solaris Next. Lukas From andrew.gabriel@oracle.com Fri Apr 2 05:46:23 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32CkN6K004198 for ; Fri, 2 Apr 2010 05:46:23 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o32CkJjm008546; Fri, 2 Apr 2010 05:46:21 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0900909258VQ00@brm-avmta-1.central.sun.com>; Fri, 02 Apr 2010 06:46:20 -0600 (MDT) 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 <0L09008M9258LQ00@brm-avmta-1.central.sun.com>; Fri, 02 Apr 2010 06:46:20 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o32CkJlu019711; Fri, 02 Apr 2010 12:46:19 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o32AlfeF017214; Fri, 02 Apr 2010 12:46:16 +0000 (GMT) Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 141526581270212267; Fri, 02 Apr 2010 05:44:27 -0700 Received: from [192.168.2.135] (/81.187.74.206) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Apr 2010 05:44:27 -0700 Date: Fri, 02 Apr 2010 13:44:49 +0100 From: Andrew Gabriel Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <4BB5DF13.4060300@workingcode.com> To: James Carlson Cc: Peter Dennis , PSARC-ext@sun.com, lukas.rovensky@sun.com Message-id: <4BB5E6C1.1060005@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BB5E719.00C5:SCFMA4539814,ss=1,fgs=0 References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090908) Status: RO Content-Length: 1392 James Carlson wrote: > Peter Dennis wrote: > >> This FastTrack will EOF the Sip Express Router (SER) and its web based >> interface -- SERWeb -- from Solaris Next and obsolete SER and SERWeb in >> Solaris 10. >> >> On November 4th 2008 a new SIP Router project was announced and joined >> by SER developers, [1]. This also means that SER itself is no longer >> developed in favour of the SIP Router, [2]. >> > > I think this project is incomplete. > > Removal without replacement doesn't seem like the right response to > having the upstream open source project merely shutting down. Instead, > I'd expect that we'd at most mark Obsolete in S10, and then remove in > the current release when the new, replacement project is ready, and > (perhaps) there's some sort of transition story that can be told. > > We've got a huge number of open source bits in OpenSolaris that have > either a long-dead upstream or no real maintainer to speak of. And > there are others that were considered "dead" for years only to come back > to life later. Why is this one special? > > Why does removal from OpenSolaris necessarily follow an announcement > like that? > As a user of SER, I would agree with that. EOF of VoIP routing in Solaris is not an appropriate thing to do. I'd be happy if the removal is conditional on first providing a replacement. -- Andrew From Lukas.Rovensky@sun.com Fri Apr 2 06:00:56 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32D0u7V004521 for ; Fri, 2 Apr 2010 06:00:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o32D0s5A023398 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Apr 2010 08:00:56 -0500 (CDT) 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 <0L0900B2B2TJYP00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 06:00:55 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L090021V2THP060@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 06:00:54 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o32D0r5h020857 for ; Fri, 02 Apr 2010 13:00:53 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0900I002O12200@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 14:00:41 +0100 (BST) Received: from vpn-129-150-124-63.germany.sun.com ([unknown] [129.150.124.63]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0900BLO2T4K780@fe-emea-13.sun.com>; Fri, 02 Apr 2010 14:00:41 +0100 (BST) Date: Fri, 02 Apr 2010 15:00:39 +0200 From: Lukas Rovensky Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <4BB5E6C1.1060005@oracle.com> Sender: Lukas.Rovensky@sun.com To: Andrew Gabriel Cc: James Carlson , Peter Dennis , PSARC-ext@sun.com Message-id: <4BB5EA77.9070706@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> <4BB5E6C1.1060005@oracle.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 Status: RO Content-Length: 1818 On 4/2/10 2:44 PM, Andrew Gabriel wrote: > James Carlson wrote: >> Peter Dennis wrote: >>> This FastTrack will EOF the Sip Express Router (SER) and its web based >>> interface -- SERWeb -- from Solaris Next and obsolete SER and SERWeb >>> in Solaris 10. >>> >>> On November 4th 2008 a new SIP Router project was announced and joined >>> by SER developers, [1]. This also means that SER itself is no longer >>> developed in favour of the SIP Router, [2]. >> >> I think this project is incomplete. >> >> Removal without replacement doesn't seem like the right response to >> having the upstream open source project merely shutting down. Instead, >> I'd expect that we'd at most mark Obsolete in S10, and then remove in >> the current release when the new, replacement project is ready, and >> (perhaps) there's some sort of transition story that can be told. >> >> We've got a huge number of open source bits in OpenSolaris that have >> either a long-dead upstream or no real maintainer to speak of. And >> there are others that were considered "dead" for years only to come back >> to life later. Why is this one special? >> >> Why does removal from OpenSolaris necessarily follow an announcement >> like that? > > As a user of SER, I would agree with that. By "as a user of SER" -- do you mean a paying customer? > EOF of VoIP routing in Solaris is not an appropriate thing to do. Can you elaborate on why it is not appropriate? I am very interested in understanding the facts concerning how having SER in Solaris is important from architectural point of view and/or how it helps to earn money (e.g., do we have and evidence on how many paying customers use it? Marketing did not provide me with such data). Thanks, Lukas > I'd be happy if the removal is conditional on first providing a > replacement. > From carlsonj@workingcode.com Fri Apr 2 07:21:29 2010 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 o32ELSXO005637 for ; Fri, 2 Apr 2010 07:21:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o32ELRtW064125; Fri, 2 Apr 2010 08:21:27 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L09002036JR6U00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 02 Apr 2010 07:21:27 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0900LGC6JQLBA0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 02 Apr 2010 07:21:27 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o32ELQsc013519; Fri, 02 Apr 2010 14:21:26 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay43i.sun.com with ESMTP id BT-MMP-437220; Fri, 02 Apr 2010 14:21:26 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-69230321; Fri, 02 Apr 2010 14:21:25 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-12729518; Fri, 02 Apr 2010 14:21:25 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o32ELLiV003785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 02 Apr 2010 10:21:21 -0400 (EDT) Date: Fri, 02 Apr 2010 10:21:21 -0400 From: James Carlson Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <4BB5EA77.9070706@sun.com> To: Lukas Rovensky Cc: Andrew Gabriel , Peter Dennis , PSARC-ext@sun.com Message-id: <4BB5FD61.2020707@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=-0.7/5.0, scanned in 0.127sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> <4BB5E6C1.1060005@oracle.com> <4BB5EA77.9070706@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 2051 Lukas Rovensky wrote: > On 4/2/10 2:44 PM, Andrew Gabriel wrote: >> James Carlson wrote: >>> Why does removal from OpenSolaris necessarily follow an announcement >>> like that? >> >> As a user of SER, I would agree with that. > > By "as a user of SER" -- do you mean a paying customer? > >> EOF of VoIP routing in Solaris is not an appropriate thing to do. > > Can you elaborate on why it is not appropriate? I am very interested in > understanding the facts concerning how having SER in Solaris is > important from architectural point of view and/or how it helps to earn > money (e.g., do we have and evidence on how many paying customers use > it? Marketing did not provide me with such data). All interesting stuff, to be sure, but I believe it's off-topic in this discussion. This is about architectural review, not business issues. The software is currently included as part of the system, and it has known users. The question of whether they pay is not architectural in nature. The question is why this needs to be removed. Why not just leave it there? As long as we're talking about money, why should Sun spend the money necessary to do the work of removing this? Isn't it far simpler and cheaper to leave it alone? Normally, an architectural case for removal will supply some sort of clear justification for the change. The justification is usually one of: - feature has been supplanted; new one is available. - feature has serious unfixable security flaws and presents a high risk. - feature is dependent on EOSL'd hardware or EOF'd software. - feature has low value and is known not to have any users. This one seems to be quite different. It's EOF because the upstream isn't as active as the project team has decided they should be. But how does that stop the bits from working for the existing users? ARC members: is this precedent the ARC should set? I'd expect that new precedent doesn't (normally) come from a fast-track. -- James Carlson 42.703N 71.076W From Lukas.Rovensky@sun.com Fri Apr 2 08:08:15 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32F8FDl006402 for ; Fri, 2 Apr 2010 08:08:15 -0700 (PDT) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o32F8E6O016793 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Apr 2010 08:08:15 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L090020D8PR5500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 09:08:15 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L09008ZF8PQLY70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 09:08:14 -0600 (MDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o32F8DIo000407 for ; Fri, 02 Apr 2010 15:08:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0900J008GU3Q00@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 16:07:54 +0100 (BST) Received: from vpn-129-150-124-63.germany.sun.com ([unknown] [129.150.124.63]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0900BUG8P4K790@fe-emea-13.sun.com>; Fri, 02 Apr 2010 16:07:54 +0100 (BST) Date: Fri, 02 Apr 2010 17:07:49 +0200 From: Lukas Rovensky Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <4BB5FD61.2020707@workingcode.com> Sender: Lukas.Rovensky@sun.com To: James Carlson Cc: Andrew Gabriel , Peter Dennis , PSARC-ext@sun.com Message-id: <4BB60845.6010201@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> <4BB5E6C1.1060005@oracle.com> <4BB5EA77.9070706@sun.com> <4BB5FD61.2020707@workingcode.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 Status: RO Content-Length: 3178 On 4/2/10 4:21 PM, James Carlson wrote: > Lukas Rovensky wrote: >> On 4/2/10 2:44 PM, Andrew Gabriel wrote: >>> James Carlson wrote: >>>> Why does removal from OpenSolaris necessarily follow an announcement >>>> like that? >>> >>> As a user of SER, I would agree with that. >> >> By "as a user of SER" -- do you mean a paying customer? >> >>> EOF of VoIP routing in Solaris is not an appropriate thing to do. >> >> Can you elaborate on why it is not appropriate? I am very interested in >> understanding the facts concerning how having SER in Solaris is >> important from architectural point of view and/or how it helps to earn >> money (e.g., do we have and evidence on how many paying customers use >> it? Marketing did not provide me with such data). > > All interesting stuff, to be sure, but I believe it's off-topic in this > discussion. This is about architectural review, not business issues. > Well, to me there is always mixture of business and architectural views in cases like this. Keeping something in Solaris cost money becasue the something has to be supported an it is not for free. Besides, bringing SER to Solaris was based on business reasons and not on architectural needs (LSARC 2004/324). > The software is currently included as part of the system, and it has > known users. The question of whether they pay is not architectural in > nature. > > The question is why this needs to be removed. Why not just leave it > there? As long as we're talking about money, why should Sun spend the > money necessary to do the work of removing this? Isn't it far simpler > and cheaper to leave it alone? > Why to remove it -- as per the architectural rules EOF like this are possible typically between minor versions (Solaris 10 -> Solaris Next). If we leave it in Solaris Next then SER will be there for another 10+ years and by this time it will be really old / dead / rotten. Leaving a supported FOSS product like SER in Solaris is not for free. For example, if there is a vulnerability issue in it then "someone" will have to fix it. For dead products it means that Oracle will be the "someone". So, no -- from long term point of view it is cheaper to remove dead stuff from Solaris. > Normally, an architectural case for removal will supply some sort of > clear justification for the change. The justification is usually one of: > > - feature has been supplanted; new one is available. > > - feature has serious unfixable security flaws and presents a high > risk. > > - feature is dependent on EOSL'd hardware or EOF'd software. > > - feature has low value and is known not to have any users. > > This one seems to be quite different. It's EOF because the upstream > isn't as active as the project team has decided they should be. But how > does that stop the bits from working for the existing users? > I am not proposing to remove it from S10 but from Solaris Next. So, existing users of S10 can still have it. Would it sound OK to you if SER is moved to /contrib? Lukas > ARC members: is this precedent the ARC should set? I'd expect that new > precedent doesn't (normally) come from a fast-track. > From carlsonj@workingcode.com Fri Apr 2 08:30:55 2010 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 o32FUtmY006758 for ; Fri, 2 Apr 2010 08:30:55 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o32FUYNu044955; Fri, 2 Apr 2010 09:30:54 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0900L039QQRM00@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Apr 2010 08:30:26 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L090027J9QQP8D0@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Apr 2010 08:30:26 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o32FPfiq026565; Fri, 02 Apr 2010 15:30:26 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay11i.sun.com with ESMTP id BT-MMP-2670752; Fri, 02 Apr 2010 15:30:26 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-104867780; Fri, 02 Apr 2010 15:30:25 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-29711860; Fri, 02 Apr 2010 15:30:25 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o32FUHlI011452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 02 Apr 2010 11:30:21 -0400 (EDT) Date: Fri, 02 Apr 2010 11:30:17 -0400 From: James Carlson Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <4BB60845.6010201@sun.com> To: Lukas Rovensky Cc: Andrew Gabriel , Peter Dennis , PSARC-ext@sun.com Message-id: <4BB60D89.2020204@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-dmv.com-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.054sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> <4BB5E6C1.1060005@oracle.com> <4BB5EA77.9070706@sun.com> <4BB5FD61.2020707@workingcode.com> <4BB60845.6010201@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1009 Lukas Rovensky wrote: > I am not proposing to remove it from S10 but from Solaris Next. So, > existing users of S10 can still have it. Would it sound OK to you if > SER is moved to /contrib? I think that's essentially going from "bundled" to "unbundled," which normally requires an actual EOF. It makes some sense to me, and is certainly much better than outright removal without a replacement, but I think we'd better get some ARC members to chime in on whether this is setting precedent for how previously supported software becomes unsupported and whether giving this project effectively a waiver is ok. I'm not too impressed, though, with the business arguments. Frankly, the folks who were dumping open source projects into the system years ago were told -- repeatedly -- that there was always cost involved, and ARC members were assured that this was known. Seeing a regression like this anyway is really unfortunate. -- James Carlson 42.703N 71.076W From garrett.damore@oracle.com Fri Apr 2 08:48:15 2010 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 o32FmFTQ006970 for ; Fri, 2 Apr 2010 08:48:15 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o32Fm8HU058008; Fri, 2 Apr 2010 09:48:13 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L090031RAKDFZ00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 02 Apr 2010 08:48:13 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0900LT5AKCMDE0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 02 Apr 2010 08:48:12 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o32FmC3H002578; Fri, 02 Apr 2010 15:48:12 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o32Fm9hV018681; Fri, 02 Apr 2010 15:48:10 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt353.oracle.com with ESMTP id 133410061270223181; Fri, 02 Apr 2010 08:46:21 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Apr 2010 08:46:20 -0700 Date: Fri, 02 Apr 2010 08:46:19 -0700 From: "Garrett D'Amore" Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <4BB5EA77.9070706@sun.com> To: Lukas Rovensky Cc: Andrew Gabriel , James Carlson , Peter Dennis , PSARC-ext@sun.com Message-id: <4BB6114B.8040108@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BB611BA.00BD:SCFMA4539814,ss=1,fgs=0 References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> <4BB5E6C1.1060005@oracle.com> <4BB5EA77.9070706@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 2812 Based on what I see, we're talking about EOF'ing a useful and still used feature of Solaris, with no replacement. While there may be reasons that we are not in a position to fund integration of a replacement, I think this decision is impact-ful enough to go beyond a fast track. As it stands now, the question we have to answer Architecturally is, "do we need a SIP router for Solaris?" I'm going to derail this case, because such a decision at least requires some basic discussion and a vote. I don't new materials are required, but if the project team has materials that they can submit which demonstrate that there is not a need for this functionality, that might helpful. If there are business reasons for the EOF which cannot be shared publicly (and I'm not saying that there are -- I don't know!), then this case can be converted into a closed one. - Garrett On 04/ 2/10 06:00 AM, Lukas Rovensky wrote: > On 4/2/10 2:44 PM, Andrew Gabriel wrote: >> James Carlson wrote: >>> Peter Dennis wrote: >>>> This FastTrack will EOF the Sip Express Router (SER) and its web based >>>> interface -- SERWeb -- from Solaris Next and obsolete SER and SERWeb >>>> in Solaris 10. >>>> >>>> On November 4th 2008 a new SIP Router project was announced and joined >>>> by SER developers, [1]. This also means that SER itself is no longer >>>> developed in favour of the SIP Router, [2]. >>> >>> I think this project is incomplete. >>> >>> Removal without replacement doesn't seem like the right response to >>> having the upstream open source project merely shutting down. Instead, >>> I'd expect that we'd at most mark Obsolete in S10, and then remove in >>> the current release when the new, replacement project is ready, and >>> (perhaps) there's some sort of transition story that can be told. >>> >>> We've got a huge number of open source bits in OpenSolaris that have >>> either a long-dead upstream or no real maintainer to speak of. And >>> there are others that were considered "dead" for years only to come >>> back >>> to life later. Why is this one special? >>> >>> Why does removal from OpenSolaris necessarily follow an announcement >>> like that? >> >> As a user of SER, I would agree with that. > > By "as a user of SER" -- do you mean a paying customer? > >> EOF of VoIP routing in Solaris is not an appropriate thing to do. > > Can you elaborate on why it is not appropriate? I am very interested > in understanding the facts concerning how having SER in Solaris is > important from architectural point of view and/or how it helps to earn > money (e.g., do we have and evidence on how many paying customers use > it? Marketing did not provide me with such data). > > Thanks, > Lukas > >> I'd be happy if the removal is conditional on first providing a >> replacement. >> > > From storycrafter@gmail.com Fri Apr 2 09:52:35 2010 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 o32GqY1k008593 for ; Fri, 2 Apr 2010 09:52:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o32GqWhh037957; Fri, 2 Apr 2010 10:52:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L090040RDJLGE00@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Apr 2010 09:52:33 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L09000OGDJKXR30@nwk-avmta-2.sfbay.sun.com>; Fri, 02 Apr 2010 09:52:32 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o32GqV8P029003; Fri, 02 Apr 2010 16:52:31 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-1105342; Fri, 02 Apr 2010 16:52:27 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-105011621; Fri, 02 Apr 2010 16:52:27 +0000 (Z) Received: from mail-pw0-f49.google.com ([209.85.160.49] [209.85.160.49]) by relay1i.sun.com with ESMTP id BT-MMP-28268906; Fri, 02 Apr 2010 16:52:26 +0000 (Z) Received: by pwj3 with SMTP id 3so838614pwj.8 for ; Fri, 02 Apr 2010 09:52:25 -0700 (PDT) Received: by 10.141.29.3 with HTTP; Fri, 02 Apr 2010 09:52:25 -0700 (PDT) Received: by 10.141.53.9 with SMTP id f9mr1695644rvk.168.1270227145746; Fri, 02 Apr 2010 09:52:25 -0700 (PDT) Date: Fri, 02 Apr 2010 10:52:25 -0600 From: Mark Martin Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <4BB6114B.8040108@oracle.com> To: "Garrett D'Amore" Cc: Lukas Rovensky , PSARC-ext@sun.com, Peter Dennis , Andrew Gabriel Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qqcH+gAvUfMERL4LJhbog/Q3BzeH1Uey49pyWhsKOHY=; b=upAEtquiIZs1bNJpyr8KabsLd1QIlLW5SnH/9h5xC6LkY+oTld9TOwGZGB6I9y1m1D nZult4Kv1hIeThRf1xviGvVMtE8nb1pRCbhVHok+BQa2bD4c0qoRwIrCCePYoT//VE7y iIZoY6ElvrrBZehfVK57yr+jKjU5QTQezhvTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Vlc51jmS7F1v38Zv6WuuTqh2Dsh9TR9xEfWSNJcn9rcwp/M/5xqt9aIVY4gng0jDRX 7bBNEAJ49lGY30N2lSc742bfPlQBL5aibjqlBKnl/V2Giph+6RCPdtrRky8pm3GdmRBS 11Z/pFZa3+lNso/lnkeTuJUSZ94+7sa1eqkk0= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.097sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> <4BB5E6C1.1060005@oracle.com> <4BB5EA77.9070706@sun.com> <4BB6114B.8040108@oracle.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id o32GqY1k008593 Status: RO Content-Length: 3858 On Fri, Apr 2, 2010 at 9:46 AM, Garrett D'Amore wrote: > Based on what I see, we're talking about EOF'ing a useful and still used > feature of Solaris, with no replacement. > > While there may be reasons that we are not in a position to fund integration > of a replacement, I think this decision is impact-ful enough to go beyond a > fast track.  As it stands now, the question we have to answer > Architecturally is, "do we need a SIP router for Solaris?" > > I'm going to derail this case, because such a decision at least requires > some basic discussion and a vote.  I don't new materials are required, but > if the project team has materials that they can submit which demonstrate > that there is not a need for this functionality, that might helpful. > > If there are business reasons for the EOF which cannot be shared publicly > (and I'm not saying that there are -- I don't know!), then this case can be > converted into a closed one. Firstly, I agree that this case seems to warrant more consideration than a fast track allows for the reasons that Jim Carlson and you mention. Secondly, and at the risk of veering slightly off-case-topic, I feel compelled to caution the committee and its members that we might be in danger of setting a precedent here for creating more closed exposure than would seem necessary. While I understand that Oracle's proprietary business information needs to be protected, and that disclosure of such information in cases is sometimes necessary, I wonder if the ARC and/or project teams couldn't do just the littlest bit of extra work here to continue to operate in the open fashion that it has in the last 5 years. Taking an open case back to a closed exposure status simply to report business justifications for a case seems a bit contrary for an ostensibly architectural (and therefor primarily technical) review. Just prior to this, an unrelated case (2010/067) was also created as a closed exposure case simply because the business justifications were included in the materials[1]. If there is a necessity for supplemental materials that are closed exposure, can we please consider an alternative way to allow review of those materials without impacting the current open status of this case? As I suggested to the project owners of that prior case, why not submit a separate case with the closed materials and its own closed discussion, and update both cases with references to each other -- similar to how umbrella cases are handled? That way, the closed exposure portions are deliberated and reviewed in the appropriate forum and with the appropriate limited disclosure, and the community at large can still participate in the parts that make sense for that larger audience and review. Umbrellas cases and all other cases I've seen are rife with references to related cases -- this doesn't seem like such a stretch from that long standing structure and process. It seems somehow short-sighted to allow, after 5 years of increasingly transparent operation, just the tiniest bit of proprietary information to allow otherwise open cases to complete totally in private, especially after spending so much money in these last many years investing in "opening" things up everywhere else in OpenSolaris Land. I'm more than happy to assist in any regard, and to the extent that it possible for me as an external contributor, to help with the extra administrative burden that might cause. I'll happily draw up template text that sponsors might include in the case(s) as I suggested above. [1] This is the alleged justification for the closed status. Regrettably, although that project team allegedly intends to eventually redact the materials so that some portion of the contents become open exposure, they have affirmed that they will not be doing it before the case is closed. From Peter.Dennis@sun.com Fri Apr 2 10:30:05 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32HU5pF009503 for ; Fri, 2 Apr 2010 10:30:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o32HU44I025161 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Apr 2010 12:30:04 -0500 (CDT) 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 <0L0900H03F90U600@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 11:29:24 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0900H8WF8Z9F00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 11:29:23 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o32HTMtw010056 for ; Fri, 02 Apr 2010 17:29:22 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0900K00F2IT800@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 18:29:16 +0100 (BST) Received: from [192.168.1.100] ([unknown] [81.157.201.41]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0900BT8F8R93C0@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 18:29:16 +0100 (BST) Date: Fri, 02 Apr 2010 18:29:15 +0100 From: petede Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: Sender: Peter.Dennis@sun.com To: PSARC-ext@sun.com Cc: Lukas Rovensky Reply-to: Peter.Dennis@sun.com Message-id: <4BB6296B.8040600@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> <4BB5E6C1.1060005@oracle.com> <4BB5EA77.9070706@sun.com> <4BB6114B.8040108@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 127 I've changed the status of this case to 'waiting needs meeting'. I'll work with the project team to find a time. Thanks pete From sacadmin Fri Apr 2 11:04:16 2010 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 o32I4G0k010605 for ; Fri, 2 Apr 2010 11:04:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o32I4G6W021409 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Fri, 2 Apr 2010 12:04:16 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0900L0RGV3V800@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 02 Apr 2010 12:04:15 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0900HZ5GV39510@brm-avmta-1.central.sun.com> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 02 Apr 2010 12:04:15 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o32I4EsW014669 for ; Fri, 02 Apr 2010 18:04:15 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o32I4DHt023606 for ; Fri, 02 Apr 2010 18:04:13 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 142318381270231372; Fri, 02 Apr 2010 11:02:52 -0700 Received: from [129.146.108.166] (/129.146.108.166) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Apr 2010 11:02:52 -0700 Date: Fri, 02 Apr 2010 11:05:57 -0700 From: Gary Winiger Subject: Fwd: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] To: psarc@sun.com Message-id: <4BB63205.6000600@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BB6319E.0077:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.1.8) Gecko/20100302 Thunderbird/3.0.2 Status: RO Content-Length: 1354 -------- Original Message -------- Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] Date: Fri, 02 Apr 2010 10:44:14 -0700 From: Gary Winiger To: Mark Martin CC: Garrett D'Amore , Lukas Rovensky , psarc@sac.eng, Peter Dennis , Andrew Gabriel Taking psarc-ext off of Mark's reply: On 04/02/10 09:52, Mark Martin wrote: > On Fri, Apr 2, 2010 at 9:46 AM, Garrett D'Amore > Firstly, I agree that this case seems to warrant more consideration > than a fast track allows for the reasons that Jim Carlson and you > mention. > > Secondly, and at the risk of veering slightly off-case-topic, I feel > compelled to caution the committee and its members that we might be in > danger of setting a precedent here for creating more closed exposure > than would seem necessary. Everything I've heard from my management chain is that anything that announces a future plan needs to be in a closed case. I take that to mean development of projects not yet openly announced as well as removal of interfaces. I'm happy to be misinformed. I hope that there will be some crystal clear guidance from upper mgmt coming real soon now, but, I'm not going to hold my breath. Gary.. From Lukas.Rovensky@sun.com Fri Apr 2 11:20:11 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o32IKA9s010913 for ; Fri, 2 Apr 2010 11:20:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o32IKAOe019501 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Apr 2010 11:20:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L090010LHLM5Y00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 11:20:10 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L09008D0HLKJ0A0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 11:20:09 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o32IK8CJ012114 for ; Fri, 02 Apr 2010 18:20:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0900K00HE6ZL00@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 19:20:00 +0100 (BST) Received: from MacMini-Lukas.local ([unknown] [85.207.15.101]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0900KS1HLBK680@fe-emea-13.sun.com>; Fri, 02 Apr 2010 19:20:00 +0100 (BST) Date: Fri, 02 Apr 2010 20:19:59 +0200 From: Lukas Rovensky Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <4BB6114B.8040108@oracle.com> Sender: Lukas.Rovensky@sun.com To: "Garrett D'Amore" Cc: Andrew Gabriel , James Carlson , Peter Dennis , PSARC-ext@sun.com Message-id: <4BB6354F.3030203@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> <4BB5E6C1.1060005@oracle.com> <4BB5EA77.9070706@sun.com> <4BB6114B.8040108@oracle.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 Status: RO Content-Length: 3058 On 4/2/10 5:46 PM, Garrett D'Amore wrote: > Based on what I see, we're talking about EOF'ing a useful and still used > feature of Solaris, with no replacement. > > While there may be reasons that we are not in a position to fund > integration of a replacement, I think this decision is impact-ful enough > to go beyond a fast track. As it stands now, the question we have to > answer Architecturally is, "do we need a SIP router for Solaris?" > Great -- this is definitely the right question to be asked. > I'm going to derail this case, because such a decision at least requires > some basic discussion and a vote. I don't new materials are required, > but if the project team has materials that they can submit which > demonstrate that there is not a need for this functionality, that might > helpful. > If I find more info I will provide it. > If there are business reasons for the EOF which cannot be shared > publicly (and I'm not saying that there are -- I don't know!), then this > case can be converted into a closed one. > This is perhaps something TBD. LUkas > - Garrett > > > On 04/ 2/10 06:00 AM, Lukas Rovensky wrote: >> On 4/2/10 2:44 PM, Andrew Gabriel wrote: >>> James Carlson wrote: >>>> Peter Dennis wrote: >>>>> This FastTrack will EOF the Sip Express Router (SER) and its web based >>>>> interface -- SERWeb -- from Solaris Next and obsolete SER and SERWeb >>>>> in Solaris 10. >>>>> >>>>> On November 4th 2008 a new SIP Router project was announced and joined >>>>> by SER developers, [1]. This also means that SER itself is no longer >>>>> developed in favour of the SIP Router, [2]. >>>> >>>> I think this project is incomplete. >>>> >>>> Removal without replacement doesn't seem like the right response to >>>> having the upstream open source project merely shutting down. Instead, >>>> I'd expect that we'd at most mark Obsolete in S10, and then remove in >>>> the current release when the new, replacement project is ready, and >>>> (perhaps) there's some sort of transition story that can be told. >>>> >>>> We've got a huge number of open source bits in OpenSolaris that have >>>> either a long-dead upstream or no real maintainer to speak of. And >>>> there are others that were considered "dead" for years only to come >>>> back >>>> to life later. Why is this one special? >>>> >>>> Why does removal from OpenSolaris necessarily follow an announcement >>>> like that? >>> >>> As a user of SER, I would agree with that. >> >> By "as a user of SER" -- do you mean a paying customer? >> >>> EOF of VoIP routing in Solaris is not an appropriate thing to do. >> >> Can you elaborate on why it is not appropriate? I am very interested >> in understanding the facts concerning how having SER in Solaris is >> important from architectural point of view and/or how it helps to earn >> money (e.g., do we have and evidence on how many paying customers use >> it? Marketing did not provide me with such data). >> >> Thanks, >> Lukas >> >>> I'd be happy if the removal is conditional on first providing a >>> replacement. >>> >> >> > From Steve.McKinty@sun.com Fri Apr 2 12:34:16 2010 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 o32JYGDh012089 for ; Fri, 2 Apr 2010 12:34:16 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o32JYE4M011763 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 2 Apr 2010 13:34:15 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0900M0PL134400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 12:34:15 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L090081CL12IWE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 12:34:15 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o32JYDAh014684 for ; Fri, 02 Apr 2010 19:34:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L0900L00KMJK600@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 02 Apr 2010 20:33:54 +0100 (BST) Received: from [10.0.0.10] ([unknown] [80.15.167.126]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L0900LX0L0DFY20@fe-emea-13.sun.com>; Fri, 02 Apr 2010 20:33:54 +0100 (BST) Date: Fri, 02 Apr 2010 21:33:49 +0200 From: Steve McKinty - Sun Microsystems Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <4BB60845.6010201@sun.com> Sender: Steve.McKinty@sun.com To: Lukas Rovensky Cc: James Carlson , Andrew Gabriel , Peter Dennis , PSARC-ext@sun.com Message-id: <4BB6469D.4080401@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> <4BB5E6C1.1060005@oracle.com> <4BB5EA77.9070706@sun.com> <4BB5FD61.2020707@workingcode.com> <4BB60845.6010201@sun.com> User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) Status: RO Content-Length: 4474 I'd just like to throw in a comment "from the gallery" here. Solaris (and if I'm honest, Linux) is a great example of where the whole is greater than the sum of the parts. If we removed every binary that we couldn't identify a paying customer for, there wouldn't be a lot left (do we need all those window managers? Isn't one shell enough? Do we need both 'cat' and 'more'?). The strength of Solaris is that people use it for one thing, but discover that it has other features, and that can lead on to other development. Granted, if something is obsolete and has been replaced by something newer we should track that, but removing something just because we can't say who uses it and it seems to save a few pennies for one team is, in my view, an error. In my 18-odd years at Sun I've seen all too many projects EOLed because the owning team didn't see sufficient gain, and the result has been financial impact to other projects where the feature has been a small but useful component. We need to look at this sort of thing from a whole-company perspective, not just for each BU's individual bottom line. That is, surely, the remit of PSARC/LSARC. Happy Easter :) Steve Lukas Rovensky wrote: > On 4/2/10 4:21 PM, James Carlson wrote: >> Lukas Rovensky wrote: >>> On 4/2/10 2:44 PM, Andrew Gabriel wrote: >>>> James Carlson wrote: >>>>> Why does removal from OpenSolaris necessarily follow an announcement >>>>> like that? >>>> >>>> As a user of SER, I would agree with that. >>> >>> By "as a user of SER" -- do you mean a paying customer? >>> >>>> EOF of VoIP routing in Solaris is not an appropriate thing to do. >>> >>> Can you elaborate on why it is not appropriate? I am very interested in >>> understanding the facts concerning how having SER in Solaris is >>> important from architectural point of view and/or how it helps to earn >>> money (e.g., do we have and evidence on how many paying customers use >>> it? Marketing did not provide me with such data). >> >> All interesting stuff, to be sure, but I believe it's off-topic in this >> discussion. This is about architectural review, not business issues. >> > Well, to me there is always mixture of business and architectural views > in cases like this. Keeping something in Solaris cost money becasue the > something has to be supported an it is not for free. Besides, bringing > SER to Solaris was based on business reasons and not on architectural > needs (LSARC 2004/324). > >> The software is currently included as part of the system, and it has >> known users. The question of whether they pay is not architectural in >> nature. >> >> The question is why this needs to be removed. Why not just leave it >> there? As long as we're talking about money, why should Sun spend the >> money necessary to do the work of removing this? Isn't it far simpler >> and cheaper to leave it alone? >> > Why to remove it -- as per the architectural rules EOF like this are > possible typically between minor versions (Solaris 10 -> Solaris Next). > If we leave it in Solaris Next then SER will be there for another 10+ > years and by this time it will be really old / dead / rotten. Leaving > a supported FOSS product like SER in Solaris is not for free. For > example, if there is a vulnerability issue in it then "someone" will > have to fix it. For dead products it means that Oracle will be the > "someone". So, no -- from long term point of view it is cheaper to > remove dead stuff from Solaris. > >> Normally, an architectural case for removal will supply some sort of >> clear justification for the change. The justification is usually one of: >> >> - feature has been supplanted; new one is available. >> >> - feature has serious unfixable security flaws and presents a high >> risk. >> >> - feature is dependent on EOSL'd hardware or EOF'd software. >> >> - feature has low value and is known not to have any users. >> >> This one seems to be quite different. It's EOF because the upstream >> isn't as active as the project team has decided they should be. But how >> does that stop the bits from working for the existing users? >> > I am not proposing to remove it from S10 but from Solaris Next. So, > existing users of S10 can still have it. Would it sound OK to you if > SER is moved to /contrib? > > Lukas > >> ARC members: is this precedent the ARC should set? I'd expect that new >> precedent doesn't (normally) come from a fast-track. >> > From joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Tue Apr 6 05:39:48 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o36Cdlij027489 for ; Tue, 6 Apr 2010 05:39:48 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o36Cdkbn011718 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 6 Apr 2010 07:39:47 -0500 (CDT) 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 <0L0G0000BGIBRG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 06 Apr 2010 05:39:47 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0G000C2GIAI000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 06 Apr 2010 05:39:46 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o36CdXha007022 for ; Tue, 06 Apr 2010 12:39:46 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay11i.sun.com with ESMTP id BT-MMP-2835269 for PSARC-ext@sun.com; Tue, 06 Apr 2010 12:39:45 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-115368459 for PSARC-ext@sun.com; Tue, 06 Apr 2010 12:39:45 +0000 (Z) Received: from relay03-haj2.antispameurope.com ([83.246.65.53] [83.246.65.53]) by relay1i.sun.com with ESMTP id BT-MMP-6410158 for PSARC-ext@sun.com; Tue, 06 Apr 2010 12:39:45 +0000 (Z) Received: by relay03-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 006EC7D4042; Tue, 06 Apr 2010 14:39:43 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay03-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 513917D401C; Tue, 06 Apr 2010 14:39:42 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id o36CdfEC007884; Tue, 06 Apr 2010 14:39:41 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 06 Apr 2010 14:39:41 +0200 Date: Tue, 06 Apr 2010 14:39:41 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: SER removal [PSARC/2010/110 FastTrack timeout 04/09/2010] In-reply-to: <4BB5DF13.4060300@workingcode.com> Sender: joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: petede@sac.sfbay.sun.com, carlsonj@workingcode.com Cc: PSARC-ext@sun.com, lukas.rovensky@sun.com Message-id: <4bbb2b8d.XCvreKRP03bjotO/%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.494sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201004020957.o329vflt002634@sac.sfbay.sun.com> <4BB5DF13.4060300@workingcode.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 06 Apr 2010 12:39:41.0335 (UTC) FILETIME=[3A440270:01CAD586] Status: RO Content-Length: 955 James Carlson wrote: > Peter Dennis wrote: > > This FastTrack will EOF the Sip Express Router (SER) and its web based > > interface -- SERWeb -- from Solaris Next and obsolete SER and SERWeb in > > Solaris 10. > > > > On November 4th 2008 a new SIP Router project was announced and joined > > by SER developers, [1]. This also means that SER itself is no longer > > developed in favour of the SIP Router, [2]. > > I think this project is incomplete. > > Removal without replacement doesn't seem like the right response to > having the upstream open source project merely shutting down. Instead, +1 Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From peter.dennis@oracle.com Wed Apr 21 02:16:33 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3L9GXZ3000033 for ; Wed, 21 Apr 2010 02:16:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3L9GVx7009725 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Apr 2010 04:16:32 -0500 (CDT) 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 <0L1700C0XZ3KLF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Apr 2010 02:16:32 -0700 (PDT) Received: from gmp-eb-inf-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 <0L17004OKZ3JCC80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Apr 2010 02:16:32 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3L9GUn8000428 for ; Wed, 21 Apr 2010 09:16:30 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L1700700YAXVP00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Apr 2010 10:16:09 +0100 (BST) Received: from [129.156.198.33] ([unknown] [129.156.198.33]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L17009BRZ2XFY60@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 21 Apr 2010 10:16:09 +0100 (BST) Date: Wed, 21 Apr 2010 10:16:09 +0100 From: Peter Dennis Subject: SER removal [PSARC/2010/110] Sender: Peter.Dennis@sun.com To: PSARC-ext , Lukas Rovensky Message-id: <4BCEC259.9060703@oracle.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 4892 Updated proposal has been put into the case and is included below. This case has been scheduled for the PSARC meeting of 28-April-2010. Thanks pete 1. Introduction 1.1 Project/Component Working Name: SER removal 1.2 Name of Document Author/Supplier: Author: Lukas Rovensky 1.3 Date of This Document: 19 March, 2010 1.4 The requested release taxonomy: Patch binding for the announcement and marking as Obsolete. Minor binding for the removal. 1.5 Introduction This FastTrack will EOF the Sip Express Router (SER) and its web based interface -- SERWeb -- from Solaris Next and obsolete SER and SERWeb in Solaris 10. On November 4th 2008 a new SIP Router project was announced and joined by SER developers, [1]. This also means that SER itself is no longer developed in favour of the SIP Router, [2]. Since SER is no longer developed product it shall be removed from Solaris Next. Should a similar product be required then the SIP Router (Kamailio) may be a good candidate. Note, that attributes(5) documents an exceptio, which can apply to this case: 4. An interface specification which isn't controlled by Sun has been changed incompatibly and the vast majority of interface consumers expect the newer interface. 1.6 Previous Relevant ARC cases LSARC/2004/324 - sfw/SIP Proxy Server (actually still in waiting state), [3] 1.7 SIP Status In Solaris, RFC 3261 SER itself provides functionality, which implements SIP protocol, RFC 3261, [8]. There are currently also two libraries in Solaris, which implement the SIP protocol (RFC 3261, [8]) and can be eventually used for implementation of SIP routing: * libsip (also in S10, since U4), PSARC 2006/402, [4], CR 6461142, [5] This library is developed by Oracle and it is available both in Solaris 10 and OpenSolaris / Solaris Next. As per the responsible engineer, there is at least one customer, who had built its application using libsip. * libosip2, LSARC 2009/277, [6], CR 6826484, [7] This is an open sourse library, [9]. There are no further plans with this library as per the responsible engineer. 1.8 Input From Marketing, Usage of SER Marketing was informed about the intention to remove SER from Solaris Next. They do not seem to have any real data, which would support or deny this action. Their current position is as the following: "Right now, I agree with the general position that SER seems like an unsupported offering and we should drop it, however we do need to assess if we should and who should pick up SIP router." The I-team also tried to approach OS Ambassadors (sig.oe@sun.com) to get more info about SER usage but no one provided any data. The I-team also looked at IPS download statistics maintained by Stephen Hahn and by end of February 2010 SER reached 24813 downloads as part of OpenSolaris. 2. Documentation Obsoleting SER and SERWeb in Solaris 10 will be announced in release notes for Solaris 10. Interface Stability in SER man page (ser(8)) in Solaris 10 will be set to "Obsolete, External". 3. Packaging and Delivery SUNWserr, SUNWseru and SUNWserweb packages will be removed from OpenSolaris. This does mean that the renamed packages will no longer be delivered (service:network:sip:ser and service:network:sip:ser:administration). 4. Interfaces All the interfaces described below will be obsoleted in Solaris 10 and removed from OpenSolars / SNV. The following files and directories (including all their content) will be removed from OpenSolaris / SNV: /usr/sfw/sbin/ser /usr/sfw/sbin/serctl /usr/sfw/lib/ser/ /usr/sfw/share/doc/ser/ /etc/sfw/ser/ /usr/sfw/share/serweb/ 5. References [1] http://sip-router.org/2008/11/04/the-sip-router-project-launched/ [2] http://sip-router.org/ [3] http://sac.sfbay/LSARC/2004/324/ [4] http://sac.sfbay/PSARC/2006/402/ http://arc.opensolaris.org/caselog/PSARC/2006/402/ [5] http://monaco.sfbay/detail.jsf?cr=6461142-2145051 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6461142 [6] http://sac.sfbay/LSARC/2009/277/ http://arc.opensolaris.org/caselog/LSARC/2009/277/ [7] http://monaco.sfbay/detail.jsf?cr=6826484 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6826484 [8] http://www.ietf.org/rfc/rfc3261.txt [9] http://www.gnu.org/software/osip/ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: sfw 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From michael.kearney@oracle.com Wed Apr 28 08:08:59 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3SF8xuL016092 for ; Wed, 28 Apr 2010 08:08:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3SF8vWr029032; Wed, 28 Apr 2010 10:08:58 -0500 (CDT) 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 <0L1L0015RE2XTQ00@brm-avmta-1.central.sun.com>; Wed, 28 Apr 2010 09:08:57 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1L00M5UE2XDS20@brm-avmta-1.central.sun.com>; Wed, 28 Apr 2010 09:08:57 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3SF8uPE023993; Wed, 28 Apr 2010 15:08:56 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3SDqWne024250; Wed, 28 Apr 2010 15:08:55 +0000 (GMT) Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 217403931272467334; Wed, 28 Apr 2010 08:08:54 -0700 Received: from [129.147.223.4] (/129.147.223.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 28 Apr 2010 08:08:53 -0700 Date: Wed, 28 Apr 2010 09:08:53 -0600 From: Michael Kearney Subject: Re: SER removal [PSARC/2010/110] In-reply-to: <4BCEC259.9060703@oracle.com> To: Peter Dennis Cc: PSARC-ext , Lukas Rovensky Message-id: <4BD84F85.9000907@oracle.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Jazzneanc06pWNARz2aL3w)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0201.4BD84F88.00A6:SCFMA4539814,ss=1,fgs=0 References: <4BCEC259.9060703@oracle.com> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 16847 This is a multi-part message in MIME format. --Boundary_(ID_Jazzneanc06pWNARz2aL3w) Content-type: multipart/alternative; boundary="Boundary_(ID_vhA3LhIEBf9jXfZshuruSg)" --Boundary_(ID_vhA3LhIEBf9jXfZshuruSg) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT c/exceptio/exception/ c/sourse/source/ On 4/21/2010 3:16 AM, Peter Dennis wrote: > Updated proposal has been put into the case and is included below. > > This case has been scheduled for the PSARC meeting of 28-April-2010. > > Thanks > pete > > > 1. Introduction > 1.1 Project/Component Working Name: > SER removal > > 1.2 Name of Document Author/Supplier: > Author: Lukas Rovensky > > 1.3 Date of This Document: > 19 March, 2010 > > 1.4 The requested release taxonomy: > Patch binding for the announcement and marking as Obsolete. > Minor binding for the removal. > > 1.5 Introduction > > This FastTrack will EOF the Sip Express Router (SER) and its web > based > interface -- SERWeb -- from Solaris Next and obsolete SER and > SERWeb in > Solaris 10. > > On November 4th 2008 a new SIP Router project was announced and > joined > by SER developers, [1]. This also means that SER itself is no longer > developed in favour of the SIP Router, [2]. > > Since SER is no longer developed product it shall be removed from > Solaris Next. Should a similar product be required then the SIP > Router > (Kamailio) may be a good candidate. > > Note, that attributes(5) documents an exceptio, which can apply to > this > case: > > 4. An interface specification which isn't controlled > by Sun has been changed incompatibly and the vast > majority of interface consumers expect the newer > interface. > > 1.6 Previous Relevant ARC cases > > LSARC/2004/324 - sfw/SIP Proxy Server (actually still in waiting > state), [3] > > 1.7 SIP Status In Solaris, RFC 3261 > > SER itself provides functionality, which implements SIP protocol, > RFC 3261, > [8]. There are currently also two libraries in Solaris, which > implement > the SIP protocol (RFC 3261, [8]) and can be eventually used for > implementation of SIP routing: > > * libsip (also in S10, since U4), PSARC 2006/402, [4], CR > 6461142, [5] > This library is developed by Oracle and it is available both > in Solaris > 10 and OpenSolaris / Solaris Next. As per the responsible > engineer, > there is at least one customer, who had built its application > using > libsip. > > * libosip2, LSARC 2009/277, [6], CR 6826484, [7] > This is an open sourse library, [9]. There are no further > plans with > this library as per the responsible engineer. > > 1.8 Input From Marketing, Usage of SER > > Marketing was informed about the intention to remove SER from Solaris > Next. They do not seem to have any real data, which would support or > deny this action. Their current position is as the following: > > "Right now, I agree with the general position that SER seems like an > unsupported offering and we should drop it, however we do need to > assess if we should and who should pick up SIP router." > > The I-team also tried to approach OS Ambassadors (sig.oe@sun.com) > to get > more info about SER usage but no one provided any data. > > The I-team also looked at IPS download statistics maintained by > Stephen > Hahn and by end of February 2010 SER reached 24813 downloads as part > of OpenSolaris. > > 2. Documentation > > Obsoleting SER and SERWeb in Solaris 10 will be announced in > release notes > for Solaris 10. > > Interface Stability in SER man page (ser(8)) in Solaris 10 will be > set to > "Obsolete, External". > > 3. Packaging and Delivery > > SUNWserr, SUNWseru and SUNWserweb packages will be removed from > OpenSolaris. This does mean that the renamed packages will no longer > be delivered (service:network:sip:ser and > service:network:sip:ser:administration). > > 4. Interfaces > > All the interfaces described below will be obsoleted in Solaris 10 > and removed from OpenSolars / SNV. > > The following files and directories (including all their content) > will be > removed from OpenSolaris / SNV: > > /usr/sfw/sbin/ser > /usr/sfw/sbin/serctl > /usr/sfw/lib/ser/ > /usr/sfw/share/doc/ser/ > /etc/sfw/ser/ > /usr/sfw/share/serweb/ > > 5. References > > [1] http://sip-router.org/2008/11/04/the-sip-router-project-launched/ > [2] http://sip-router.org/ > [3] http://sac.sfbay/LSARC/2004/324/ > [4] http://sac.sfbay/PSARC/2006/402/ > http://arc.opensolaris.org/caselog/PSARC/2006/402/ > [5] http://monaco.sfbay/detail.jsf?cr=6461142-2145051 > > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6461142 > [6] http://sac.sfbay/LSARC/2009/277/ > http://arc.opensolaris.org/caselog/LSARC/2009/277/ > [7] http://monaco.sfbay/detail.jsf?cr=6826484 > > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6826484 > [8] http://www.ietf.org/rfc/rfc3261.txt > [9] http://www.gnu.org/software/osip/ > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > sfw > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > -- * Michael Kearney * Principal Software Engineer *Oracle Corp.* MS UBRM05-390, 500 Eldorado Blvd Broomfield, CO 80021 US Phone 303-272-2402 Fax 303-272-6554 Email Michael.Kearney@Oracle.COM --Boundary_(ID_vhA3LhIEBf9jXfZshuruSg) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT c/exceptio/exception/
c/sourse/source/

On 4/21/2010 3:16 AM, Peter Dennis wrote:
Updated proposal has been put into the case and is included below.

This case has been scheduled for the PSARC meeting of 28-April-2010.

Thanks
pete


1.  Introduction
1.1 Project/Component Working Name:
    SER removal

1.2 Name of Document Author/Supplier:
    Author: Lukas Rovensky

1.3 Date of This Document:
    19 March, 2010

1.4 The requested release taxonomy:
    Patch binding for the announcement and marking as Obsolete.
    Minor binding for the removal.

1.5 Introduction

    This FastTrack will EOF the Sip Express Router (SER) and its web based
    interface -- SERWeb -- from Solaris Next and obsolete SER and SERWeb in
    Solaris 10.

    On November 4th 2008 a new SIP Router project was announced and joined
    by SER developers, [1].  This also means that SER itself is no longer
    developed in favour of the SIP Router, [2].

    Since SER is no longer developed product it shall be removed from
    Solaris Next.  Should a similar product be required then the SIP Router
    (Kamailio) may be a good candidate.

    Note, that attributes(5) documents an exceptio, which can apply to this
    case:

         4.   An interface specification which  isn't  controlled
              by  Sun  has been changed incompatibly and the vast
              majority of interface consumers  expect  the  newer
              interface.

1.6 Previous Relevant ARC cases

    LSARC/2004/324 - sfw/SIP Proxy Server (actually still in waiting state), [3]

1.7 SIP Status In Solaris, RFC 3261

    SER itself provides functionality, which implements SIP protocol, RFC 3261,
    [8].  There are currently also two libraries in Solaris, which implement
    the SIP protocol (RFC 3261, [8]) and can be eventually used for
    implementation of SIP routing:

       * libsip (also in S10, since U4), PSARC 2006/402, [4], CR 6461142, [5]
         This library is developed by Oracle and it is available both in Solaris
         10 and OpenSolaris / Solaris Next.  As per the responsible engineer,
         there is at least one customer, who had built its application using
         libsip.

       * libosip2, LSARC 2009/277, [6], CR 6826484, [7]
         This is an open sourse library, [9].  There are no further plans with
         this library as per the responsible engineer.

1.8 Input From Marketing, Usage of SER

    Marketing was informed about the intention to remove SER from Solaris
    Next.  They do not seem to have any real data, which would support or
    deny this action.  Their current position is as the following:

    "Right now, I agree with the general position that SER seems like an
     unsupported offering and we should drop it, however we do need to
     assess if we should and who should pick up SIP router."

    The I-team also tried to approach OS Ambassadors (sig.oe@sun.com) to get
    more info about SER usage but no one provided any data.

    The I-team also looked at IPS download statistics maintained by Stephen
    Hahn and by end of February 2010 SER reached 24813 downloads as part
    of OpenSolaris.

2.  Documentation

    Obsoleting SER and SERWeb in Solaris 10 will be announced in release notes
    for Solaris 10.

    Interface Stability in SER man page (ser(8)) in Solaris 10 will be set to
    "Obsolete, External".

3.  Packaging and Delivery

    SUNWserr, SUNWseru and SUNWserweb packages will be removed from
    OpenSolaris.  This does mean that the renamed packages will no longer
    be delivered (service:network:sip:ser and
    service:network:sip:ser:administration).

4.  Interfaces

    All the interfaces described below will be obsoleted in Solaris 10
    and removed from OpenSolars / SNV.

    The following files and directories (including all their content) will be
    removed from OpenSolaris / SNV:

    /usr/sfw/sbin/ser
    /usr/sfw/sbin/serctl
    /usr/sfw/lib/ser/
    /usr/sfw/share/doc/ser/
    /etc/sfw/ser/
    /usr/sfw/share/serweb/

5.  References

    [1] http://sip-router.org/2008/11/04/the-sip-router-project-launched/
    [2] http://sip-router.org/
    [3] http://sac.sfbay/LSARC/2004/324/
    [4] http://sac.sfbay/PSARC/2006/402/
        http://arc.opensolaris.org/caselog/PSARC/2006/402/
    [5] http://monaco.sfbay/detail.jsf?cr=6461142-2145051
        http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6461142
    [6] http://sac.sfbay/LSARC/2009/277/
        http://arc.opensolaris.org/caselog/LSARC/2009/277/
    [7] http://monaco.sfbay/detail.jsf?cr=6826484
        http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6826484
    [8] http://www.ietf.org/rfc/rfc3261.txt
    [9] http://www.gnu.org/software/osip/


6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
sfw
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open


--
Michael Kearney
Principal Software Engineer

Oracle Corp.
MS UBRM05-390, 500 Eldorado Blvd
Broomfield, CO 80021 US
Phone 303-272-2402
Fax 303-272-6554
Email Michael.Kearney@Oracle.COM
--Boundary_(ID_vhA3LhIEBf9jXfZshuruSg)-- --Boundary_(ID_Jazzneanc06pWNARz2aL3w) Content-type: text/x-vcard; charset=utf-8; name=michael_kearney.vcf Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=michael_kearney.vcf begin:vcard fn:Michael Kearney n:Kearney;Michael org:VTCS Enterprise Engineering;Tikka adr:;;500 Eldorado Blvd;Broomfield;CO;80021;USA email;internet:michael.kearney@oracle.com title:Principal Software Engineer tel;work:303-272-2402 url:http://www.oracle.com version:2.1 end:vcard --Boundary_(ID_Jazzneanc06pWNARz2aL3w)-- From peter.dennis@oracle.com Wed Apr 28 08:55:29 2010 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 o3SFtT16016791 for ; Wed, 28 Apr 2010 08:55:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3SFtRfh026481 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Apr 2010 09:55:29 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1L00L0HG8GXL00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Apr 2010 08:55:28 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1L00ATYG8C7630@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Apr 2010 08:55:25 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3SFtOBF022827 for ; Wed, 28 Apr 2010 15:55:24 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L1L00E00DB33B00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Apr 2010 16:55:24 +0100 (BST) Received: from [129.156.198.33] ([unknown] [129.156.198.33]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L1L00J04G8CTN90@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 28 Apr 2010 16:55:24 +0100 (BST) Date: Wed, 28 Apr 2010 16:55:23 +0100 From: Peter Dennis Subject: Re: SER removal [PSARC/2010/110] In-reply-to: <4BD84F85.9000907@oracle.com> Sender: Peter.Dennis@sun.com To: Michael Kearney Cc: PSARC-ext , Lukas Rovensky Message-id: <4BD85A6B.30709@oracle.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4BCEC259.9060703@oracle.com> <4BD84F85.9000907@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 142 On 04/28/10 16:08, Michael Kearney wrote: > c/exceptio/exception/ > c/sourse/source/ > Thank you. I've fixed the document within the case. From peter.dennis@oracle.com Thu Apr 29 02:24:35 2010 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 o3T9OYbR027692 for ; Thu, 29 Apr 2010 02:24:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3T9OXW0004288 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 29 Apr 2010 03:24:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1M00315SSYLG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Apr 2010 02:24:34 -0700 (PDT) Received: from gmp-eb-inf-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 <0L1M00A2TSSW7WC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Apr 2010 02:24:32 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3T9OVl7021871 for ; Thu, 29 Apr 2010 09:24:31 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L1M00000SMIFJ00@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Apr 2010 10:24:30 +0100 (BST) Received: from [129.156.198.33] ([unknown] [129.156.198.33]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L1M000UYSSU7690@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 29 Apr 2010 10:24:30 +0100 (BST) Date: Thu, 29 Apr 2010 10:24:30 +0100 From: Peter Dennis Subject: Re: SER removal [PSARC/2010/110] In-reply-to: <4BCEC259.9060703@oracle.com> Sender: Peter.Dennis@sun.com To: PSARC-ext , Lukas Rovensky Message-id: <4BD9504E.2020708@oracle.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4BCEC259.9060703@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 851 After a discussion during the PSARC meeting of 28-April-2010 this case was moved back to being a fasttrack and was approved. The discussion centered around: o this is not being removed from Solaris 10, just marked as Obsolete. o there does exist an external project that could be downloaded and used as a replacement (and recommended by the external SER owners). o this is not setting a precedent. o the case derailer, Garrett D'Amore, supported the rerailing of the case as the project have undertaken the background work to ensure that the missing functionality is not desired by marketing. o there was talk about minor vs. patch and the general agreement was that the Solaris 10/Solaris Next boundary is the right time for this removal, rather than deferring to a later patch update within the Solaris Next timeframe.