From gd78059@sac.sfbay.sun.com Sat Oct 24 20:26: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 n9P3QUcv001355 for ; Sat, 24 Oct 2009 20:26:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n9P3QHA2008681; Sun, 25 Oct 2009 11:26:29 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KS10010BW829S00@brm-avmta-1.central.sun.com>; Sat, 24 Oct 2009 21:26:26 -0600 (MDT) 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 <0KS100M0XW81HM40@brm-avmta-1.central.sun.com>; Sat, 24 Oct 2009 21:26:26 -0600 (MDT) 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 n9P3QPXn026924; Sat, 24 Oct 2009 20:26:25 -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 n9P3QOQP001350; Sat, 24 Oct 2009 20:26:24 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n9P3QOtB001346; Sat, 24 Oct 2009 20:26:24 -0700 (PDT) Date: Sat, 24 Oct 2009 20:26:24 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] To: PSARC-ext@sun.com Cc: Garrett.Damore@sun.com Message-id: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1649 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 stp4020 1.2. Name of Document Author/Supplier: Author: Garrett D'Amore 1.3 Date of This Document: 24 October, 2009 4. Technical Description EOF of stp4020 driver --------------------- The stp4020 device driver supports an Sbus <-> PCMCIA adapter bridge. This hardware was never particularly common, and was potentially used in Sun Ultra 1 and Ultra 2 systems. (Theoretically it could have been used some Enterprise class Sbus systems (sunfire, starfire, campfire), but its unlikely that this was ever actually done in practice. Note that recently the SBus based workstations were officially EOF'd (although code in ON still remains for them) and will not be supported in next release of Solaris. (See PSARC 2009/572.) Note also that PCMCIA is a very slow legacy bus, and unlikely to be useful to users with more modern systems. The upshot of this is that we feel the time is ripe to eliminate the support for the stp4020 driver from OpenSolaris. NOTE: Furthermore, after the removal of Tadpole SPARCLE (PSARC 2009/538), its unlikely that there are any folks using PCMCIA on SPARC anymore, and certainly not with SPARC and OpenSolaris. It would be a good idea to investigate the idea of removing the PCMCIA and Cardbus components from SPARC as part of another case. 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 ro@techfak.uni-bielefeld.de Tue Oct 27 09:42:29 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 n9RGgS3K008942 for ; Tue, 27 Oct 2009 09:42:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9RGgSGL009509; Tue, 27 Oct 2009 09:42:28 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KS60041RMEQDU00@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Oct 2009 09:42:26 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS600KHEMEOS290@nwk-avmta-2.sfbay.sun.com>; Tue, 27 Oct 2009 09:42:24 -0700 (PDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9RGPcWO003041; Tue, 27 Oct 2009 16:42:24 +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-4622796; Tue, 27 Oct 2009 16:42:23 +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-24437721; Tue, 27 Oct 2009 16:42:20 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay4i.sun.com with ESMTP id BT-MMP-1935364; Tue, 27 Oct 2009 16:42:20 +0000 (Z) Received: from komagatake.TechFak.Uni-Bielefeld.DE (komagatake.TechFak.Uni-Bielefeld.DE [129.70.137.126]) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id DBD74DE; Tue, 27 Oct 2009 17:42:19 +0100 (CET) Received: (from ro@localhost) by komagatake.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) id n9RGgJf19831; Tue, 27 Oct 2009 17:42:19 +0100 (MET) Date: Tue, 27 Oct 2009 17:42:19 +0100 From: Rainer Orth Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: "Garrett D'Amore - sun microsystems"'s message of "Sat, 24 Oct 2009 20:26:24 -0700 (PDT)" Sender: ro@techfak.uni-bielefeld.de To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com Message-id: MIME-version: 1.0 X-Mailer: Gnus v5.6.44/Emacs 19.34 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.873sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ Lines: 17 References: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> Status: RO Content-Length: 712 "Garrett D'Amore - sun microsystems" writes: > Note that recently the SBus based workstations were officially EOF'd (although > code in ON still remains for them) and will not be supported in next > release of Solaris. (See PSARC 2009/572.) > > Note also that PCMCIA is a very slow legacy bus, and unlikely to be useful Not this case, but I'm quite disappointed and upset that this was run as a closed self-review case despite I assume that this would be quite controversial. Isn't this supposed to be *Open*Solaris after all? Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From Garrett.Damore@sun.com Tue Oct 27 10:00:32 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 n9RH0Uji009586 for ; Tue, 27 Oct 2009 10:00:31 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9RH0M0j024421 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 27 Oct 2009 17:00:30 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KS600501N8SBL00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 10:00:28 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS600K15N8RS2B0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 10:00:28 -0700 (PDT) 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 n9RH0RH0028718 for ; Tue, 27 Oct 2009 10:00:27 -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 <0KS600D00MPLUX00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 10:00:27 -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 <0KS600I4MN8AAZB0@fe-sfbay-09.sun.com>; Tue, 27 Oct 2009 10:00:11 -0700 (PDT) Date: Tue, 27 Oct 2009 10:00:10 -0700 From: "Garrett D'Amore" Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: Sender: Garrett.Damore@sun.com To: Rainer Orth Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4AE7271A.1020700@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: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 874 Rainer Orth wrote: > "Garrett D'Amore - sun microsystems" writes: > > >> Note that recently the SBus based workstations were officially EOF'd (although >> code in ON still remains for them) and will not be supported in next >> release of Solaris. (See PSARC 2009/572.) >> >> Note also that PCMCIA is a very slow legacy bus, and unlikely to be useful >> > > Not this case, but I'm quite disappointed and upset that this was run as a > closed self-review case despite I assume that this would be quite > controversial. Isn't this supposed to be *Open*Solaris after all? > > Rainer > > Its "closed" meaning I didn't expect this to be controversial at all. Why do you believe that this case is controversial? (If you're referring to PSARC 2009/572, that *was* run as closed, and I happen to share your sentiment.) - Garrett From ro@techfak.uni-bielefeld.de Tue Oct 27 10:13:07 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 n9RHD6JH009954 for ; Tue, 27 Oct 2009 10:13:06 -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 n9RHCxfI000172; Tue, 27 Oct 2009 10:13:06 -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 <0KS600K4FNTS8V00@brm-avmta-1.central.sun.com>; Tue, 27 Oct 2009 11:13:04 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS600C74NTS3R80@brm-avmta-1.central.sun.com>; Tue, 27 Oct 2009 11:13:04 -0600 (MDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9RH6uIF006681; Tue, 27 Oct 2009 17:13:03 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay15i.sun.com with ESMTP id BT-MMP-838852; Tue, 27 Oct 2009 17:13:03 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-33242810; Tue, 27 Oct 2009 17:13:03 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay1i.sun.com with ESMTP id BT-MMP-1246834; Tue, 27 Oct 2009 17:13:03 +0000 (Z) Received: from komagatake.TechFak.Uni-Bielefeld.DE (komagatake.TechFak.Uni-Bielefeld.DE [129.70.137.126]) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id B3C0EB6; Tue, 27 Oct 2009 18:13:02 +0100 (CET) Received: (from ro@localhost) by komagatake.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) id n9RHD2o20375; Tue, 27 Oct 2009 18:13:02 +0100 (MET) Date: Tue, 27 Oct 2009 18:13:00 +0100 (MET) From: Rainer Orth Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AE7271A.1020700@sun.com> To: Garrett.Damore@sun.com Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Message-id: <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> MIME-version: 1.0 X-Mailer: VM 6.62 under Emacs 19.34.1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== References: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> Status: RO Content-Length: 916 Garrett D'Amore writes: > Its "closed" meaning I didn't expect this to be controversial at all. > Why do you believe that this case is controversial? (If you're *This* case isn't too controversial, although I happen to have both SBus machines and one of those cards, so I'm affected, but it isn't really bad. > referring to PSARC 2009/572, that *was* run as closed, and I happen to > share your sentiment.) Indeed I was, and I consider this to be a slap in the community's face: it is well known that some non-Sun distributions added my hack to re-enable UltraSPARC I support, and I have a sponsor to have it added back to Nevada. So there is considerable community interest, and this is being sneaked in like this ;-( Not what I consider proper procedure. Rainer ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From Garrett.Damore@sun.com Tue Oct 27 10:19:34 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 n9RHJY7n010248 for ; Tue, 27 Oct 2009 10:19:34 -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 n9RHJOR1062118 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 27 Oct 2009 11:19:33 -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 <0KS60053ZO4K7L00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 10:19:32 -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 <0KS600LF7O4KX140@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 10:19:32 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9RHJWsB013450 for ; Tue, 27 Oct 2009 10:19:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KS600D00NRYL400@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 10:19:32 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KS600EUPO4GOH90@fe-sfbay-10.sun.com>; Tue, 27 Oct 2009 10:19:29 -0700 (PDT) Date: Tue, 27 Oct 2009 10:19:28 -0700 From: "Garrett D'Amore" Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> Sender: Garrett.Damore@sun.com To: Rainer Orth Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4AE72BA0.5020308@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: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 2052 Rainer Orth wrote: > Garrett D'Amore writes: > > >> Its "closed" meaning I didn't expect this to be controversial at all. >> Why do you believe that this case is controversial? (If you're >> > > *This* case isn't too controversial, although I happen to have both SBus > machines and one of those cards, so I'm affected, but it isn't really bad. > > >> referring to PSARC 2009/572, that *was* run as closed, and I happen to >> share your sentiment.) >> > > Indeed I was, and I consider this to be a slap in the community's face: it > is well known that some non-Sun distributions added my hack to re-enable > UltraSPARC I support, and I have a sponsor to have it added back to > Nevada. So there is considerable community interest, and this is being > sneaked in like this ;-( Not what I consider proper procedure. > As I said, I share your sentiment. The decision here was made by Sun management for business reasons. (Ultimately it comes down to long term support issues. If we don't remove support at this point, we'll probably have to keep support going for at least 5 - 10 years *further*, and the problem becomes one of continuing availability of equipment for support.) Its also the case that many of these systems have framebuffers in them that we cannot continue to support -- there isn't funding to transition the Xsun stuff to Xorg, and the Xsun baggage is holding back new development. (Although one could have imagined that at least *some* of the systems in the field could be supported if they have one of the few remaining supported SPARC graphics cards -- I think the XVR-100 is one such.) I've been contemplating setting up a community repo that could reintegrate some of the platform support that is being removed from ON proper, into a separate "legacy" consolidation, that would not be supported by Sun. Does this sound like something you'd be interested in helping out on? If it is, perhaps the community can come together to solve the problem here going forward. - Garrett From Peter.Dennis@Sun.COM Tue Oct 27 10:24:54 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 n9RHOrhb010503 for ; Tue, 27 Oct 2009 10:24:53 -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 n9RHOqkC012285 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 27 Oct 2009 17:24:52 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 <0KS60050RODFVF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 10:24:51 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS600L89ODEWF60@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 10:24:51 -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-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9RHOoUo025973 for ; Tue, 27 Oct 2009 17:24:50 +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 <0KS600D00NRI3400@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 17:24:35 +0000 (GMT) Received: from [129.156.173.66] ([unknown] [129.156.173.66]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KS600KGOOCZ9130@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 17:24:35 +0000 (GMT) Date: Tue, 27 Oct 2009 17:24:35 +0000 From: Peter Dennis - Sustaining Engineer Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AE72BA0.5020308@sun.com> Sender: Peter.Dennis@Sun.COM To: Garrett.Damore@Sun.COM Cc: Rainer Orth , PSARC-ext@Sun.COM Message-id: <4AE72CD3.9080207@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: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 2449 Garrett D'Amore wrote: > Rainer Orth wrote: >> Garrett D'Amore writes: >> >> >>> Its "closed" meaning I didn't expect this to be controversial at >>> all. Why do you believe that this case is controversial? (If you're >>> >> >> *This* case isn't too controversial, although I happen to have both SBus >> machines and one of those cards, so I'm affected, but it isn't really >> bad. >> >> >>> referring to PSARC 2009/572, that *was* run as closed, and I happen >>> to share your sentiment.) >>> >> >> Indeed I was, and I consider this to be a slap in the community's >> face: it >> is well known that some non-Sun distributions added my hack to re-enable >> UltraSPARC I support, and I have a sponsor to have it added back to >> Nevada. So there is considerable community interest, and this is being >> sneaked in like this ;-( Not what I consider proper procedure. >> > > As I said, I share your sentiment. The decision here was made by Sun > management for business reasons. (Ultimately it comes down to long term > support issues. If we don't remove support at this point, we'll > probably have to keep support going for at least 5 - 10 years *further*, > and the problem becomes one of continuing availability of equipment for > support.) > > Its also the case that many of these systems have framebuffers in them > that we cannot continue to support -- there isn't funding to transition > the Xsun stuff to Xorg, and the Xsun baggage is holding back new > development. (Although one could have imagined that at least *some* of > the systems in the field could be supported if they have one of the few > remaining supported SPARC graphics cards -- I think the XVR-100 is one > such.) > > I've been contemplating setting up a community repo that could > reintegrate some of the platform support that is being removed from ON > proper, into a separate "legacy" consolidation, that would not be > supported by Sun. I think that this would be an interesting and valuable thing to be done. A place to put legacy code that can be maintained (and supported...) by the folks interested. Pete > > Does this sound like something you'd be interested in helping out on? > If it is, perhaps the community can come together to solve the problem > here going forward. > > - Garrett > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From carlsonj@workingcode.com Tue Oct 27 10:50:22 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 n9RHoMTj011025 for ; Tue, 27 Oct 2009 10:50:22 -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 n9RHoJxs017767; Tue, 27 Oct 2009 10:50:20 -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 <0KS60000BPJVO900@brm-avmta-1.central.sun.com>; Tue, 27 Oct 2009 11:50:19 -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 <0KS600CEIPJT3XC0@brm-avmta-1.central.sun.com>; Tue, 27 Oct 2009 11:50:17 -0600 (MDT) Received: from relay42i.sun.com ([192.5.209.72]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9RHTegQ024562; Tue, 27 Oct 2009 17:50:17 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay42i.sun.com with ESMTP id BT-MMP-2205964; Tue, 27 Oct 2009 17:50:17 +0000 (Z) Received: from relay44i.sun.com (relay44i.sun.com [192.5.209.118]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-24550523; Tue, 27 Oct 2009 17:50:16 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-2059911; Tue, 27 Oct 2009 17:50:16 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n9RHoFDI014436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 13:50:15 -0400 (EDT) Date: Tue, 27 Oct 2009 13:50:14 -0400 From: James Carlson Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AE72CD3.9080207@sun.com> To: Peter Dennis - Sustaining Engineer Cc: Garrett.Damore@sun.com, PSARC-ext@sun.com Message-id: <4AE732D6.6020703@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 1181; Body=3 Fuz1=3 Fuz2=3 X-Antispam: No, score=-1.1/5.0, scanned in 0.261sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1938 Peter Dennis - Sustaining Engineer wrote: > Garrett D'Amore wrote: >> I've been contemplating setting up a community repo that could >> reintegrate some of the platform support that is being removed from ON >> proper, into a separate "legacy" consolidation, that would not be >> supported by Sun. > > I think that this would be an interesting and valuable thing to be done. > A place to put legacy code that can be maintained (and supported...) > by the folks interested. Interesting and valuable if it can be done. This isn't the first time such a thing has been discussed, and in the previous runs at the problem, the real issue is not the mechanics of setting up and maintaining a separate gate, but rather that 99 and 44/100ths of the effort is actually a legal review to determine what -- if anything at all -- can be released, and under what terms. If there isn't enough to maintain the code as the OS evolves, what's the chance that there's enough money to do a detailed legal analysis sufficient for release? Talk with Bonnie Corwin before going too far down this path. It's not as simple as you might imagine. It's not just that the copyrights on the code have to be checked; everything about it has to be checked. Were there contractors involved? What documentation was used to develop the code? Are there any legal agreements recorded for it? I know of several cases where we were unable to ship driver source code because a "proprietary" manual for the device was used in development. It didn't matter that some later version of the manual in question was released to the public. It didn't matter that all of the engineers on the project were regular Sun employees. It didn't matter that the device was long obsolete. When we had the vendor's document, it was marked confidential, and that was enough to cause the code to be withheld. -- James Carlson 42.703N 71.076W From Alan.Coopersmith@sun.com Tue Oct 27 11:08:13 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 n9RI8CaY012033 for ; Tue, 27 Oct 2009 11:08:12 -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 n9RI86jR008198 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Oct 2009 02:08:11 +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 <0KS60090DQDN6300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.com); Tue, 27 Oct 2009 11:08:11 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS6007XWQDMKZ30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.com); Tue, 27 Oct 2009 11:08:10 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9RI8AXb020208 for ; Tue, 27 Oct 2009 11:08:10 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KS600F00PWK0F00@fe-sfbay-10.sun.com> for PSARC-ext@Sun.com (ORCPT PSARC-ext@Sun.com); Tue, 27 Oct 2009 11:08:10 -0700 (PDT) Received: from [129.145.155.53] ([unknown] [129.145.155.53]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KS6005WEQDL1QE0@fe-sfbay-10.sun.com> for PSARC-ext@Sun.com (ORCPT PSARC-ext@Sun.com); Tue, 27 Oct 2009 11:08:10 -0700 (PDT) Date: Tue, 27 Oct 2009 11:08:09 -0700 From: Alan Coopersmith Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AE732D6.6020703@workingcode.com> Sender: Alan.Coopersmith@sun.com To: James Carlson Cc: Peter Dennis - Sustaining Engineer , Garrett.Damore@sun.com, PSARC-ext@sun.com Message-id: <4AE73709.1030605@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090720) Status: RO Content-Length: 1458 James Carlson wrote: > Peter Dennis - Sustaining Engineer wrote: >> Garrett D'Amore wrote: >>> I've been contemplating setting up a community repo that could >>> reintegrate some of the platform support that is being removed from ON >>> proper, into a separate "legacy" consolidation, that would not be >>> supported by Sun. >> I think that this would be an interesting and valuable thing to be done. >> A place to put legacy code that can be maintained (and supported...) >> by the folks interested. > > Interesting and valuable if it can be done. > > This isn't the first time such a thing has been discussed, and in the > previous runs at the problem, the real issue is not the mechanics of > setting up and maintaining a separate gate, but rather that 99 and > 44/100ths of the effort is actually a legal review to determine what -- > if anything at all -- can be released, and under what terms. Is that really an issue though for code that's already in the open ON gate, but which Sun no longer wants to support? Presumably all that legal review happened for the ON gate publication. (For the graphics drivers, sure, you're not going to see us release the source to the drivers that aren't already open, which means pretty much just cg6. But there's a lot of other devices on the old Ultra workstations besides just graphics.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Garrett.Damore@sun.com Tue Oct 27 11:11:39 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 n9RIBbhg012064 for ; Tue, 27 Oct 2009 11:11:37 -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 n9RIBVCp009829 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 28 Oct 2009 02:11:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KS60091BQJADK00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.com); Tue, 27 Oct 2009 11:11:34 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS6007G1QJ7KL40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.com); Tue, 27 Oct 2009 11:11:32 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9RIBVnP007645 for ; Tue, 27 Oct 2009 11:11:31 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KS600D00NRYL300@fe-sfbay-10.sun.com> for PSARC-ext@Sun.com (ORCPT PSARC-ext@Sun.com); Tue, 27 Oct 2009 11:11:31 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KS60058DQJ51QG0@fe-sfbay-10.sun.com> for PSARC-ext@Sun.com (ORCPT PSARC-ext@Sun.com); Tue, 27 Oct 2009 11:11:30 -0700 (PDT) Date: Tue, 27 Oct 2009 11:11:29 -0700 From: "Garrett D'Amore" Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AE732D6.6020703@workingcode.com> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Peter Dennis - Sustaining Engineer , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4AE737D1.9080102@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: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 2699 James Carlson wrote: > Peter Dennis - Sustaining Engineer wrote: > >> Garrett D'Amore wrote: >> >>> I've been contemplating setting up a community repo that could >>> reintegrate some of the platform support that is being removed from ON >>> proper, into a separate "legacy" consolidation, that would not be >>> supported by Sun. >>> >> I think that this would be an interesting and valuable thing to be done. >> A place to put legacy code that can be maintained (and supported...) >> by the folks interested. >> > > Interesting and valuable if it can be done. > > This isn't the first time such a thing has been discussed, and in the > previous runs at the problem, the real issue is not the mechanics of > setting up and maintaining a separate gate, but rather that 99 and > 44/100ths of the effort is actually a legal review to determine what -- > if anything at all -- can be released, and under what terms. If there > isn't enough to maintain the code as the OS evolves, what's the chance > that there's enough money to do a detailed legal analysis sufficient for > release? > I'm only talking about resurrecting the bits that are actually in the open or were in the open at some time. I don't want to get into questions about "legacy" that requires legal review. (In some cases the legacy could be "ported" from an alternate source -- such as NetBSD -- if a suitable Solaris version was never open sourced.) > Talk with Bonnie Corwin before going too far down this path. It's not > as simple as you might imagine. It's not just that the copyrights on > the code have to be checked; everything about it has to be checked. > Were there contractors involved? What documentation was used to develop > the code? Are there any legal agreements recorded for it? > Understood... I'm hoping to tread only in waters that don't have this kind of legal quagmire associated with them. > I know of several cases where we were unable to ship driver source code > because a "proprietary" manual for the device was used in development. > It didn't matter that some later version of the manual in question was > released to the public. It didn't matter that all of the engineers on > the project were regular Sun employees. It didn't matter that the > device was long obsolete. When we had the vendor's document, it was > marked confidential, and that was enough to cause the code to be withheld. > > Can you say "iprb" :-) Actually in "iprb"'s case, everything is ready to go now, we got all the legal approvals, but the Oracle acquisition has thrown a wrench into the works, and I can't submit the RTI until an *Oracle* lawyer approves it. - Garrett From carlsonj@workingcode.com Tue Oct 27 11:49:22 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 n9RInLvc012646 for ; Tue, 27 Oct 2009 11:49:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n9RInHOI056785; Tue, 27 Oct 2009 12:49:19 -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 <0KS600605SA7GQ00@brm-avmta-1.central.sun.com>; Tue, 27 Oct 2009 12:49:19 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS6004JFSA6EG10@brm-avmta-1.central.sun.com>; Tue, 27 Oct 2009 12:49:18 -0600 (MDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9RIZTjq002093; Tue, 27 Oct 2009 18:49:17 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay41i.sun.com with ESMTP id BT-MMP-1962019; Tue, 27 Oct 2009 18:49:17 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-24642113; Tue, 27 Oct 2009 18:49:17 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay4i.sun.com with ESMTP id BT-MMP-53026417; Tue, 27 Oct 2009 18:49:17 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n9RInE1w023536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 14:49:14 -0400 (EDT) Date: Tue, 27 Oct 2009 14:49:14 -0400 From: James Carlson Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AE73709.1030605@sun.com> To: Alan Coopersmith Cc: Peter Dennis - Sustaining Engineer , Garrett.Damore@sun.com, PSARC-ext@sun.com Message-id: <4AE740AA.1010704@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 1181; Body=4 Fuz1=4 Fuz2=4 X-Antispam: No, score=-0.7/5.0, scanned in 0.248sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> <4AE73709.1030605@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 2085 Alan Coopersmith wrote: > James Carlson wrote: >> Peter Dennis - Sustaining Engineer wrote: >>> Garrett D'Amore wrote: >>>> I've been contemplating setting up a community repo that could >>>> reintegrate some of the platform support that is being removed from ON >>>> proper, into a separate "legacy" consolidation, that would not be >>>> supported by Sun. >>> I think that this would be an interesting and valuable thing to be done. >>> A place to put legacy code that can be maintained (and supported...) >>> by the folks interested. >> Interesting and valuable if it can be done. >> >> This isn't the first time such a thing has been discussed, and in the >> previous runs at the problem, the real issue is not the mechanics of >> setting up and maintaining a separate gate, but rather that 99 and >> 44/100ths of the effort is actually a legal review to determine what -- >> if anything at all -- can be released, and under what terms. > > Is that really an issue though for code that's already in the open ON gate, > but which Sun no longer wants to support? Presumably all that legal review > happened for the ON gate publication. (For the graphics drivers, sure, > you're not going to see us release the source to the drivers that aren't > already open, which means pretty much just cg6. But there's a lot of other > devices on the old Ultra workstations besides just graphics.) > I'm puzzled. Why would you need it at all for code in the ON gate? Anything you want is right there in the hg history. If someone has got the time to commit to maintaining it, then bringing it back should be relatively easy -- easier than forking off to a separate gate. (Does the ON C-team care who is maintaining the code, as long as it's being maintained? I'd expect that they don't require someone to hold a Sun badge in order to claim that something is supported. Right?) Yes, it's all the other drivers that I'd be more concerned about. Without those, you've more or less got a fancy boat anchor. -- James Carlson 42.703N 71.076W From carlsonj@workingcode.com Tue Oct 27 11:57:41 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 n9RIveIp013208 for ; Tue, 27 Oct 2009 11:57:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9RIvcmg001455; Tue, 27 Oct 2009 11:57:39 -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 <0KS600H19SO33N00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Oct 2009 11:57:39 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KS600LOSSO2WGB0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Oct 2009 11:57:38 -0700 (PDT) Received: from relay11i.sun.com (ip121.net129179-4.block1.us.syntegra.com [129.179.4.121]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9RIoj4B011503; Tue, 27 Oct 2009 18:57:38 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay11i.sun.com with ESMTP id BT-MMP-5135152; Tue, 27 Oct 2009 18:57:37 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-33433539; Tue, 27 Oct 2009 18:57:37 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-173789; Tue, 27 Oct 2009 18:57:37 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n9RIvWBR024758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 14:57:33 -0400 (EDT) Date: Tue, 27 Oct 2009 14:57:32 -0400 From: James Carlson Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AE737D1.9080102@sun.com> To: Garrett.Damore@sun.com Cc: Peter Dennis - Sustaining Engineer , PSARC-ext@sun.com Message-id: <4AE7429C.5000102@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 1181; Body=3 Fuz1=3 Fuz2=3 References: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> <4AE737D1.9080102@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 2501 Garrett D'Amore wrote: > James Carlson wrote: >> This isn't the first time such a thing has been discussed, and in the >> previous runs at the problem, the real issue is not the mechanics of >> setting up and maintaining a separate gate, but rather that 99 and >> 44/100ths of the effort is actually a legal review to determine what -- >> if anything at all -- can be released, and under what terms. If there >> isn't enough to maintain the code as the OS evolves, what's the chance >> that there's enough money to do a detailed legal analysis sufficient for >> release? >> > > I'm only talking about resurrecting the bits that are actually in the > open or were in the open at some time. I don't want to get into > questions about "legacy" that requires legal review. (In some cases the > legacy could be "ported" from an alternate source -- such as NetBSD -- > if a suitable Solaris version was never open sourced.) Then color me baffled. The code isn't actually going away. It's still in the history. If someone can commit to supporting it, it seems like it ought to be a simple matter (community-wise, at least) to bring it right back. Sun doesn't get an automatic trump of what code is "supported," does it? The tougher matter is if you decide to retreat to your own shadow ON gate, then you'll have to deal with all the other projects that are no longer updating the code at issue, because it's "dead" to them. In other words, if the VM guys decide to rewrite their subsystem, you won't magically get updated Ultra I VM code. You'll be on your own. Code that's maintained and "live" in the ON gate is a shared burden; everyone integrating into ON is required to show how they've tested with it, where appropriate. Code that's hidden somewhere else is nobody's responsibility. To bring this back to ARC matters: you're talking about splitting a bunch of consolidation private interfaces across two consolidations. Maybe doable if you have a near-infinite supply of time and money, but probably fairly hard to keep up otherwise. > Can you say "iprb" :-) Actually in "iprb"'s case, everything is ready > to go now, we got all the legal approvals, but the Oracle acquisition > has thrown a wrench into the works, and I can't submit the RTI until an > *Oracle* lawyer approves it. I was actually thinking about the SPARC "se" driver. But, believe me, I don't want to know the details on "iprb." :-/ -- James Carlson 42.703N 71.076W From Garrett.Damore@sun.com Tue Oct 27 11:58:32 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 n9RIwWVO013220 for ; Tue, 27 Oct 2009 11:58:32 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n9RIwVaH001778 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 27 Oct 2009 11:58:32 -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 <0KS600H07SPG8R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@SUN.COM); Tue, 27 Oct 2009 11:58:28 -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 <0KS600LBLSPGX5C0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@SUN.COM); Tue, 27 Oct 2009 11:58:28 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9RIwSpB026535 for ; Tue, 27 Oct 2009 11:58:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KS600500SI2ZJ00@fe-sfbay-10.sun.com> for PSARC-ext@SUN.COM (ORCPT PSARC-ext@SUN.COM); Tue, 27 Oct 2009 11:58:28 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KS6006DXSPDT410@fe-sfbay-10.sun.com> for PSARC-ext@SUN.COM (ORCPT PSARC-ext@SUN.COM); Tue, 27 Oct 2009 11:58:26 -0700 (PDT) Date: Tue, 27 Oct 2009 11:58:25 -0700 From: "Garrett D'Amore" Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AE740AA.1010704@workingcode.com> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Alan Coopersmith , Peter Dennis - Sustaining Engineer , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4AE742D1.5090104@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: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> <4AE73709.1030605@sun.com> <4AE740AA.1010704@workingcode.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 4073 James Carlson wrote: > Alan Coopersmith wrote: > >> James Carlson wrote: >> >>> Peter Dennis - Sustaining Engineer wrote: >>> >>>> Garrett D'Amore wrote: >>>> >>>>> I've been contemplating setting up a community repo that could >>>>> reintegrate some of the platform support that is being removed from ON >>>>> proper, into a separate "legacy" consolidation, that would not be >>>>> supported by Sun. >>>>> >>>> I think that this would be an interesting and valuable thing to be done. >>>> A place to put legacy code that can be maintained (and supported...) >>>> by the folks interested. >>>> >>> Interesting and valuable if it can be done. >>> >>> This isn't the first time such a thing has been discussed, and in the >>> previous runs at the problem, the real issue is not the mechanics of >>> setting up and maintaining a separate gate, but rather that 99 and >>> 44/100ths of the effort is actually a legal review to determine what -- >>> if anything at all -- can be released, and under what terms. >>> >> Is that really an issue though for code that's already in the open ON gate, >> but which Sun no longer wants to support? Presumably all that legal review >> happened for the ON gate publication. (For the graphics drivers, sure, >> you're not going to see us release the source to the drivers that aren't >> already open, which means pretty much just cg6. But there's a lot of other >> devices on the old Ultra workstations besides just graphics.) >> >> > > I'm puzzled. Why would you need it at all for code in the ON gate? > Anything you want is right there in the hg history. If someone has got > the time to commit to maintaining it, then bringing it back should be > relatively easy -- easier than forking off to a separate gate. > Some one might want to *modify* those sources. Keep them updated so they work with current versions of ON, etc. The hg history is there, but it isn't "alive" in the sense that you don't make changes to it unless you're planning on integrating those changes into a delivering product. > (Does the ON C-team care who is maintaining the code, as long as it's > being maintained? I'd expect that they don't require someone to hold a > Sun badge in order to claim that something is supported. Right?) > Yes, they do care. Stuff in the gate has to be built, if you're not delivering it it requires exception lists, etc. There are implications for packaging, as well. The point here is that Sun has abandoned these things (and more will come) -- and with good reason in most cases. However, if the community wishes to separately keep the stuff alive, it should be possible to do so. Continuing to carry legacy/unsupported baggage in ON forever is not really a good solution. > Yes, it's all the other drivers that I'd be more concerned about. > Without those, you've more or less got a fancy boat anchor. > > Maybe. Tadpole SPARCLE support is one that could be revived pretty easily. I expect some of the other hardware drivers I'm looking at EOF'ing, and eventually platmod support (e.g. platmod stuff for SUNW,Ultra-2, the stp4020 driver, the bpp driver, later the audiocs driver, even SPARC delivery of the sdcard modules) all are things that are useful today, and will be useful going forward to *some* people who still want to run on older SPARC equipment that is no longer supported by Sun. The way I envision this is as a separate repo that you check out, *along* with a parallel copy of ON, and build. The build could look into ON for sources or headers which are still there (such as for "Consolidation Private" interfaces or to pick up common sources so that SPARC versions of them can be recompiled.) Yes, this would violate the PSARC rules for Consolidation Private, but I'm thinking of a project that operates well outside of ARC and Sun rules, as a community effort. (And you'd have to match "build numbers", so the community effort would have to keep the project in sync with ON.) -- Garrett From carlsonj@workingcode.com Tue Oct 27 12:18:28 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 n9RJISdb013572 for ; Tue, 27 Oct 2009 12:18:28 -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 n9RJIOHt010554; Tue, 27 Oct 2009 12:18:26 -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 <0KS600913TMPEG00@brm-avmta-1.central.sun.com>; Tue, 27 Oct 2009 13:18:25 -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 <0KS6004EPTMPEC40@brm-avmta-1.central.sun.com>; Tue, 27 Oct 2009 13:18:25 -0600 (MDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9RJGc8w023833; Tue, 27 Oct 2009 19:18:25 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-5134989; Tue, 27 Oct 2009 19:18:25 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-33468910; Tue, 27 Oct 2009 19:18:24 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-213256; Tue, 27 Oct 2009 19:18:24 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n9RJIMIR028260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 15:18:23 -0400 (EDT) Date: Tue, 27 Oct 2009 15:18:22 -0400 From: James Carlson Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AE742D1.5090104@sun.com> To: Garrett.Damore@sun.com Cc: Alan Coopersmith , Peter Dennis - Sustaining Engineer , PSARC-ext@sun.com Message-id: <4AE7477E.7020609@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 1181; Body=4 Fuz1=4 Fuz2=4 References: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> <4AE73709.1030605@sun.com> <4AE740AA.1010704@workingcode.com> <4AE742D1.5090104@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 4107 Garrett D'Amore wrote: > James Carlson wrote: >> I'm puzzled. Why would you need it at all for code in the ON gate? >> Anything you want is right there in the hg history. If someone has got >> the time to commit to maintaining it, then bringing it back should be >> relatively easy -- easier than forking off to a separate gate. >> > > Some one might want to *modify* those sources. Keep them updated so > they work with current versions of ON, etc. The hg history is there, > but it isn't "alive" in the sense that you don't make changes to it > unless you're planning on integrating those changes into a delivering > product. Indeed. And that's a fairly important issue about a consolidation. There has to be consensus (or at least a set of known rules) governing what it contains. >> (Does the ON C-team care who is maintaining the code, as long as it's >> being maintained? I'd expect that they don't require someone to hold a >> Sun badge in order to claim that something is supported. Right?) >> > > Yes, they do care. Stuff in the gate has to be built, if you're not > delivering it it requires exception lists, etc. There are implications > for packaging, as well. The point here is that Sun has abandoned these > things (and more will come) -- and with good reason in most cases. > However, if the community wishes to separately keep the stuff alive, it > should be possible to do so. > > Continuing to carry legacy/unsupported baggage in ON forever is not > really a good solution. This doesn't quite sound right to me. The way I look at it, there are contributors to ON, and those contributors are all held to the same standards: you have to test what you deliver and allow others to test with it. There isn't a requirement that you hold a Sun badge, just that you comply with the rules. It isn't or shouldn't be ON-versus-community, but rather ON-in-community. Before a "new" platform is delivered, the team doing that work carries a pretty heavy load, and has to keep up with ON's changes privately. Then they deliver, with the C-team's blessing, and it becomes everyone's problem to deal with it. Is that what we're really discussing here? That ON's content, at least in terms of platforms supported, is at Sun's discretion, and we need (or you'd like to have) a separate ON in order to meet non-Sun developer's needs? If so, then that's a sad result. Nobody's stopping you (or anyone else) from doing it, but it's the sort of fork that just gets expensive and divisive over time. Forking is technically as simple as setting up a public source repository. >> Yes, it's all the other drivers that I'd be more concerned about. >> Without those, you've more or less got a fancy boat anchor. >> >> > Maybe. Tadpole SPARCLE support is one that could be revived pretty > easily. I expect some of the other hardware drivers I'm looking at > EOF'ing, and eventually platmod support (e.g. platmod stuff for > SUNW,Ultra-2, the stp4020 driver, the bpp driver, later the audiocs > driver, even SPARC delivery of the sdcard modules) all are things that > are useful today, and will be useful going forward to *some* people who > still want to run on older SPARC equipment that is no longer supported > by Sun. > > The way I envision this is as a separate repo that you check out, > *along* with a parallel copy of ON, and build. The build could look > into ON for sources or headers which are still there (such as for > "Consolidation Private" interfaces or to pick up common sources so that > SPARC versions of them can be recompiled.) > > Yes, this would violate the PSARC rules for Consolidation Private, but > I'm thinking of a project that operates well outside of ARC and Sun > rules, as a community effort. (And you'd have to match "build numbers", > so the community effort would have to keep the project in sync with ON.) The rules aren't there to stop people who want to hurt themselves. :-/ Instead, they document what is known to work -- and what's known not to work. -- James Carlson 42.703N 71.076W From Garrett.Damore@sun.com Tue Oct 27 12:35:17 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 n9RJZHwr014045 for ; Tue, 27 Oct 2009 12:35:17 -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 n9RJZGSs016123 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 27 Oct 2009 12:35:17 -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 <0KS600B0TUES4X00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 13:35:16 -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 <0KS60044ZUEREG50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 13:35:15 -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 n9RJZFoE000423 for ; Tue, 27 Oct 2009 12:35:15 -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 <0KS600300U7ZVB00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 12:35:15 -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 <0KS600DROUEP5F50@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 27 Oct 2009 12:35:14 -0700 (PDT) Date: Tue, 27 Oct 2009 12:35:13 -0700 From: "Garrett D'Amore" Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AE7477E.7020609@workingcode.com> Sender: Garrett.Damore@sun.com To: James Carlson Cc: Alan Coopersmith , Peter Dennis - Sustaining Engineer , PSARC-ext@sun.com Reply-to: Garrett.Damore@sun.com Message-id: <4AE74B71.8050009@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: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> <4AE73709.1030605@sun.com> <4AE740AA.1010704@workingcode.com> <4AE742D1.5090104@sun.com> <4AE7477E.7020609@workingcode.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 6931 James Carlson wrote: > Garrett D'Amore wrote: > >> James Carlson wrote: >> >>> I'm puzzled. Why would you need it at all for code in the ON gate? >>> Anything you want is right there in the hg history. If someone has got >>> the time to commit to maintaining it, then bringing it back should be >>> relatively easy -- easier than forking off to a separate gate. >>> >>> >> Some one might want to *modify* those sources. Keep them updated so >> they work with current versions of ON, etc. The hg history is there, >> but it isn't "alive" in the sense that you don't make changes to it >> unless you're planning on integrating those changes into a delivering >> product. >> > > Indeed. And that's a fairly important issue about a consolidation. > There has to be consensus (or at least a set of known rules) governing > what it contains. > Yes. I think part of the problem here is that Sun decides the rules for ON, ultimately. We might like to pretend that this is a community project, but really there is still a benevolent dictator in the form of the C-Team, which is at present a Sun entity. That will be true until Sun hands over control of the gate, and allows non-Sun folks to both be RTI advocates, and to sit on the C-Team. Right now the C-Team runs almost completely subservient to Sun's P-teams (e.g. the OpenSolaris distro business team) -- hence Sun's business interests, and gives *no* real thought or consideration to what other folks in the community want, or to other distributions. (Well, to be fair, they might think about such things, but if there is no marketing demand for something, then it probably doesn't carry any weight in the decision.) (For example, UltraSPARC-I support that Rainer did, will probably never get reintroduced into ON. Why not? Because Sun doesn't want it, and can't support it.) >>> (Does the ON C-team care who is maintaining the code, as long as it's >>> being maintained? I'd expect that they don't require someone to hold a >>> Sun badge in order to claim that something is supported. Right?) >>> >>> >> Yes, they do care. Stuff in the gate has to be built, if you're not >> delivering it it requires exception lists, etc. There are implications >> for packaging, as well. The point here is that Sun has abandoned these >> things (and more will come) -- and with good reason in most cases. >> However, if the community wishes to separately keep the stuff alive, it >> should be possible to do so. >> >> Continuing to carry legacy/unsupported baggage in ON forever is not >> really a good solution. >> > > This doesn't quite sound right to me. > > The way I look at it, there are contributors to ON, and those > contributors are all held to the same standards: you have to test what > you deliver and allow others to test with it. There isn't a requirement > that you hold a Sun badge, just that you comply with the rules. It > isn't or shouldn't be ON-versus-community, but rather ON-in-community. > Its a nice utopia, but not representative of fact. Otherwise we'd have a community supplied version of a GLDv3 ce driver by now. Or the community supplied mfi driver. Or UltraSPARC I support. Sun's business interests trump all else *in practice*. > Before a "new" platform is delivered, the team doing that work carries a > pretty heavy load, and has to keep up with ON's changes privately. Then > they deliver, with the C-team's blessing, and it becomes everyone's > problem to deal with it. > Getting C-Team's blessings for projects that are not deemed appropriate to Sun is well nigh impossible. For example, you have to get Sustaining approval and commitment to provide long term support, perform a TOI, set up a bugster category, get tech pubs to agree to supply documentation, get commitment for any I18N or L10N resources, perform A11Y assessments, etc. You might also have to get supporting evidence from marketing, P-Team approval, etc. All of this is required before anyone can integrate a substantial new thing into ON. Many of those things are simply impossible to get if there is not some manager at Sun that is willing to support the effort. > Is that what we're really discussing here? That ON's content, at least > in terms of platforms supported, is at Sun's discretion, and we need (or > you'd like to have) a separate ON in order to meet non-Sun developer's > needs? > Yes, at the end of the day, that's exactly right. > If so, then that's a sad result. Nobody's stopping you (or anyone else) > from doing it, but it's the sort of fork that just gets expensive and > divisive over time. Forking is technically as simple as setting up a > public source repository. > It is sad, but maybe not as bad as you think. Its a bad result if we have to continue to build all the things that *someone* might want in ON, even though there isn't really enough resource to properly support (where support means continued testing, maintenance, etc.) it going forward. > >>> Yes, it's all the other drivers that I'd be more concerned about. >>> Without those, you've more or less got a fancy boat anchor. >>> >>> >>> >> Maybe. Tadpole SPARCLE support is one that could be revived pretty >> easily. I expect some of the other hardware drivers I'm looking at >> EOF'ing, and eventually platmod support (e.g. platmod stuff for >> SUNW,Ultra-2, the stp4020 driver, the bpp driver, later the audiocs >> driver, even SPARC delivery of the sdcard modules) all are things that >> are useful today, and will be useful going forward to *some* people who >> still want to run on older SPARC equipment that is no longer supported >> by Sun. >> >> The way I envision this is as a separate repo that you check out, >> *along* with a parallel copy of ON, and build. The build could look >> into ON for sources or headers which are still there (such as for >> "Consolidation Private" interfaces or to pick up common sources so that >> SPARC versions of them can be recompiled.) >> >> Yes, this would violate the PSARC rules for Consolidation Private, but >> I'm thinking of a project that operates well outside of ARC and Sun >> rules, as a community effort. (And you'd have to match "build numbers", >> so the community effort would have to keep the project in sync with ON.) >> > > The rules aren't there to stop people who want to hurt themselves. :-/ > > Instead, they document what is known to work -- and what's known not to > work. > I'm not sure I agree with the second half of that statement. The rules are there to minimize the likelihood of someone using an interface that might change incompatibly. For this particular usage, that's a known risk that the community can decide to take -- and Sun won't have to deal with any fall out from it, because this will be well outside of the "supported" configurations. - Garrett From carlsonj@workingcode.com Tue Oct 27 13:29:27 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 n9RKTRLq015301 for ; Tue, 27 Oct 2009 13:29:27 -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 n9RKTP5C026178; Tue, 27 Oct 2009 13:29:25 -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 <0KS60050TWX0P000@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Oct 2009 13:29:24 -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 <0KS600LAXWWZO730@nwk-avmta-1.sfbay.Sun.COM>; Tue, 27 Oct 2009 13:29:23 -0700 (PDT) Received: from relay13i.sun.com (ip123.net129179-4.block1.us.syntegra.com [129.179.4.123]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9RKTE2v014934; Tue, 27 Oct 2009 20:29:23 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay13i.sun.com with ESMTP id BT-MMP-5140808; Tue, 27 Oct 2009 20:29:02 +0000 (Z) Received: from relay13i.sun.com (relay13i.sun.com [129.179.4.123]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-33578251; Tue, 27 Oct 2009 20:29:02 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-1629057; Tue, 27 Oct 2009 20:29:01 +0000 (Z) Received: from [10.50.24.188] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id n9RKSteU008803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Oct 2009 16:28:55 -0400 (EDT) Date: Tue, 27 Oct 2009 16:28:54 -0400 From: James Carlson Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AE74B71.8050009@sun.com> To: Garrett.Damore@sun.com Cc: Alan Coopersmith , Peter Dennis - Sustaining Engineer , PSARC-ext@sun.com Message-id: <4AE75806.1010504@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: 0; Body=4 Fuz1=4 Fuz2=4 References: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> <4AE73709.1030605@sun.com> <4AE740AA.1010704@workingcode.com> <4AE742D1.5090104@sun.com> <4AE7477E.7020609@workingcode.com> <4AE74B71.8050009@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 941 Garrett D'Amore wrote: > I'm not sure I agree with the second half of that statement. The rules > are there to minimize the likelihood of someone using an interface that > might change incompatibly. For this particular usage, that's a known > risk that the community can decide to take -- and Sun won't have to deal > with any fall out from it, because this will be well outside of the > "supported" configurations. The fork-and-maintain scheme is a known quantity. It's been done in the past. And, in fact, if you go back and read some of the rationale behind the ARC, such things were actually the _reason_ that the ARC was formed -- to avoid the consequences of this choice. But I've said my piece, and you know what I think of the plan. It doesn't matter, of course, as setting up a new gate is trivial. It's what comes after that's hard. Good luck. -- James Carlson 42.703N 71.076W From Sebastien.Roy@sun.com Wed Nov 4 07:29:54 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 nA4FTslv001538 for ; Wed, 4 Nov 2009 07:29:54 -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 nA4FTsBd008230 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Nov 2009 07:29:54 -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 <0KSL0031BCDTVA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 04 Nov 2009 07:29:53 -0800 (PST) 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 <0KSL00LW3CDRSZ70@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 04 Nov 2009 07:29:52 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4FTpHs026677 for ; Wed, 04 Nov 2009 15:29:51 +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 <0KSL00100BQ0AS00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 04 Nov 2009 08:29:51 -0700 (MST) 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 <0KSL00K8MCDQ9FF0@mail-amer.sun.com>; Wed, 04 Nov 2009 08:29:50 -0700 (MST) Date: Wed, 04 Nov 2009 10:27:16 -0500 From: Sebastien Roy Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> Sender: Sebastien.Roy@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, Garrett.Damore@sun.com Message-id: <1257348436.26975.1.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: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> Status: RO Content-Length: 60 The dust around this case seems to have cleared. +1 -Seb From gdamore@sun.com Wed Nov 4 10:11: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 nA4IBc9o008618 for ; Wed, 4 Nov 2009 10:11:38 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA4IBYVe003047 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 4 Nov 2009 10:11:38 -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 <0KSL00MMLJVDR500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Nov 2009 10:11:37 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSL0087OJTPN190@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Nov 2009 10:10:37 -0800 (PST) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA4IAbcO029747 for ; Wed, 04 Nov 2009 10:10:37 -0800 (PST) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSL00000J7BW500@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Nov 2009 10:10:37 -0800 (PST) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSL00IGEJT83QJ0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 04 Nov 2009 10:10:21 -0800 (PST) Date: Wed, 04 Nov 2009 10:10:20 -0800 From: "Garrett D'Amore" Subject: PSARC 2009/580 EOF of stp4020 Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <4AF1C38C.9080009@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 User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 54 This case was approved at PSARC today. - Garrett From ro@techfak.uni-bielefeld.de Thu Nov 5 10:16:51 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 nA5IGpnZ020083 for ; Thu, 5 Nov 2009 10:16:51 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA5IGoGr023268; Thu, 5 Nov 2009 10:16:51 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSN00L0JES2PV00@nwk-avmta-2.sfbay.sun.com>; Thu, 05 Nov 2009 10:16:50 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSN00KF4ES1O710@nwk-avmta-2.sfbay.sun.com>; Thu, 05 Nov 2009 10:16:49 -0800 (PST) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA5I0rMd009174; Thu, 05 Nov 2009 18:16:49 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay15i.sun.com with ESMTP id BT-MMP-1661097; Thu, 05 Nov 2009 18:16:49 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-53218245; Thu, 05 Nov 2009 18:16:48 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay1i.sun.com with ESMTP id BT-MMP-10631493; Thu, 05 Nov 2009 18:16:48 +0000 (Z) Received: from asien.TechFak.Uni-Bielefeld.DE (asien.TechFak.Uni-Bielefeld.DE [129.70.131.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTPS id E5CE8E8; Thu, 05 Nov 2009 19:16:47 +0100 (CET) Date: Thu, 05 Nov 2009 19:16:47 +0100 From: ro@techfak.uni-bielefeld.de Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: "Garrett D'Amore"'s message of "Tue, 27 Oct 2009 12:35:13 -0700" To: Garrett.Damore@sun.com Cc: James Carlson , PSARC-ext@sun.com, Alan Coopersmith Message-id: MIME-version: 1.0 X-Mailer: Gnus v5.6.44/Emacs 19.34 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== Lines: 40 References: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> <4AE73709.1030605@sun.com> <4AE740AA.1010704@workingcode.com> <4AE742D1.5090104@sun.com> <4AE7477E.7020609@workingcode.com> <4AE74B71.8050009@sun.com> Status: RO Content-Length: 2160 "Garrett D'Amore" writes: > Yes. I think part of the problem here is that Sun decides the rules for > ON, ultimately. We might like to pretend that this is a community > project, but really there is still a benevolent dictator in the form of > the C-Team, which is at present a Sun entity. > > That will be true until Sun hands over control of the gate, and allows > non-Sun folks to both be RTI advocates, and to sit on the C-Team. Right > now the C-Team runs almost completely subservient to Sun's P-teams (e.g. > the OpenSolaris distro business team) -- hence Sun's business interests, > and gives *no* real thought or consideration to what other folks in the > community want, or to other distributions. (Well, to be fair, they > might think about such things, but if there is no marketing demand for > something, then it probably doesn't carry any weight in the decision.) > > (For example, UltraSPARC-I support that Rainer did, will probably never > get reintroduced into ON. Why not? Because Sun doesn't want it, and > can't support it.) I think there's the problem: you assume that only things that Sun can and will support can live in ON. But this assumption is not necessarily true: when I discussed UltraSPARC-I revival with Stephen Hahn 2 or 3 years ago, he seems to have been in contact with Sun Legal about the wording of a message from (then) ufsboot/inetboot about US-I being not supported. With that proviso, it seems that the revival code could have gone in. Obviously, we have to keep the code in ON building, but why should the support burden fall only on Sun? This way we could avoid an expensive fork (especially in this case where the changes are trivial: just a few lines of code and a couple of symlinks). Allowing something like this would be an important sign of goodwill by Sun to the community. Otherwise, this whole thread makes it obvious that much of this talk about a community is just that: talk, contradicted by actions. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From Garrett.Damore@sun.com Thu Nov 5 10:35:53 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 nA5IZr5J020317 for ; Thu, 5 Nov 2009 10:35:53 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nA5IZSbi019546 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 5 Nov 2009 11:35:52 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSN00607FN27Q00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 05 Nov 2009 10:35:26 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSN00HPVFN1F060@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 05 Nov 2009 10:35:26 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA5IZPFp024247 for ; Thu, 05 Nov 2009 10:35:25 -0800 (PST) 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 <0KSN00600FHGCB00@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 05 Nov 2009 10:35:25 -0800 (PST) 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 <0KSN00AN2FN0IK60@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 05 Nov 2009 10:35:24 -0800 (PST) Date: Thu, 05 Nov 2009 10:35:23 -0800 From: "Garrett D'Amore" Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: Sender: Garrett.Damore@sun.com To: ro@techfak.uni-bielefeld.de Cc: James Carlson , PSARC-ext@sun.com, Alan Coopersmith Reply-to: Garrett.Damore@sun.com Message-id: <4AF31AEB.90705@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: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> <4AE73709.1030605@sun.com> <4AE740AA.1010704@workingcode.com> <4AE742D1.5090104@sun.com> <4AE7477E.7020609@workingcode.com> <4AE74B71.8050009@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090909) Status: RO Content-Length: 2862 ro@techfak.uni-bielefeld.de wrote: > "Garrett D'Amore" writes: > > >> Yes. I think part of the problem here is that Sun decides the rules for >> ON, ultimately. We might like to pretend that this is a community >> project, but really there is still a benevolent dictator in the form of >> the C-Team, which is at present a Sun entity. >> >> That will be true until Sun hands over control of the gate, and allows >> non-Sun folks to both be RTI advocates, and to sit on the C-Team. Right >> now the C-Team runs almost completely subservient to Sun's P-teams (e.g. >> the OpenSolaris distro business team) -- hence Sun's business interests, >> and gives *no* real thought or consideration to what other folks in the >> community want, or to other distributions. (Well, to be fair, they >> might think about such things, but if there is no marketing demand for >> something, then it probably doesn't carry any weight in the decision.) >> >> (For example, UltraSPARC-I support that Rainer did, will probably never >> get reintroduced into ON. Why not? Because Sun doesn't want it, and >> can't support it.) >> > > I think there's the problem: you assume that only things that Sun can and > will support can live in ON. That is the precedent to date. > But this assumption is not necessarily true: > when I discussed UltraSPARC-I revival with Stephen Hahn 2 or 3 years ago, > he seems to have been in contact with Sun Legal about the wording of a > message from (then) ufsboot/inetboot about US-I being not supported. With > that proviso, it seems that the revival code could have gone in. > Obviously, we have to keep the code in ON building, but why should the > support burden fall only on Sun? This way we could avoid an expensive fork > (especially in this case where the changes are trivial: just a few lines of > code and a couple of symlinks). > > Allowing something like this would be an important sign of goodwill by Sun > to the community. Otherwise, this whole thread makes it obvious that much > of this talk about a community is just that: talk, contradicted by actions. > I'm not going to disagree with your sentiments... but to date there are many situations where Sun's business interests trump those of the community. As long as the ON consolidation is staffed entirely by folks who owe allegiance to Sun (or its successors), then it will be hard to effect any change that allows the community to integrate "community sustained" sources. At the end of the day, its not clear to me that this is really that great of a problem. Its perfectly reasonable to create other consolidation with non-Sun sources (or with sources that Sun doesn't approve of) that live side by side with ON. There is no intrinsic need that legacy hardware support stuff has to be in ON. - Garrett From ro@techfak.uni-bielefeld.de Fri Nov 6 09:27:41 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 nA6HRem7026296 for ; Fri, 6 Nov 2009 09:27:40 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA6HRZMG007204; Fri, 6 Nov 2009 17:27:35 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 <0KSP00E0175Y8000@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Nov 2009 09:27:34 -0800 (PST) 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 <0KSP00JKZ75Y4X90@nwk-avmta-1.sfbay.Sun.COM>; Fri, 06 Nov 2009 09:27:34 -0800 (PST) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA6HIx2J017510; Fri, 06 Nov 2009 17:27:33 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay44i.sun.com with ESMTP id BT-MMP-993609; Fri, 06 Nov 2009 17:27:33 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-42487197; Fri, 06 Nov 2009 17:27:33 +0000 (Z) Received: from smarthost.TechFak.Uni-Bielefeld.DE ([129.70.137.17] [129.70.137.17]) by relay4i.sun.com with ESMTP id BT-MMP-16377591; Fri, 06 Nov 2009 17:27:32 +0000 (Z) Received: from komagatake.TechFak.Uni-Bielefeld.DE (komagatake.TechFak.Uni-Bielefeld.DE [129.70.137.126]) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTP id 35515DD; Fri, 06 Nov 2009 18:27:32 +0100 (CET) Received: (from ro@localhost) by komagatake.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) id nA6HRWm17217; Fri, 06 Nov 2009 18:27:32 +0100 (MET) Date: Fri, 06 Nov 2009 18:27:30 +0100 (MET) From: Rainer Orth Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <4AF31AEB.90705@sun.com> To: Garrett.Damore@sun.com Cc: James Carlson , PSARC-ext@sun.com, Alan Coopersmith Message-id: <19188.23682.222742.534612@komagatake.TechFak.Uni-Bielefeld.DE> MIME-version: 1.0 X-Mailer: VM 6.62 under Emacs 19.34.1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=-2.6/5.0, scanned in 0.227sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> <4AE73709.1030605@sun.com> <4AE740AA.1010704@workingcode.com> <4AE742D1.5090104@sun.com> <4AE7477E.7020609@workingcode.com> <4AE74B71.8050009@sun.com> <4AF31AEB.90705@sun.com> Status: RO Content-Length: 3599 Garrett D'Amore writes: > > I think there's the problem: you assume that only things that Sun can and > > will support can live in ON. > > That is the precedent to date. True, but in my opinion that's the fundamental problem here. In another open source project I know well (GCC), it works completely differently: SVN trunk contains all the code that is deemed appropriate by the release process and the maintainers. Even though many of them are payed by the likes of Redhat, Suse, Google, Intel and AMD, they use the project's rules for deciding what goes into the tree. Since vendors often want to ship modified versions of the code, either with patches that are not yet ready for mainline, or completely inappropriate for trunk, they maintain vendor branches where all this happens. At least ON is different here: only Sun business and support interests dictate what's allowed into the hg repository, no matter what the community thinks is appropriate. I'm certainly not opposed to the ARC process and strict requirements for code review and testing here, quite the contrary: in my opinion, those are the strong points of the OpenSolaris project. But Sun dictatorship doesn't seem right for a community project here: this is quite different from a benevolent dictator who follows documented though strict community rules for what can go into the tree. In my opinion, this is a central OpenSolaris governance issue. Unfortunately, Michelle Olson couldn't come to OSDevCon '09 in Dresden last week as planned, otherwise I'd have liked to raise the issue with the OGB there. > I'm not going to disagree with your sentiments... but to date there are > many situations where Sun's business interests trump those of the > community. As long as the ON consolidation is staffed entirely by folks > who owe allegiance to Sun (or its successors), then it will be hard to > effect any change that allows the community to integrate "community > sustained" sources. The GCC example makes it abundantly clear that this needn't be the case: while the core maintainers are paid by various companies, as long as decisions are made for trunk, they are based on community rules, even if they are contrary to those of the company paying their paychecks. This is of course different for the vendor branches. There are also precedents against the strict prohibition of support for unsupported hardware in commercial distributions: e.g. in the Tru64 V5.1 (or 5.0, I don't remember exactly) days, several older Alpha machines were declared unsupported by Compaq, yet the code stayed in the distribution and continued to work. You only couldn't call support if something didn't work as expected. > At the end of the day, its not clear to me that this is really that > great of a problem. Its perfectly reasonable to create other > consolidation with non-Sun sources (or with sources that Sun doesn't > approve of) that live side by side with ON. There is no intrinsic need > that legacy hardware support stuff has to be in ON. It depends on where the necessary changes live: if they are just a couple of additional drivers, you may be right, but if there are changes to shared code, it requires a full-fledge fork of ON. Say all OpenSolaris distributors but Sun want this support, so they have to maintain that fork together instead of putting the burden on Sun to either declare the machines unsupported or not ship the code in their branch. Rainer ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University From Sebastien.Roy@sun.com Fri Nov 6 09:52:22 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 nA6HqL4v027189 for ; Fri, 6 Nov 2009 09:52:21 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA6HqGGK022352 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 6 Nov 2009 17:52:20 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSP00A0F8B6BC00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 06 Nov 2009 10:52:18 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSP00MGL8B69320@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 06 Nov 2009 10:52:18 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA6HqIJC026634 for ; Fri, 06 Nov 2009 17:52:18 +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 <0KSP00500740AF00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 06 Nov 2009 10:52:18 -0700 (MST) Received: from [192.168.1.5] ([unknown] [173.76.16.34]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSP00BXS8ARU140@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 06 Nov 2009 10:52:04 -0700 (MST) Date: Fri, 06 Nov 2009 12:52:02 -0500 From: Sebastien Roy Subject: Re: EOF of stp4020 [PSARC/2009/580 FastTrack timeout 10/31/2009] In-reply-to: <19188.23682.222742.534612@komagatake.TechFak.Uni-Bielefeld.DE> Sender: Sebastien.Roy@sun.com To: Rainer Orth Cc: Garrett.Damore@sun.com, PSARC-ext@sun.com, Alan Coopersmith Message-id: <1257529922.23488.47.camel@seb> 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: <200910250326.n9P3QOtB001346@sac.sfbay.sun.com> <4AE7271A.1020700@sun.com> <19175.10780.853992.969042@komagatake.TechFak.Uni-Bielefeld.DE> <4AE72BA0.5020308@sun.com> <4AE72CD3.9080207@sun.com> <4AE732D6.6020703@workingcode.com> <4AE73709.1030605@sun.com> <4AE740AA.1010704@workingcode.com> <4AE742D1.5090104@sun.com> <4AE7477E.7020609@workingcode.com> <4AE74B71.8050009@sun.com> <4AF31AEB.90705@sun.com> <19188.23682.222742.534612@komagatake.TechFak.Uni-Bielefeld.DE> Status: RO Content-Length: 140 Folks, this is off-topic at this point. There is a separate thread on arc-discuss if you want to continue this line of discussion. -Seb