From gd78059@sac.sfbay.sun.com Wed Oct 7 22:56:21 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n985uKbp020704 for ; Wed, 7 Oct 2009 22:56:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n985uBV8018941; Thu, 8 Oct 2009 13:56:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KR60030BLTU6000@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Oct 2009 22:56:18 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR600H19LTU5350@nwk-avmta-2.sfbay.sun.com>; Wed, 07 Oct 2009 22:56:18 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n985uISd001609; Wed, 07 Oct 2009 22:56:18 -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 n985uGqx020699; Wed, 07 Oct 2009 22:56:16 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n985uF34020695; Wed, 07 Oct 2009 22:56:15 -0700 (PDT) Date: Wed, 07 Oct 2009 22:56:15 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009] To: PSARC-ext@sun.com Message-id: <200910080556.n985uF34020695@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5435 The following fast track (submitted on my own behalf) straddles (IMO) the boundary between a full-case and a fast track, primarily because of the impact it has on what are presumed to be Committed interfaces. It seems fairly straight-forward to me, but other members may feel otherwise. With that in mind, if a member feels discussion or an explicit vote is required, please don't hestite to derail it. I've also used a two-week timer to ensure that sufficient time is given for members to review and derail if that is appropriate. Thanks. - Garrett Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: EOF of plotting components 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 07 October, 2009 4. Technical Description EOF of plot, graph, lpr -g, and related legacy ---------------------------------------------- As part of my analysis of UCB legacy we can potentially clean up, one of the items that came up is the support for legacy plotters via the plot(4B) file format, libplot, graph(1), and the various /usr/ucb/ plotting commands. It turns out that these bits are used to support physical devices which are no longer readily accessible, and probably have not been so in quite a long time. (These devices largely date back to the 70's, 80's, and early 90's.) Modern devices use PostScript or HP-GL/2, neither of which are supported by the current Solaris plotting infrastructure, but are well supported via the same infrastructure used to support ordinary printers. There is also support for plotting to a terminal device, either a graphics or a text based terminal. The graphics terminals that are supported are quite ancient (although "xterm" can emulate a Tek 4013 device), and the project team feels that the plotting support for character based terminals is of rather limited use. Note also that users who might still have such ancient hardware (or want to plot to a terminal device) might find they are able to plot to it using the "gnuplot" command, which has output drivers for it. (Gnuplot is not yet integrated, but this is expected as it was approved as part of PSARC 2009/395. If the PSARC members feel the rest of this case warrants sufficient risk to justify it, this project team is willing to accept delivery of PSARC 2009/395 as a pre-requisite, although we don't particularly feel that it should be so.) Proposal -------- 1) We propose to entirely remove all of the plotting commands from /usr/ucb. This consists of /usr/ucb/aedplot /usr/ucb/atoplot /usr/ucb/bgplot /usr/ucb/crtplot /usr/ucb/dumbplot /usr/ucb/gigiplot /usr/ucb/hp7221plot /usr/ucb/hpplot /usr/ucb/implot /usr/ucb/plot /usr/ucb/vplot /usr/ucb/t300 /usr/ucb/t300s /usr/ucb/t4013 /usr/ucb/t450 /usr/ucb/tek We don't believe any applications will be impacted by this removal. 2) We propose to remove /usr/bin/graph. We believe this program is also not terribly useful, since the only way to generate plotting output from it is with one of the above commands, which almost certainly precludes being able to get hardcopy. (And graphical display is probably limited to output in an xterm tek window, for users with enough savvy to figure this part out.) Note that gnuplot offers a vastly superior superset of graph(1)'s capabilities, and is capable of processing graph(1) input files. (It would probably be only a small task to provide a shell-script called "graph" that offered the same command line switches as graph(1), but used gnuplot to generate its output. The utility of this seems questionable, however, unless the output format is changed from plot(4B) -- which gnuplot can generate -- but which would also defeat any compatibility purpose. 3) We propose to obsolete libplot(3plot) and its brethren, but leave the libraries in place for the benefit of applications which may have linked against them in the past. (It is impossible to know what those applications might be.) The specific taxonomy changes are (note that no stability was ever mentioned before for these libraries, so we assume Committed for this use): /usr/lib/libplot.so.1 Obsolete Committed /usr/lib/lib300.so.1 " " /usr/lib/lib300s.so.1 " " /usr/lib/lib4014.so.1 " " /usr/lib/lib450.so.1 " " /usr/lib/libvt0.so.1 " " Note: Its likely that these libraries could be safely removed -- despite the "Committed" level -- or replaced with stubs that simply resolve the symbols but don't actually generate any output. We simply don't believe any real programs use these libraries but we don't know for sure. 4) We propose to remove the "-g" option to /usr/ucb/lpr, which was intended to support the plot(4B) format. Again, real devices which could benefit from these filters are just not to be found in the modern era. Lpr would exit with an error number if this option is supplied. Note that /usr/ucb/lpr is already effectively obsolete, by virtue of being delivered in /usr/ucb. Also, CUPS lacks support for this option, so eliminating it will facilitate an eventual replacement of our legacy printing stack with the far more functional and better-maintained CUPS implementation. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From bart.smaalders@sun.com Thu Oct 8 10:08:30 2009 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 n98H8UnG014449 for ; Thu, 8 Oct 2009 10:08:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n98H8Tot015169 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Thu, 8 Oct 2009 11:08:30 -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 <0KR700B0BGY6LE00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 08 Oct 2009 10:08:30 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KR700052GY5IGC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 08 Oct 2009 10:08:29 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n98H7NKJ016969; Thu, 08 Oct 2009 17:07:23 +0000 (GMT) Date: Thu, 08 Oct 2009 10:06:27 -0700 From: Bart Smaalders Subject: Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009] In-reply-to: <200910080556.n985uF34020695@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com Message-id: <4ACE1C13.70802@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080556.n985uF34020695@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 493 Garrett D'Amore - sun microsystems wrote: > The following fast track (submitted on my own behalf) straddles (IMO) the > boundary between a full-case and a fast track, primarily because of the > impact it has on what are presumed to be Committed interfaces. Thanks for doing this; it's well past time for these to go. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From Sebastien.Roy@sun.com Wed Oct 21 07:33:19 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9LEXHAi027625 for ; Wed, 21 Oct 2009 07:33:17 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n9LEWq21000294 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Oct 2009 22:33:16 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRV00C09CFG6J00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 21 Oct 2009 07:33:16 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRV004MRCFFKSA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.Com); Wed, 21 Oct 2009 07:33:15 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9LEXF5d005068 for ; Wed, 21 Oct 2009 14:33:15 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRV00300CDL9E00@mail-amer.sun.com> for PSARC-ext@Sun.Com (ORCPT PSARC-ext@Sun.Com); Wed, 21 Oct 2009 08:33:15 -0600 (MDT) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRV00KUACF14480@mail-amer.sun.com>; Wed, 21 Oct 2009 08:33:01 -0600 (MDT) Date: Wed, 21 Oct 2009 10:30:35 -0400 From: Sebastien Roy Subject: Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009] In-reply-to: <200910080556.n985uF34020695@sac.sfbay.sun.com> Sender: Sebastien.Roy@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com Message-id: <1256135435.13241.32.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080556.n985uF34020695@sac.sfbay.sun.com> Status: RO Content-Length: 827 On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems wrote: > The following fast track (submitted on my own behalf) straddles (IMO) the > boundary between a full-case and a fast track, primarily because of the > impact it has on what are presumed to be Committed interfaces. > > It seems fairly straight-forward to me, but other members may feel otherwise. > With that in mind, if a member feels discussion or an explicit vote is > required, please don't hestite to derail it. I've also used a two-week timer > to ensure that sufficient time is given for members to review and derail if > that is appropriate. Thanks. I don't see a release binding associated with this case. I give this case a +1 assuming that the binding is not less than Minor (i.e., this is not applicable for Patch or Micro). -Seb From gdamore@sun.com Wed Oct 21 14:44:39 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9LLidG3012430 for ; Wed, 21 Oct 2009 14:44:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9LLicL5003280 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 21 Oct 2009 14:44:39 -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 <0KRV0001BWEELW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 21 Oct 2009 15:44:38 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRV00CY1WEDRMC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 21 Oct 2009 15:44:37 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9LLib2U006604 for ; Wed, 21 Oct 2009 14:44:37 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRV00B00VPZOR00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 21 Oct 2009 14:44:37 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRV0069XWEAFH70@fe-sfbay-09.sun.com>; Wed, 21 Oct 2009 14:44:35 -0700 (PDT) Date: Wed, 21 Oct 2009 14:44:34 -0700 From: "Garrett D'Amore" Subject: Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009] In-reply-to: <1256135435.13241.32.camel@strat> Sender: Garrett.Damore@sun.com To: Sebastien Roy Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4ADF80C2.20807@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: <200910080556.n985uF34020695@sac.sfbay.sun.com> <1256135435.13241.32.camel@strat> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 1010 Sebastien Roy wrote: > On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems > wrote: > >> The following fast track (submitted on my own behalf) straddles (IMO) the >> boundary between a full-case and a fast track, primarily because of the >> impact it has on what are presumed to be Committed interfaces. >> >> It seems fairly straight-forward to me, but other members may feel otherwise. >> With that in mind, if a member feels discussion or an explicit vote is >> required, please don't hestite to derail it. I've also used a two-week timer >> to ensure that sufficient time is given for members to review and derail if >> that is appropriate. Thanks. >> > > I don't see a release binding associated with this case. I give this > case a +1 assuming that the binding is not less than Minor (i.e., this > is not applicable for Patch or Micro). > > -Seb > > > Yes, it should have been minor. Thanks. This case was approved at PSARC today, and has minor binding. - Garrett From gdamore@sun.com Wed Oct 21 20:37:31 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9M3bUwP019268 for ; Wed, 21 Oct 2009 20:37:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n9M3bNNM022583 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 22 Oct 2009 11:37:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KRW00M01CQEWF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 21 Oct 2009 20:37:26 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KRW00LQICQERZ00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 21 Oct 2009 20:37:26 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9M3bQNn008206 for ; Wed, 21 Oct 2009 20:37:26 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KRW00300CQ6WR00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 21 Oct 2009 20:37:26 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KRW008I8CQD6670@fe-sfbay-09.sun.com>; Wed, 21 Oct 2009 20:37:26 -0700 (PDT) Date: Wed, 21 Oct 2009 20:37:25 -0700 From: "Garrett D'Amore" Subject: Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009] In-reply-to: <4ADF80C2.20807@sun.com> Sender: Garrett.Damore@sun.com To: Sebastien Roy Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4ADFD375.5020107@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: <200910080556.n985uF34020695@sac.sfbay.sun.com> <1256135435.13241.32.camel@strat> <4ADF80C2.20807@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 2572 So, in the process of going about the work to remove these utilities, I found a few surprises. First off, it is possible to take "graph" output, and generate postscript, using the "postplot" utility (located in /usr/lib/lp/postscript). Second, it turns out that there are other postscript filters related to postplot in some way, but which possibly could also be removed as they are unlikely to be found useful in modern systems. (I'm speaking specifically of posttek and postdaisy, which convert Tek 4014 and Diablo 630 format files into PostScript.) What isn't clear to me here is what the best approach is. Some options: 1) Decline to remove "/usr/bin/graph" at this point, and remove it only later when/if we find we can remove the postscript commands. 2) We could also leave the "-g" option in LPR, although I think its better to remove it since CUPS can't support it. 3) We could remove "postplot" (which mostly exists for the purpose of dealing with "lpr -g"), as well. 4) We could decline to implement the case at all, although I think that is silly. There is clearly at least *some* baggage here that we can remove. My personal preference is to just remove it all, probably in two phases. Phase 1 will implement the stuff specified here, as specified and approved. Phase 2 would be a new case to remove the "posttek", "postplot", "postdaisy" utilities, subject to separate PSARC and C-Team/P-Team review. Any strong opinions here? - Garrett Garrett D'Amore wrote: > Sebastien Roy wrote: >> On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems >> wrote: >> >>> The following fast track (submitted on my own behalf) straddles >>> (IMO) the >>> boundary between a full-case and a fast track, primarily because of the >>> impact it has on what are presumed to be Committed interfaces. >>> >>> It seems fairly straight-forward to me, but other members may feel >>> otherwise. >>> With that in mind, if a member feels discussion or an explicit vote is >>> required, please don't hestite to derail it. I've also used a >>> two-week timer >>> to ensure that sufficient time is given for members to review and >>> derail if >>> that is appropriate. Thanks. >>> >> >> I don't see a release binding associated with this case. I give this >> case a +1 assuming that the binding is not less than Minor (i.e., this >> is not applicable for Patch or Micro). >> >> -Seb >> >> >> > Yes, it should have been minor. Thanks. This case was approved at > PSARC today, and has minor binding. > > - Garrett From gdamore@sun.com Tue Oct 27 08:52:10 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9RFq8BU007422 for ; Tue, 27 Oct 2009 08:52:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9RFq2kB008773 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 27 Oct 2009 15:52:08 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KS600B5BK2VZ200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 09:52:07 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS600KO1K2UO8E0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 09:52:06 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9RFq6AA002447 for ; Tue, 27 Oct 2009 08:52:06 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KS600000JX45T00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 08:52:06 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KS600L3XK2SLFG0@fe-sfbay-09.sun.com>; Tue, 27 Oct 2009 08:52:05 -0700 (PDT) Date: Tue, 27 Oct 2009 08:52:04 -0700 From: "Garrett D'Amore" Subject: Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009] In-reply-to: <4ADFD375.5020107@sun.com> Sender: Garrett.Damore@sun.com To: Sebastien Roy Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <4AE71724.10103@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: <200910080556.n985uF34020695@sac.sfbay.sun.com> <1256135435.13241.32.camel@strat> <4ADF80C2.20807@sun.com> <4ADFD375.5020107@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 3530 In the absence of feedback, I've decided that the best approach is to leave the functionality that is potentially still useful, and remove the functionality that is not. I'm doing this as an update to this case; I don't believe restarting the timer is necessary. Here's the actual changes: 1) Remove the /usr/ucb plotting commands, as indicated. 2) Leave graph and lpr -g alone for now. 3) Leave any other commands (posttek, postplot) alone for now. A future case will be necessary if /usr/bin/graph, or any of the other stuff (outside of the /usr/ucb commands) that deals with plot(4UCB) is to be removed. Personally, I believe the time is ripe to eliminate that stuff, but I don't want to broaden the scope of *this* case without properly reviewing it. I'll file a separate case to do that later. - Garrett Garrett D'Amore wrote: > > So, in the process of going about the work to remove these utilities, > I found a few surprises. > > First off, it is possible to take "graph" output, and generate > postscript, using the "postplot" utility (located in > /usr/lib/lp/postscript). > > Second, it turns out that there are other postscript filters related > to postplot in some way, but which possibly could also be removed as > they are unlikely to be found useful in modern systems. (I'm > speaking specifically of posttek and postdaisy, which convert Tek 4014 > and Diablo 630 format files into PostScript.) > > What isn't clear to me here is what the best approach is. Some options: > > 1) Decline to remove "/usr/bin/graph" at this point, and remove it > only later when/if we find we can remove the postscript commands. > > 2) We could also leave the "-g" option in LPR, although I think its > better to remove it since CUPS can't support it. > 3) We could remove "postplot" (which mostly exists for the purpose of > dealing with "lpr -g"), as well. > > 4) We could decline to implement the case at all, although I think > that is silly. There is clearly at least *some* baggage here that we > can remove. > > My personal preference is to just remove it all, probably in two > phases. Phase 1 will implement the stuff specified here, as specified > and approved. Phase 2 would be a new case to remove the "posttek", > "postplot", "postdaisy" utilities, subject to separate PSARC and > C-Team/P-Team review. > > Any strong opinions here? > > - Garrett > > > Garrett D'Amore wrote: >> Sebastien Roy wrote: >>> On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems >>> wrote: >>> >>>> The following fast track (submitted on my own behalf) straddles >>>> (IMO) the >>>> boundary between a full-case and a fast track, primarily because of >>>> the >>>> impact it has on what are presumed to be Committed interfaces. >>>> >>>> It seems fairly straight-forward to me, but other members may feel >>>> otherwise. >>>> With that in mind, if a member feels discussion or an explicit vote is >>>> required, please don't hestite to derail it. I've also used a >>>> two-week timer >>>> to ensure that sufficient time is given for members to review and >>>> derail if >>>> that is appropriate. Thanks. >>>> >>> >>> I don't see a release binding associated with this case. I give this >>> case a +1 assuming that the binding is not less than Minor (i.e., this >>> is not applicable for Patch or Micro). >>> >>> -Seb >>> >>> >>> >> Yes, it should have been minor. Thanks. This case was approved at >> PSARC today, and has minor binding. >> >> - Garrett > From dan.mick@sun.com Thu Oct 29 22:17:39 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9U5HdSA014363 for ; Thu, 29 Oct 2009 22:17:39 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9U5HWai019796; Fri, 30 Oct 2009 05:17:37 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSB00J01APCWR00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 29 Oct 2009 22:17:36 -0700 (PDT) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSB00F3BAPBROB0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 29 Oct 2009 22:17:35 -0700 (PDT) Received: from [10.1.48.101] (angus.West.Sun.COM [10.1.48.101]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9U5HYb3013348; Thu, 29 Oct 2009 22:17:34 -0700 (PDT) Date: Thu, 29 Oct 2009 22:17:34 -0700 From: Dan Mick Subject: Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009] In-reply-to: <4AE71724.10103@sun.com> To: "Garrett D'Amore" Cc: Sebastien Roy , PSARC-ext@sun.com, "Garrett D'Amore - sun microsystems" Message-id: <4AEA76EE.2050203@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200910080556.n985uF34020695@sac.sfbay.sun.com> <1256135435.13241.32.camel@strat> <4ADF80C2.20807@sun.com> <4ADFD375.5020107@sun.com> <4AE71724.10103@sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070419) Status: RO Content-Length: 4603 Garrett asked me for codereview, and in looking, I've noticed that xterm still supports the crufty old Tek 4014 mode, and one can actually make it work with graph and plot (at least). So it's *conceivable* that someone is still using this, although it would have to be nasty moldy old code, I'd think. Given that those people can certainly use graph | postplot, we may officially not care about them. I'm willing to accept that; I just want to make sure those with an opinion know that we're removing the bundled stuff that someone might be using, because, strictly speaking, it's one of the few workable things we have in Solaris at the moment. Given the followups for plotutils, I can't imagine this will be any kind of issue for long, so this is only a nit to make doubly sure the committee agrees. Garrett D'Amore wrote: > In the absence of feedback, I've decided that the best approach is to > leave the functionality that is potentially still useful, and remove the > functionality that is not. I'm doing this as an update to this case; I > don't believe restarting the timer is necessary. Here's the actual > changes: > > 1) Remove the /usr/ucb plotting commands, as indicated. > 2) Leave graph and lpr -g alone for now. > 3) Leave any other commands (posttek, postplot) alone for now. > > A future case will be necessary if /usr/bin/graph, or any of the other > stuff (outside of the /usr/ucb commands) that deals with plot(4UCB) is > to be removed. > > Personally, I believe the time is ripe to eliminate that stuff, but I > don't want to broaden the scope of *this* case without properly > reviewing it. I'll file a separate case to do that later. > > - Garrett > > > Garrett D'Amore wrote: >> >> So, in the process of going about the work to remove these utilities, >> I found a few surprises. >> >> First off, it is possible to take "graph" output, and generate >> postscript, using the "postplot" utility (located in >> /usr/lib/lp/postscript). >> >> Second, it turns out that there are other postscript filters related >> to postplot in some way, but which possibly could also be removed as >> they are unlikely to be found useful in modern systems. (I'm >> speaking specifically of posttek and postdaisy, which convert Tek 4014 >> and Diablo 630 format files into PostScript.) >> >> What isn't clear to me here is what the best approach is. Some options: >> >> 1) Decline to remove "/usr/bin/graph" at this point, and remove it >> only later when/if we find we can remove the postscript commands. >> >> 2) We could also leave the "-g" option in LPR, although I think its >> better to remove it since CUPS can't support it. >> 3) We could remove "postplot" (which mostly exists for the purpose of >> dealing with "lpr -g"), as well. >> >> 4) We could decline to implement the case at all, although I think >> that is silly. There is clearly at least *some* baggage here that we >> can remove. >> >> My personal preference is to just remove it all, probably in two >> phases. Phase 1 will implement the stuff specified here, as specified >> and approved. Phase 2 would be a new case to remove the "posttek", >> "postplot", "postdaisy" utilities, subject to separate PSARC and >> C-Team/P-Team review. >> >> Any strong opinions here? >> >> - Garrett >> >> >> Garrett D'Amore wrote: >>> Sebastien Roy wrote: >>>> On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems >>>> wrote: >>>> >>>>> The following fast track (submitted on my own behalf) straddles >>>>> (IMO) the >>>>> boundary between a full-case and a fast track, primarily because of >>>>> the >>>>> impact it has on what are presumed to be Committed interfaces. >>>>> >>>>> It seems fairly straight-forward to me, but other members may feel >>>>> otherwise. >>>>> With that in mind, if a member feels discussion or an explicit vote is >>>>> required, please don't hestite to derail it. I've also used a >>>>> two-week timer >>>>> to ensure that sufficient time is given for members to review and >>>>> derail if >>>>> that is appropriate. Thanks. >>>>> >>>> >>>> I don't see a release binding associated with this case. I give this >>>> case a +1 assuming that the binding is not less than Minor (i.e., this >>>> is not applicable for Patch or Micro). >>>> >>>> -Seb >>>> >>>> >>>> >>> Yes, it should have been minor. Thanks. This case was approved at >>> PSARC today, and has minor binding. >>> >>> - Garrett >> > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From gww@sac.sfbay.sun.com Wed Nov 4 12:22:23 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA4KMMnX012894 for ; Wed, 4 Nov 2009 12:22:22 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA4KMM2U023237; Wed, 4 Nov 2009 12:22:22 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSL0090JPXAP400@brm-avmta-1.central.sun.com>; Wed, 04 Nov 2009 13:22:22 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSL00LKVPXAGA80@brm-avmta-1.central.sun.com>; Wed, 04 Nov 2009 13:22:22 -0700 (MST) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA4KMLTI024810; Wed, 04 Nov 2009 12:22:21 -0800 (PST) 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 nA4KMJRg012892; Wed, 04 Nov 2009 12:22:19 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id nA4KMItx012891; Wed, 04 Nov 2009 12:22:18 -0800 (PST) Date: Wed, 04 Nov 2009 12:22:18 -0800 (PST) From: Gary Winiger Subject: Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009] To: dan.mick@sun.com, gdamore@sun.com Cc: PSARC-ext@sun.com, Sebastien.Roy@sun.com, gd78059@sac.sfbay.sun.com Message-id: <200911042022.nA4KMItx012891@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1097 > Garrett asked me for codereview, and in looking, I've noticed that xterm still > supports the crufty old Tek 4014 mode, and one can actually make it work with > graph and plot (at least). So it's *conceivable* that someone is still using > this, although it would have to be nasty moldy old code, I'd think. > > Given that those people can certainly use graph | postplot, we may officially > not care about them. I'm willing to accept that; I just want to make sure those > with an opinion know that we're removing the bundled stuff that someone might be > using, because, strictly speaking, it's one of the few workable things we have > in Solaris at the moment. > > Given the followups for plotutils, I can't imagine this will be any kind of > issue for long, so this is only a nit to make doubly sure the committee agrees. At today's PSARC meeting Garrett asked for a follow up to this comment. Since graph is not part of the removal, and there appears to be an OpenSolaris follow up. I don't see an issue surrounding cleaning up the 4014 stuff in a Minor release. Gary.. From dan.mick@sun.com Wed Nov 4 20:27:14 2009 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 nA54REfH022828 for ; Wed, 4 Nov 2009 20:27:14 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA54RDgt025957; Wed, 4 Nov 2009 20:27:14 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSM00C0DCDDEU00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Nov 2009 20:27:13 -0800 (PST) Received: from dm-eng-01.sfbay.sun.com ([129.145.155.198]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSM005OACDCBY90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 04 Nov 2009 20:27:13 -0800 (PST) Received: from [10.1.48.101] (angus.West.Sun.COM [10.1.48.101]) by dm-eng-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA54RCbZ000057; Wed, 04 Nov 2009 20:27:12 -0800 (PST) Date: Wed, 04 Nov 2009 20:27:12 -0800 From: Dan Mick Subject: Re: EOF of plotting components [PSARC/2009/540 FastTrack timeout 10/21/2009] In-reply-to: <200911042022.nA4KMItx012891@sac.sfbay.sun.com> To: Gary Winiger Cc: gdamore@sun.com, PSARC-ext@sun.com, Sebastien.Roy@sun.com, gd78059@sac.sfbay.sun.com Message-id: <4AF25420.2040006@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200911042022.nA4KMItx012891@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070419) Status: RO Content-Length: 1214 Gary Winiger wrote: >> Garrett asked me for codereview, and in looking, I've noticed that xterm still >> supports the crufty old Tek 4014 mode, and one can actually make it work with >> graph and plot (at least). So it's *conceivable* that someone is still using >> this, although it would have to be nasty moldy old code, I'd think. >> >> Given that those people can certainly use graph | postplot, we may officially >> not care about them. I'm willing to accept that; I just want to make sure those >> with an opinion know that we're removing the bundled stuff that someone might be >> using, because, strictly speaking, it's one of the few workable things we have >> in Solaris at the moment. >> >> Given the followups for plotutils, I can't imagine this will be any kind of >> issue for long, so this is only a nit to make doubly sure the committee agrees. > > At today's PSARC meeting Garrett asked for a follow up to this > comment. Since graph is not part of the removal, and there > appears to be an OpenSolaris follow up. I don't see an issue > surrounding cleaning up the 4014 stuff in a Minor release. > > Gary.. I've approved the integration. Thanks for the followon consideration.