From sacadmin Tue May 13 15:11:09 2008 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4DMB9Pe008987; Tue, 13 May 2008 15:11:09 -0700 (PDT) Received: (from rm129958@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m4DMB9xg008983; Tue, 13 May 2008 15:11:09 -0700 (PDT) Date: Tue, 13 May 2008 15:11:09 -0700 (PDT) From: Richard Jr Matthews Message-Id: <200805132211.m4DMB9xg008983@sac.sfbay.sun.com> To: LSARC-record@sac.sfbay.sun.com Subject: links [LSARC/2008/322 FastTrack timeout 05/20/2008] Status: RO Content-Length: 539 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: links 1.2. Name of Document Author/Supplier: Author: Reid Kaufmann 1.3 Date of This Document: 13 May, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sacadmin Tue May 13 15:35:49 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4DMZnxF010532 for ; Tue, 13 May 2008 15:35:49 -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 m4DMZl94008757 for <@sunmail2sca.sfbay.sun.com:LSARC@sun.com>; Tue, 13 May 2008 16:35:48 -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 <0K0T00215W3NVQ00@nwk-avmta-1.sfbay.Sun.COM> for LSARC@sun.com (ORCPT LSARC@sun.com); Tue, 13 May 2008 15:35:47 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K0T0061JW3MUOB0@nwk-avmta-1.sfbay.Sun.COM> for LSARC@sun.com (ORCPT LSARC@sun.com); Tue, 13 May 2008 15:35:46 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4DMZkEF023437 for ; Tue, 13 May 2008 22:35:46 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K0T00L01VCMDN00@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM) for LSARC@sun.com (ORCPT LSARC@sun.com); Tue, 13 May 2008 16:35:46 -0600 (MDT) Received: from [129.152.9.14] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K0T00D38W36Y8C0@mail-amer.sun.com> for LSARC@sun.com (ORCPT LSARC@sun.com); Tue, 13 May 2008 16:35:34 -0600 (MDT) Date: Tue, 13 May 2008 17:35:25 -0500 From: Rick Matthews Subject: LSARC/2008/322 - links [FastTrack timeout 05/20/2008] Sender: Richard.Matthews@sun.com To: LSARC@sun.com Reply-to: Richard.Matthews@sun.com Message-id: <482A17AD.9000305@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 15073 I am sponsoring the following FastTrack for Reid Kaufmann. The project requests a minor release binding. All submitted materials are in the case directory. ---- 1.0 Project Information 1.1 Name of project/component: links 1.2 Author of document: Reid Kaufmann 2.0 Project Summary 2.1 Project Description Links is a web-browser with a text-based interface. In environments where X forwarding is not available or practical, it is of great utility. The purpose of this proposal is to include Links in the SFW consolidation as part of general effort to make more open source software more available in Solaris. Links' only requirements are a POSIX environment, OpenSSL (for full https functionality), and libgcc-3.3. Links is a simple standalone binary with few library dependencies. 2.2 Release binding What is is the release binding? (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/) [ ] Major [x] Minor [ ] Patch or Micro [ ] Unknown -- ARC review required 2.3 Originating Community 2.3.1 Community Name: links.sourceforge.net 2.3.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [ ] Contributor [x] Monitoring Will the project team work with the upstream community to resolve architectural issues of interest to Sun? [x] Yes, but no changes are expected -- the program is simple [ ] No - briefly explain Will we or are we forking from the community? [ ] Yes - ARC review required prior to forking [x] No 3.0 Technical Description 3.1 Installation & Sharable 3.1.1S Solaris Installation - section only required for Solaris Software (see http://opensolaris.org/os/community/arc/policies/install-locations/ for details) Does this project follow the Install Locations best practice? [x] Yes [ ] No - ARC review required Does this project install into /usr under [sbin|bin|lib|include|man|share]? [x] Yes [ ] No or N/A Does this project install into /opt? [ ] Yes - explain below [x] No or N/A Does this project install into a different directory structure? [ ] Yes - ARC review required [x] No or N/A Do any of the components of this project conflict with anything under /usr? (see http://opensolaris.org/os/community/arc/caselog/2007/047/ for details) [ ] Yes - explain below [x] No If conflicts exist then will this project install under /usr/gnu? [ ] Yes [ ] No - ARC review required [x] N/A Is this project installing into /usr/sfw? [ ] Yes - ARC review required [x] No 3.1.1W Windows Installation - section only required for Windows Software (see http://sac.sfbay/WSARC/2002/494 for details) SECTION N/A 3.1.2 Share and Sharable Does the module include any components that are used or shared by other projects? [ ] Yes [x] No If yes are these components packaged to be shared with the other FOSS? [ ] Yes [ ] No - ARC review required Are these components already in the Solaris WOS? [ ] Yes [ ] No - continue with next section If yes are these newer versions being delivered? [ ] Yes [ ] No - ARC review required If yes are the newer versions replacing the existing versions? [ ] Yes [ ] No - ARC review required 3.2 Libraries: SECTION N/A -- no libraries being delivered 3.3 Services and the /etc Directory (see http://opensolaris.org/os/community/arc/policies/SMF-policy/) Does the project integrate anything into /etc/init.d or /etc/rc?.d? [ ] Yes - ARC review required [x] No Does the project integrate any new entries into /etc/inittab or /etc/inetd.conf? [ ] Yes - ARC review required [x] No Does the project integrate any private non-public files into /etc/default or /etc/ configuration files? [ ] Yes - ARC review required [x] No Does the service manifests method context grant rights above that of the noaccess user and basic privilege set? [ ] Yes - ARC review required [x] No 3.4 Security 3.4.1 Secure By Default: SECTION N/A -- no network services (see http://opensolaris.org/os/community/arc/policies/secure-by-default/ for details) (see http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ for details) (see parts of http://opensolaris.org/os/community/arc/policies/SMF-policy/ for addtional details) Are network services enabled by default? [ ] Yes - ARC review required [ ] No [x] N/A Are network services automatically enabled by the project during installation? [ ] Yes - ARC review required [ ] No [x] N/A Are inbound network communications denied by default? [ ] Yes [ ] No - ARC review required [x] N/A Is inbound data checked to prevent content-based attacks? [ ] Yes [ ] No - ARC review required [x] N/A Is the outbound receiver authenticated? [ ] Yes [ ] No - ARC review required [x] N/A Is the receiver authenticated prior to receiving any sensitive outbound communication? [ ] Yes [ ] No - ARC review required [x] N/A 3.4.2 Authorization (see http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ and http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ for details) Are there any setuid/setgid privileged binaries in the project? [ ] Yes - ARC review required [x] No - continue with next section If yes then are the setuid/setgid privileges handled by the use of roles? [ ] Yes [ ] No - ARC review required 3.4.3 Auditing (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details) (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details) Does this component contain administrative or security enforcing software? [ ] Yes - ARC review required [x] No - continue to next section (see http://opensolaris.org/os/community/arc/caselog/2003/397 for details) Do the components create audit logs detailing what took place including what event took place, who was involved, when the event took place? [ ] Yes - ARC contract and Audit project team review required [ ] No - ARC review required 3.4.4 Authentication (see http://opensolaris.org/os/community/arc/policies/PAM/) Do the components contain any authentication code? [ ] Yes [x] No - continue to next section If yes do the components use PAM (plugable authentication modules) for authentication? [ ] Yes [ ] No - ARC review required If yes is a single PAM session maintained during authentication? [ ] Yes [ ] No - ARC review required If yes are the components sufficiently privileged to allow the requested operations (authentication, password change, process credential manipulation, audit state initialization)? [ ] Yes - briefly describe below [ ] No - ARC review required 3.4.5 Passwords (see http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ and http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ for details) Do any of the components for the project deal with passwords? [ ] Yes [x] No - continue to next section If yes are these passwords entered via the CLI or environment? [ ] Yes - ARC review required [ ] No Are passwords stored within the file system for the component? [ ] Yes [ ] No - continue to next section If yes are the permissions on the file such to protect exposing the password(s)? [ ] Yes [ ] No - ARC review required 3.4.6 General Security Questions (see http://opensolaris.org/os/community/arc/bestpractices/security-questions/ for details) Do the components use standard network protocols? [x] Yes [ ] No - ARC review required Do network services for the project make decisions based upon user, host or service identities? [ ] Yes - explain below [x] No [ ] N/A Do the components make use of secret information during authentication and/or authorization? [x] Yes - explain below [ ] No [ ] N/A The project uses OpenSSL. 3.5 Networking Do the components access the network? [x] Yes [ ] No - continue to next section If yes do the components support IPv6? [ ] Yes [x] No - ARC review required 3.6 Core Solaris Components Do the components of this project compete with or duplicate core Solaris components? [ ] Yes - ARC review required [x] No Examples of Core Solaris Components include but are not limited to: Secure By Default Authorizations PAM -- Plugable Authentication Module Privilege PRM -- Process Rights Management -- Privilege Audit xVm -- Virtualization zones / Solaris Containers PRM -- Process Rights Management RBAC -- Role Based Access Control TX / Trusted Extensions ZFS SMF -- Service Management Facility FMA -- Fault Management Architecture SCF -- Smart Card Facility IPsec 4.0 Interfaces (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) 4.1 Exported Interfaces Interface Name Classification Comments --------------------------- ------------------- --------------------------- SUNWlinks Uncommitted Package Name /usr/bin/links Uncommitted Executable location /usr/share/man/man1/links.1 Uncommitted Man page links Uncommitted Commandline syntax 4.2 Imported Interfaces Interface Name Classification Comments --------------------------- -------------------- -------------------------- OpenSSL Contracted Unstable PSARC/2003/500/contracts/contract-19 Note--Remove all Wizzy, Bang, Slushy, Cherry Flavor, Stingy references above as these are simply examples Brief Interface Classifications - See Appendix C for definitions Volatile - use check list for approval Uncommitted - ARC review might be required, seek committee member advice package names do not require further review Committed - ARC review required Project Private - no review required, just documentat in table Contracted (interface modifier) - further review required Appendix A - References 1. Solaris Installation Locations Policy http://opensolaris.org/os/community/arc/policies/install-locations/ 2. /usr/gnu Installation ARC case http://opensolaris.org/os/community/arc/caselog/2007/047/ 3. Secure By Default Policy http://opensolaris.org/os/community/arc/policies/secure-by-default/ 4. Network Install Time Securityuy Policy http://www.opensolaris.org/os/community/arc/policies/NITS-policy/ 5. Adding RBAC Authorizations Policy http://opensolaris.org/os/community/arc/bestpractices/rbac-auths/ 6. When to use setuid -vs- RBAC roles and profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ and 7. Building RBAC Rights Profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ 8. Solaris Audit Policy http://opensolaris.org/os/community/arc/policies/audit-policy/ 9. Security questionaire http://opensolaris.org/os/community/arc/bestpractices/security-questions/ 10. Interface Taxonomy http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ 11. Plugable Authentication Modules -- PAM http://opensolaris.org/os/community/arc/policies/PAM/ 12. Reusable Passwords In Command Line Arguments and Environment Variables http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ 13. Storing Reusable Passwords on a Filesystem http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ 14. Release Taxonomy http://opensolaris.org/os/community/arc/policies/release-taxonomy/ 15. Service Management Facility (SMF) usage http://opensolaris.org/os/community/arc/policies/SMF-policy/ Appendix B - Suggested case materials 1. man pages 2. SMF manifests 3. links to contracts Appendix C - Definitions Submitter an agent responsible for creation of an ARC project along with the materials describing that project. Owner the ARC agent responsible for shepherding the case through review and ensuring a formal opinion is written where required. Maintainer an agent responsible for releasing new versions of a program, typically the "main" contributor or person incharge of making Architectural decisions for the project Contributor an agent who make contributions to a project, typically has a voice in making Architectural decisions for the project Monitoring an agent who is only following the changes made in the community and has no Architectural input into the project Volatile* interfaces that are very fluid and typically follow the originating community. Typically these interfaces can not be imported by other projects. Uncommitted* interfaces that are still evolving but will most likely be present from release to release. Committed* interfaces that are stable and with Sun guaranteeing some level of compatibility from release to release. Project Private* interfaces that are exposed only to or intended to be used only by the project being reviewed. These interfaces can not be imported by other projects. Not-An-Interface* components that are not interfaces. Contracted* (interface modifier) - ARC review of Contract required interfaces that do not allow another project to import can be *Note: see http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- From sacadmin Wed May 14 00:20:54 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4E7Krl6023305 for ; Wed, 14 May 2008 00:20:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m4E7KplY057145; Wed, 14 May 2008 01:20:53 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K0U00101KESDN00@nwk-avmta-2.sfbay.sun.com>; Wed, 14 May 2008 00:20:52 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K0U0096DKESNDE0@nwk-avmta-2.sfbay.sun.com>; Wed, 14 May 2008 00:20:52 -0700 (PDT) Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4E7KpCv013005; Wed, 14 May 2008 07:20:52 +0000 (GMT) Received: from buye.red.iplanet.com (buye [192.18.65.224]) by dm-usca15-11.red.iplanet.com (8.11.7p1+Sun/8.11.7/IPLANET,v1.2) with ESMTP id m4E7Kp210628; Wed, 14 May 2008 00:20:51 -0700 (PDT) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m4E7KpSt012815; Wed, 14 May 2008 00:20:51 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m4E7KpHH012814; Wed, 14 May 2008 00:20:51 -0700 (PDT) Date: Wed, 14 May 2008 00:20:51 -0700 From: Jyri Virkki Subject: Re: LSARC/2008/322 - links [FastTrack timeout 05/20/2008] In-reply-to: <482A17AD.9000305@Sun.COM> To: Rick Matthews Cc: LSARC@sun.com Message-id: <20080514072051.GK11914@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <482A17AD.9000305@Sun.COM> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 903 Rick Matthews wrote: > > 4.1 Exported Interfaces Would be a nit, but since the exported interfaces is ultimately one of the most key sections for a case, it really is important to communicate those interfaces clearly. Between the word wrap and the misaligned columns I find the following almost entirely unreadable. Please put 2 minutes into making it readable please... > Interface Name Classification Comments > --------------------------- ------------------- > --------------------------- > SUNWlinks Uncommitted Package Name > /usr/bin/links Uncommitted > Executable location > /usr/share/man/man1/links.1 Uncommitted Man page > links > Uncommitted Commandline syntax -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From sacadmin Wed May 14 02:21:28 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4E9LRTM025065 for ; Wed, 14 May 2008 02:21:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m4E9L1TC008824; Wed, 14 May 2008 10:21:25 +0100 (BST) 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 <0K0U0010DPZM8600@brm-avmta-1.central.sun.com>; Wed, 14 May 2008 03:21:22 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K0U00MKTPZLR420@brm-avmta-1.central.sun.com>; Wed, 14 May 2008 03:21:21 -0600 (MDT) Received: from snowdog (snowdog.SFBay.Sun.COM [129.146.228.213]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m4E9LLWX771336; Wed, 14 May 2008 02:21:21 -0700 (PDT) Date: Wed, 14 May 2008 02:25:02 -0700 From: Dan Price Subject: Re: LSARC/2008/322 - links [FastTrack timeout 05/20/2008] In-reply-to: <482A17AD.9000305@Sun.COM> To: Rick Matthews Cc: LSARC@sun.com Message-id: <20080514092502.GA10582@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <482A17AD.9000305@Sun.COM> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1608 On Tue 13 May 2008 at 05:35PM, Rick Matthews wrote: > I am sponsoring the following FastTrack for Reid Kaufmann. The project > requests > a minor release binding. All submitted materials are in the case directory. > > ---- > 1.0 Project Information > 1.1 Name of project/component: links > > 1.2 Author of document: Reid Kaufmann > > 2.0 Project Summary > 2.1 Project Description > > Links is a web-browser with a text-based interface. In > environments where X forwarding is not available or practical, it > is of great utility. The purpose of this proposal is to include > Links in the SFW consolidation as part of general effort to make > more open source software more available in Solaris. Rick, Reid, Was any consideration given to doing 'elinks' instead? According to: http://elinks.or.cz/history.html "The original Links was written by Mikulas Patocka. Links 0.9x is still maintained by Mikulas, but from 0.98 on, no new features are accepted, only bug-fixes and translation updates." The links homepage seems to agree with this statement. While links is of high utility, it seems like elinks has simply addded more useful stuff. I can vouch that elinks is quite nice to use and compiles easily and works well under Solaris. 256-color xterms (such as gnome-terminal) even work well. IPv6 seems to be supported. CSS is supported to some degree, etc. I don't mean to offend, just to point out that we might get more functionality for our engineering dollar with elinks. -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From sacadmin Wed May 14 02:25:55 2008 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 m4E9Pt6q025098 for ; Wed, 14 May 2008 02:25:55 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m4E9Pscu017729; Wed, 14 May 2008 02:25:55 -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 <0K0U0060BQ74KG00@nwk-avmta-2.sfbay.sun.com>; Wed, 14 May 2008 02:25:52 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K0U005ZSQ74GX00@nwk-avmta-2.sfbay.sun.com>; Wed, 14 May 2008 02:25:52 -0700 (PDT) Received: from snowdog (snowdog.SFBay.Sun.COM [129.146.228.213]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m4E9PqGE771527; Wed, 14 May 2008 02:25:52 -0700 (PDT) Date: Wed, 14 May 2008 02:29:32 -0700 From: Dan Price Subject: Re: LSARC/2008/322 - links [FastTrack timeout 05/20/2008] In-reply-to: <20080514092502.GA10582@eng.sun.com> To: Rick Matthews Cc: LSARC@sun.com Message-id: <20080514092932.GB10582@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <482A17AD.9000305@Sun.COM> <20080514092502.GA10582@eng.sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 613 On Wed 14 May 2008 at 02:25AM, Dan Price wrote: > Rick, Reid, > > Was any consideration given to doing 'elinks' instead? > > According to: http://elinks.or.cz/history.html > > "The original Links was written by Mikulas Patocka. Links 0.9x is still > maintained by Mikulas, but from 0.98 on, no new features are accepted, > only bug-fixes and translation updates." > > The links homepage seems to agree with this statement. I forgot to say, in case it isn't clear: elinks is a direct derivative project of links. -dp -- Daniel Price - Solaris Kernel Engineering - dp@eng.sun.com - blogs.sun.com/dp From Reid.Kaufmann@sun.com Wed May 14 11:53:32 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4EIrW52018819 for ; Wed, 14 May 2008 11:53:32 -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 m4EIrPQU025882 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 14 May 2008 19:53:31 +0100 (BST) 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 <0K0V00401GH29P00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 May 2008 11:53:26 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K0V0028LGH2U130@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 May 2008 11:53:26 -0700 (PDT) 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 m4EIrQFv002716 for ; Wed, 14 May 2008 18:53:26 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K0V00K01EUV0Y00@mail-amer.sun.com> (original mail from Reid.Kaufmann@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 May 2008 12:53:26 -0600 (MDT) Received: from [10.1.147.162] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K0V00H42GGZIAG0@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 May 2008 12:53:24 -0600 (MDT) Date: Wed, 14 May 2008 13:55:32 -0500 From: Reid Kaufmann Subject: Re: LSARC/2008/322 - links [FastTrack timeout 05/20/2008] Sender: Reid.Kaufmann@sun.com To: LSARC-ext@sun.com Cc: Rick Matthews Reply-to: Reid.Kaufmann@sun.com Message-id: <482B35A4.3030902@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Followup-to: <20080514092502.GA10582@eng.sun.com>,<20080514092932.GB10582@eng.sun.com>,<20080514072051.GK11914@sun.com> User-Agent: Thunderbird 2.0.0.12 (X11/20080325) Status: RO Content-Length: 2038 Daniel Price wrote: > Was any consideration given to doing 'elinks' instead? > ... > I forgot to say, in case it isn't clear: elinks is a direct derivative > project of links. I am aware of elinks, and the "one-pager" document (in the case directory) does acknowledge it's relation to links. I don't doubt that elinks has greater feature content. I have ported links 0.9x simply because it was an assignment given by the VP Open Solaris mandate. I imagine it was selected at that point because it is quite stable and because 0.98 was already available on sunfreeware.com. > I don't mean to offend, just to point out that we might get > more functionality for our engineering dollar with elinks. No offense taken. At this point, most of the prep-work has already been completed for links 0.99. Considering that, it would be most prudent to deliver links and then evaluate whether to spend Sun's resources integrating elinks as a supplement or replacement. Jyri J. Virkki wrote: > Would be a nit, but since the exported interfaces is ultimately one of > the most key sections for a case, it really is important to > communicate those interfaces clearly. I apologize for the mess. I'll fess up to cutting and pasting and not checking whether tabs or spaces were used. Below is a correction, and I'll send updated documents (foss check list and one-pager) to Rick. Exported Interfaces: Interface Name Classification Comments --------------------------- ------------------- --------------------- SUNWlinks Uncommitted Package Name /usr/bin/links Uncommitted Executable location /usr/share/man/man1/links.1 Uncommitted Man page links Uncommitted Commandline syntax Imported Interfaces: Interface Name Classification Comments --------------------------- -------------------- -------------------- OpenSSL Contracted Unstable PSARC/2003/500/... reid From Alan.Coopersmith@sun.com Wed May 14 12:28:41 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4EJSegv020556 for ; Wed, 14 May 2008 12:28:40 -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 m4EJSbVM009193 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 14 May 2008 20:28:39 +0100 (BST) 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 <0K0V00003I3QFS00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 May 2008 12:28:38 -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 <0K0V00GPHI3QFG40@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 May 2008 12:28:38 -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 m4EJScqA027700 for ; Wed, 14 May 2008 12:28:38 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K0V00401HWMZU00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 14 May 2008 12:28:38 -0700 (PDT) Received: from almas.sfbay.sun.com ([129.146.106.93]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K0V00J2GI3PN150@fe-sfbay-10.sun.com>; Wed, 14 May 2008 12:28:38 -0700 (PDT) Date: Wed, 14 May 2008 12:28:37 -0700 From: Alan Coopersmith Subject: Re: LSARC/2008/322 - links [FastTrack timeout 05/20/2008] In-reply-to: <482B35A4.3030902@Sun.COM> Sender: Alan.Coopersmith@sun.com To: Reid.Kaufmann@sun.com Cc: LSARC-ext@sun.com, Rick Matthews , David Comay Message-id: <482B3D65.8000909@sun.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-Enigmail-Version: 0.95.1 References: <482B35A4.3030902@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 792 Reid Kaufmann wrote: > I am aware of elinks, and the "one-pager" document (in the case > directory) does acknowledge it's relation to links. I don't doubt > that elinks has greater feature content. I have ported links 0.9x > simply because it was an assignment given by the VP Open Solaris > mandate. I imagine it was selected at that point because it is quite > stable and because 0.98 was already available on sunfreeware.com. The "VP OpenSolaris mandate" was not to blindly port everything on the list, but to evaluate the things on the list to see what should or should not be integrated. Your job was to do the evaluation and selection, because it wasn't done yet. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Richard.Matthews@sun.com Wed May 21 06:54:46 2008 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 m4LDskTa005938 for ; Wed, 21 May 2008 06:54:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m4LDsj7a005583 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 21 May 2008 06:54:46 -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 <0K1800H0T1BABS00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 21 May 2008 06:54:46 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1800DKV1B8VH60@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 21 May 2008 06:54:45 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4LDsiOk021408 for ; Wed, 21 May 2008 13:54:44 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1800K010SPCN00@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM) for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 21 May 2008 07:54:44 -0600 (MDT) Received: from [129.152.9.14] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1800E2U1B8QOF0@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 21 May 2008 07:54:44 -0600 (MDT) Date: Wed, 21 May 2008 08:54:44 -0500 From: Rick Matthews Subject: LSARC/2008/322 - links [FastTrack timeout 05/20/2008] Sender: Richard.Matthews@sun.com To: LSARC-ext@sun.com Reply-to: Richard.Matthews@sun.com Message-id: <483429A4.2090203@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 530 This case was approved during yesterday's open ARC business. -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- From sacadmin Fri May 30 12:33:59 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m4UJXxSs009300 for ; Fri, 30 May 2008 12:33:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m4UJXwCO054896 for <@sunmail2sca.sfbay.sun.com:lsarc-record@sun.com>; Fri, 30 May 2008 13:33:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K1P0010950K6V00@nwk-avmta-2.sfbay.sun.com> for lsarc-record@sun.com (ORCPT lsarc-record@sun.com); Fri, 30 May 2008 12:33:56 -0700 (PDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K1P00KGU50IV250@nwk-avmta-2.sfbay.sun.com> for lsarc-record@sun.com (ORCPT lsarc-record@sun.com); Fri, 30 May 2008 12:33:55 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4UJXsLa019853 for ; Fri, 30 May 2008 19:33:54 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K1P00L01409IS00@mail-amer.sun.com> (original mail from Richard.Matthews@Sun.COM) for lsarc-record@sun.com (ORCPT lsarc-record@sun.com); Fri, 30 May 2008 13:33:54 -0600 (MDT) Received: from [129.152.9.14] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K1P00AA15032YA0@mail-amer.sun.com> for lsarc-record@sun.com (ORCPT lsarc-record@sun.com); Fri, 30 May 2008 13:33:42 -0600 (MDT) Date: Fri, 30 May 2008 14:33:39 -0500 From: Rick Matthews Subject: LSARC/2008/322 - links Sender: Richard.Matthews@Sun.COM To: lsarc-record@Sun.COM Reply-to: Richard.Matthews@Sun.COM Message-id: <48405693.4000307@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_xRytNNb31mJjaFAv5XeekA)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.12 (X11/20080228) Status: RO Content-Length: 27848 This is a multi-part message in MIME format. --Boundary_(ID_xRytNNb31mJjaFAv5XeekA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT For the record.... -------- Original Message -------- Subject: Re: request for review of "links" Date: Fri, 30 May 2008 14:16:37 -0500 From: Rick Matthews Reply-To: Richard.Matthews@Sun.COM To: Mike.Sullivan@Sun.COM CC: Alan.Coopersmith@Sun.COM, Gregory.Matthews@Sun.COM, Reid.Kaufmann@Sun.COM References: <200805281653.m4SGrBlA390128@yavin.Eng.Sun.COM> Mike, Thanks for the reply. I'm going to cut out some of this thread. I think we're in general agreement. -- Rick Mike.Sullivan@Sun.COM wrote: > >From Richard.Matthews@sun.com Tue May 27 19:14:57 2008 > > >> There was a lengthy discussion about this subject at the LSARC meeting on >> May 20.You can review the audio is you choose to. >> > > No minutes just audio? sigh. > > Well if there was a discussion that's good. But it would have been > good to summarize to the case log as otherwise it just looks like > Alan was ignored. > Either Reid or I will add the appropriate commentary to the case log. Alan was essentially ignored. We can fix that. It was also unusual that Alan didn't take part in the meeting. I'm not sure about written minutes (not a usual LSARC guy...PSARC keeps both). > >> As to the elinks/links >> question, I don't think anyone disagrees that elinks should also be >> ported (except >> me). The fact that links was on "the list" meant it was important to >> someone. >> > > AFAIK, 'the list' was a list of suggestions to evaluate and simply start > with. It was not a list of must haves. > I think we understand this point. elinks has been added to our list of ports. > >> If as Alan claims, links should be dropped and elinks should be added, >> get that >> ruling from "makers of the list" and this work will be discarded. Does >> someone >> want to tell me why we want any text based browser? >> > > I like text browsers. Or at least, I'd like at least one. Personally > I don't want to have more than one of each thing before we cover the > holes in Solaris (I'd rather have emacs instead of 3 text browsers and > 12 ways to do ftp, for example, heck or even more games like nethack). > > I would rather have something that's under active development as > well. Putting something in that is dead, or marked as no-new-features > (like elinks... it's not dead but clearly in that mode) seems wrong. > That's certainly going to happen to some things after integration, but > it seems wrong to integrate them if we know they're in that situation, > as it will likely add to the amount of support we have to do. > If those who made the list wanted a priority, they should have added one. If they wanted rules like "one instance until all bases covered", such guidance should have been given. Also, someone (or in some combined report) should have classified what functionality is provided. (Wouldn't it been nice to have a update-able list so groups didn't "false start" on ports which were already in progress?). I guess my point here is while you and Alan are correct that some intelligence should have been applied by each project team as to disposition of the selected utility, some intelligence should also been applied to how to organize and maintain the list by the SFW (or whoever). Sorry, I don't know who owns the list...our involvement is to submit a list of potential choices to a project manager, who gave us a yea or nay. > >> LSARC decided that more than one thing that has similar functionality >> is acceptable. If links is completely obsolete (no one on the face of >> the earth >> uses it), it fails the familiarity test. Otherwise, it is just as >> eligible as elinks. >> > > We can certainly have more than one. I just question priorities when > we have more than one thing in the same area when we have holes to > cover first. > Yep...I think we understand that also. But shouldn't we submit the work already done? Or should we hold onto links until elink, emacs and lynx are integrated. Should we toss it on the floor? Our management has specified that we proceed with this integration as the case was approved by LSARC. > >> I did ask Reid to make sure elinks got added to the list (since it >> wasn't there >> initially...on any copies I saw). >> Mike, are you involved with the team that made the list? >> > > Other than them trying to make me do it all once no :) > But I think David Comay is involved. And I've asked him to > try to clarify that ('sigh, again' I think he said :) since > this is the second time somebody has said they had to do exactly > what was on the list. Note that I'm not upset with Reid about > that, I am quite sure that after going through many layers of > management everything was lost except 'pick something and do it' :) > Amen! > >> Do you use >> elinks? >> > > no. > > >> Why? Inquiring minds want to know. >> > > I use lynx myself. I use it all the time to look up bugs, since it's > a lot faster than firefox (it's my simple 'bugcat' script to talk to > monaco). And sometimes I use it to read docs or mail I get in > html format when I'm at home using mailx. I am, as they say, old. > I understand...I have a little mileage myself. Old dogs and whatever... Thanks for the info about what you use, and why...useful info. > >> Please note that I intentionally did not post this to the external >> list. If it really >> belongs there, I'll let one of you do so in the reply. >> > > The only reason that there's a -ext is in the sfw alias is because > one person is a contractor who originally didn't have a Sun address. > There's no reason to hide things like this from him. > OK...didn't know... > Mike > > >> -- >> Rick >> >> Mike Sullivan wrote: >> >>>
>>> >>> hopefully this will be readable. I'll try to mark my responses >>> with a '*': >>> >>> >>> 2. Review >>> >>> _X__ 2.1 ARC approval status: list case name, number, date approved >>> and approved release binding. >>> LSARC/2008/322 approved 05/20/08 for minor release binding >>> >>> _X__ 2.2. List all ARC TCRs and TCAs >>> No formal TCRs or TCAs. All LSARC questions were resolved. >>> >>> * hmm I'm not sure about all questions being resolved. >>> In particular the question Dan asked as an interested party, >>> about why links and not elinks when elinks appears to be the >>> active development branch? Why not elinks? It doesn't seem to >>> me that this response is good enough: >>> >>> --- >>> I am aware of elinks, and the "one-pager" document (in the case >>> directory) does acknowledge it's relation to links. I don't doubt >>> that elinks has greater feature content. I have ported links 0.9x >>> simply because it was an assignment given by the VP Open Solaris mandate. >>> I imagine it was selected at that point because it is quite stable and >>> because 0.98 was already available on sunfreeware.com. >>> --- >>> >>> I'm pretty sure the 'VP Open Solaris mandate' was not 'go port these >>> and only these' and was more of a suggestion list, that was supposed to >>> involve evaluation and possible changes. If elinks is more appropriate, >>> and if it's under more active development I'd think it is, then why >>> not do that? >>> >>> I see Alan pointed that out but there was no response to him. >>> >>> I don't buy this either: >>> >>> --- >>> At this point, most of the prep-work has already >>> been completed for links 0.99. Considering that, it would be most >>> prudent to deliver links and then evaluate whether to spend Sun's >>> resources integrating elinks as a supplement or replacement. >>> --- >>> >>> Once links is there it will be a lot more work to replace it with >>> elinks instead of just doing elinks now, and a lot easier to say >>> 'why bother with elinks we already have links'. >>> >>> >>> YES_ 2.3 Code review complete and all issues resolved? >>> >>> The makefiles and install scripts were reviewed. Paul Cunningham >>> (paul.cunningham@tadpole.com) and Steve Christensen >>> (steve@smc.vnet.net) provided feedback and this was the resolution >>> (summarized): >>> >>> Paul, I added URL to the METADATA file. I took your suggestions >>> in the Makefile and removed the "-g" flag since it's not needed. >>> GCC is required because it doesn't compile with Sun's CC. I also >>> moved the copyright notices as you suggested. >>> >>> * it compiles with studio if I remove the 'inline' from terminal.c. >>> Though with lots of nasty warnings. I dunno that that's a good reason >>> to use gcc though. Actually I didn't even have to remove it this >>> configure line did it "env CC=cc CFLAGS=-Dinline= ./configure" >>> though it may not be that easy in the Makefile.sfw. >>> >>> Steven, I updated to the 0.99 tarball (from 0.99pre6) taken from >>> the primary site. >>> >>> * I was going to worry about that since we don't generally include >>> rc/pre/alpha bits but I won't now :) >>> >>> >>> >>> 3. Testing >>> >>> 3.1 Describe briefly the testing you have done. >>> >>> Built and installed on both x86/64 and sparc. The test was >>> to use >>> links to log into NetAdmin in order to verify basic page >>> rendering and >>> ssl functionality. Also verified that the man page >>> displayed properly. >>> >>> YES complete? >>> 5/23/08 - date completed >>> YES on all supported ISAs? >>> List supported ISAs: x86/64 and sparc >>> >>> * why call out 64 on intel, is there a 64-bit version you're doing? >>> If so, why not call out both 32 and 64-bit sparc? Or does it depend >>> on the type of kernel you're running (strange for a browser to >>> do so though). >>> >>> >>> Which Metacluster(s)? >>> [+] SUNWCall (Entire distribution) >>> [+] SUNWCprog (Developer) >>> [ ] SUNWCuser (End-User) >>> [ ] SUNWCreq (Core) >>> [ ] SUNWCrnet (Reduced Networking System Support) >>> >>> * why not end-user? they wouldn't want to use a text browser because >>> they always have a gui, and nobody would want to write a tool for >>> an end-user that might want this? I know I use lynx all the time because >>> it's faster to look up bugs with that than firefox. >>> >>> Mike >>>
>>> >> -- >> --------------------------------------------------------------------- >> Rick Matthews email: Rick.Matthews@sun.com >> Sun Microsystems, Inc. phone:+1(651) 554-1518 >> 1270 Eagan Industrial Road phone(internal): 54418 >> Suite 160 fax: +1(651) 554-1540 >> Eagan, MN 55121-1231 USA main: +1(651) 554-1500 >> --------------------------------------------------------------------- >> >> >> -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- --Boundary_(ID_xRytNNb31mJjaFAv5XeekA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT For the record....

-------- Original Message --------
Subject: Re: request for review of "links"
Date: Fri, 30 May 2008 14:16:37 -0500
From: Rick Matthews <Richard.Matthews@Sun.COM>
Reply-To: Richard.Matthews@Sun.COM
To: Mike.Sullivan@Sun.COM
CC: Alan.Coopersmith@Sun.COM, Gregory.Matthews@Sun.COM, Reid.Kaufmann@Sun.COM
References: <200805281653.m4SGrBlA390128@yavin.Eng.Sun.COM>


Mike,
  Thanks for the reply. I'm going to cut out some of this thread. I think we're in general agreement.
--
Rick

Mike.Sullivan@Sun.COM wrote: 
>From Richard.Matthews@sun.com Tue May 27 19:14:57 2008

  
 There was a lengthy discussion about this subject at the LSARC meeting on
May 20.You can review the audio is you choose to.
    

No minutes just audio? sigh.

Well if there was a discussion that's good. But it would have been
good to summarize to the case log as otherwise it just looks like
Alan was ignored.
Either Reid or I will add the appropriate commentary to the case log.
Alan was essentially ignored. We can fix that. It was also unusual that
Alan didn't take part in the meeting.

I'm not sure about written minutes (not a usual LSARC guy...PSARC
keeps both).
  
As to the elinks/links
question, I don't think anyone disagrees that elinks should also be 
ported (except
me). The fact that links was on "the list" meant it was important to 
someone.
    

AFAIK, 'the list' was a list of suggestions to evaluate and simply start
with. It was not a list of must haves.
I think we understand this point. elinks has been added to our list of ports.
  
If as Alan claims, links should be dropped and elinks should be added, 
get that
ruling from "makers of the list" and this work will be discarded.  Does 
someone
want to tell me why we want any text based browser?
    

I like text browsers. Or at least, I'd like at least one. Personally
I don't want to have more than one of each thing before we cover the
holes in Solaris (I'd rather have emacs instead of 3 text browsers and
12 ways to do ftp, for example, heck or even more games like nethack).

I would rather have something that's under active development as
well. Putting something in that is dead, or marked as no-new-features
(like elinks... it's not dead but clearly in that mode) seems wrong.
That's certainly going to happen to some things after integration, but
it seems wrong to integrate them if we know they're in that situation,
as it will likely add to the amount of support we have to do.
If those who made the list wanted a priority, they should have added one. If they
wanted rules like "one instance until all bases covered", such guidance should have been
given. Also, someone (or in some combined report) should have classified what
functionality is provided. (Wouldn't it been nice to have a update-able list so
groups didn't "false start" on ports which were already in progress?). I guess my
point here is while you and Alan are correct that some intelligence should have been
applied by each project team as to disposition of the selected utility, some intelligence
should also been applied to how to organize and maintain the list by the SFW (or
whoever). Sorry, I don't know who owns the list...our involvement is to submit a list
of potential choices to a project manager, who gave us a yea or nay. 
  
 LSARC decided that more than one thing that has similar functionality
is acceptable. If links is completely obsolete (no one on the face of 
the earth
uses it), it fails the familiarity test. Otherwise, it is just as 
eligible as elinks.
    

We can certainly have more than one. I just question priorities when
we have more than one thing in the same area when we have holes to
cover first.
Yep...I think we understand that also. But shouldn't we submit the work already done?
Or should we hold onto links until elink, emacs and lynx are integrated. Should we toss it
on the floor? Our management has specified that we proceed with this integration as
the case was approved by LSARC.
  
 I did ask Reid to make sure elinks got added to the list (since it 
wasn't there
initially...on any copies I saw).
 Mike, are you involved with the team that made the list?
    

Other than them trying to make me do it all once no :)
But I think David Comay is involved. And I've asked him to
try to clarify that ('sigh, again' I think he said :) since
this is the second time somebody has said they had to do exactly
what was on the list. Note that I'm not upset with Reid about
that, I am quite sure that after going through many layers of
management everything was lost except 'pick something and do it' :)
Amen!
  
Do you use 
elinks?
    

no.

  
Why? Inquiring minds want to know.
    

I use lynx myself. I use it all the time to look up bugs, since it's
a lot faster than firefox (it's my simple 'bugcat' script to talk to
monaco). And sometimes I use it to read docs or mail I get in
html format when I'm at home using mailx. I am, as they say, old.
I understand...I have a little mileage myself. Old dogs and whatever... Thanks for the
info about what you use, and why...useful info.
  
 Please note that I intentionally did not post this to the external 
list. If it really
belongs there, I'll let one of you do so in the reply.
    

The only reason that there's a -ext is in the sfw alias is because
one person is a contractor who originally didn't have a Sun address.
There's no reason to hide things like this from him.
OK...didn't know...
	Mike

  
--
Rick

Mike Sullivan wrote:
    
<div class="moz-text-flowed" style="font-family: -moz-fixed">

hopefully this will be readable. I'll try to mark my responses
with a '*':


2. Review

_X__ 2.1  ARC approval status: list case name, number, date approved
and approved release binding.
    LSARC/2008/322 approved 05/20/08 for minor release binding

_X__ 2.2. List all ARC TCRs and TCAs
        No formal TCRs or TCAs.  All LSARC questions were resolved.

* hmm I'm not sure about all questions being resolved.
In particular the question Dan asked as an interested party,
about why links and not elinks when elinks appears to be the
active development branch? Why not elinks? It doesn't seem to
me that this response is good enough:

---
I am aware of elinks, and the "one-pager" document (in the case
directory) does acknowledge it's relation to links.  I don't doubt
that elinks has greater feature content.  I have ported links 0.9x
simply because it was an assignment given by the VP Open Solaris mandate.
I imagine it was selected at that point because it is quite stable and
because 0.98 was already available on sunfreeware.com.
---

I'm pretty sure the 'VP Open Solaris mandate' was not 'go port these
and only these' and was more of a suggestion list, that was  supposed to
involve evaluation and possible changes.  If elinks is more appropriate,
and if it's under more active development I'd think it is, then why
not do that?

I see Alan pointed that out but there was no response to him.

I don't buy this either:

---
At this point, most of the prep-work has already
been completed for links 0.99.  Considering that, it would be most
prudent to deliver links and then evaluate whether to spend Sun's
resources integrating elinks as a supplement or replacement.
---

Once links is there it will be a lot more work to replace it with
elinks instead of just doing elinks now, and a lot easier to say
'why bother with elinks we already have links'.


YES_ 2.3  Code review complete and all issues resolved?

    The makefiles and install scripts were reviewed.  Paul Cunningham
    (paul.cunningham@tadpole.com) and Steve Christensen
    (steve@smc.vnet.net) provided feedback and this was the resolution
    (summarized):

        Paul, I added URL to the METADATA file. I took your suggestions
        in the Makefile and removed the "-g" flag since it's not needed.
        GCC is required because it doesn't compile with Sun's CC. I also
        moved the copyright notices as you suggested.

* it compiles with studio if I remove the 'inline' from terminal.c.
Though with lots of nasty warnings. I dunno that that's a good reason
to use gcc though. Actually I didn't even have to remove it this
configure line did it "env CC=cc CFLAGS=-Dinline= ./configure"
though it may not be that easy in the Makefile.sfw.

        Steven, I updated to the 0.99 tarball (from 0.99pre6) taken from
        the primary site.

* I was going to worry about that since we don't generally include
rc/pre/alpha bits but I won't now :)



3. Testing

      3.1 Describe briefly the testing you have done.

          Built and installed on both x86/64 and sparc.  The test was 
to use
          links to log into NetAdmin in order to verify basic page 
rendering and
          ssl functionality.  Also verified that the man page 
displayed properly.

          YES  complete?
           5/23/08 - date completed
          YES  on all supported ISAs?
               List supported ISAs: x86/64 and sparc

* why call out 64 on intel, is there a 64-bit version you're doing?
If so, why not call out both 32 and 64-bit sparc? Or does it depend
on the type of kernel you're running (strange for a browser to
do so though).


Which Metacluster(s)?
                       [+] SUNWCall  (Entire distribution)
                       [+] SUNWCprog (Developer)
                       [ ] SUNWCuser (End-User)
                       [ ] SUNWCreq  (Core)
                       [ ] SUNWCrnet (Reduced Networking System Support)

* why not end-user? they wouldn't want to use a text browser because
they always have a gui, and nobody would want to write a tool for
an end-user that might want this? I know I use lynx all the time because
it's faster to look up bugs with that than firefox.

    Mike
</div>
      
-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews@sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500		
---------------------------------------------------------------------


    


-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews@sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500		
---------------------------------------------------------------------


-- 
---------------------------------------------------------------------
Rick Matthews                           email: Rick.Matthews@sun.com
Sun Microsystems, Inc.                  phone:+1(651) 554-1518
1270 Eagan Industrial Road              phone(internal): 54418
Suite 160                               fax:  +1(651) 554-1540
Eagan, MN 55121-1231 USA                main: +1(651) 554-1500		
---------------------------------------------------------------------
--Boundary_(ID_xRytNNb31mJjaFAv5XeekA)--