From sacadmin Tue Jan 29 16:28:55 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 m0U0St8a004511; Tue, 29 Jan 2008 16:28:55 -0800 (PST) Received: (from johnf@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m0U0StYt004506; Tue, 29 Jan 2008 16:28:55 -0800 (PST) Date: Tue, 29 Jan 2008 16:28:55 -0800 (PST) From: John Fischer Message-Id: <200801300028.m0U0StYt004506@sac.sfbay.sun.com> To: LSARC-record@sac.sfbay.sun.com Subject: Indiana fast track check list [LSARC/2008/061 FastTrack timeout 02/05/2008] Status: RO Content-Length: 566 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Indiana fast track check list 1.2. Name of Document Author/Supplier: Author: John Fischer 1.3 Date of This Document: 29 January, 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: SAC 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From John.Fischer@sun.com Tue Jan 29 16:45:06 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 m0U0j5XA004649 for ; Tue, 29 Jan 2008 16:45:06 -0800 (PST) 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 m0U0j0AT021632 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 30 Jan 2008 00:45:04 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 <0JVF00K1FM315M00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 29 Jan 2008 16:45:01 -0800 (PST) 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 <0JVF002Q2M30Q5A0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 29 Jan 2008 16:45:00 -0800 (PST) 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 m0U0j0uH002444 for ; Tue, 29 Jan 2008 16:45:00 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVF00G01LZI5M00@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 29 Jan 2008 16:45:00 -0800 (PST) Received: from [192.168.10.6] ([24.10.86.139]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVF008YRM2ZXU30@fe-sfbay-09.sun.com>; Tue, 29 Jan 2008 16:45:00 -0800 (PST) Date: Tue, 29 Jan 2008 16:44:40 -0800 From: John Fischer Subject: LSARC/2008/061 - Indiana check list Sender: John.Fischer@sun.com To: lsarc-ext@sun.com Cc: David.Comay@sun.com Reply-to: John.Fischer@sun.com Message-id: <479FC878.6010900@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_7vT2uNQG9pwnuj4rs8/OCg)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 8501 This is a multi-part message in MIME format. --Boundary_(ID_7vT2uNQG9pwnuj4rs8/OCg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT LSARC, I am sponsoring this project for myself as a representative of the ARC community and a C-Team producing many Indiana projects in the near future. The attached check list is also in the project directory. I have set a time out for Tuesday, February 5th, 2008. As discussed at LSARC before the winter break this project proposes a check list to help facilitate the review of the Indiana projects. The idea is that the various Indiana projects will be able to use this check list to determine if the new component can be approved automatic or needs a committee review. After talking with a couple other committee members we noted that the minimum requirements revolve around security and installation location. This document reflects that opinion. Thanks, John --Boundary_(ID_7vT2uNQG9pwnuj4rs8/OCg) Content-type: text/plain; name=Indiana-Check-list Content-transfer-encoding: 7BIT Content-disposition: inline; filename=Indiana-Check-list ICL--Indiana Check List 0. Introduction 0.1 Document History Version Author Change 0.1 John Fischer Initial Draft 0.2 John Fischer Modified based upon feedback from ARC members 0.2 Purpose Architecture review at Sun has allowed the company to evolve our projects within multiple disjoint groups while still maintaining a cohesive product line. Each architecture review was conducted within Sun's control. With the advent of Free Open Source Software processes the control that Sun as a company can wield has been diminished. Now that Sun is moving to a more fluid delivery mechanism with project Indiana we need to evolve the architecture review process. This document is meant to aid in the architecture review process. Each new project must complete this check list to help ensure that the overall resulting product conforms to Sun product standards. If the project deviates from these standards further review would be necessary by an architecture review committee. 1.0 Project Information 1.1 Name of project/component 1.2 Author of document 2.0 Project Summary 2.1 Project Description 2.2 Originating Community 2.2.1 Community Name 2.2.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [ ] Contributor [ ] Monitoring Will changes be feed back to the community? [ ] Yes [ ] No - briefly explain Will we or are we forking from the community? [ ] Yes - ARC review required prior to forking [ ] No 2.2.3 Licensing Indicate the license for the component(s) [ ] GPL [ ] Other 3.0 Technical Description 3.1 Installation 3.1.1 Installation (see http://opensolaris.org/os/community/arc/policies/install-locations/ for details) Does this project follow the Install Locations best practice? [ ] Yes [ ] No - ARC review required Does this project install into /usr under [sbin|bin|lib|include|man|share]? [ ] Yes [ ] No or N/A Does this project install into /opt? [ ] Yes - explain below [ ] No or N/A Does this project install into a different directory structure? [ ] Yes - ARC review required [ ] 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 [ ] No If conflicts exist then will this project install under /usr/gnu? [ ] Yes [ ] No - ARC review required [ ] N/A Is this project installing into /usr/sfw? [ ] Yes - ARC review required [ ] No 3.1.2 Share and Sharable Are any components shared with other Free Open Souce Software (FOSS)? [ ] Yes [ ] 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 Security 3.2.1 Secure By Default (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) Are network services enabled by default? [ ] Yes - ARC review required [ ] No [ ] N/A Are network services automatically enabled by the project during installation? [ ] Yes - ARC review required [ ] No [ ] N/A Are inbound network communications denied by default? [ ] Yes [ ] No - ARC review required [ ] N/A Is inbound data checked to prevent content-based attacks? [ ] Yes [ ] No - ARC review required [ ] N/A Is the outbound receiver authenticated? [ ] Yes [ ] No - ARC review required [ ] N/A Is the receiver authenticated prior to receiving any sensitive outbound communication? [ ] Yes [ ] No - ARC review required [ ] N/A 3.2.2 Authorization (see http://opensolaris.org/os/community/arc/bestpractices/rbac-auths for details) Are there any setuid/setgid privileged binaries in the project? [ ] Yes [ ] 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.2.3 Auditing (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details) Does this component contain administrative or security enforcing software? [ ] Yes [ ] No - continue to next section Do the components create audit logs detailing what took place including what event took place, who was involved, when the event took place? [ ] Yes [ ] No - ARC review required 3.2.4 General Security Questions (see http://opensolaris.org/os/community/arc/bestpractices/security-questions/ for details) Do the components use standard network protocols? [ ] Yes [ ] No - ARC review required Do network services for the project make decisions based upon user, host or service identities? [ ] Yes - explain below [ ] No [ ] N/A Do the components make use of secret information during authentication and/or authorization? [ ] Yes - explain below [ ] No [ ] N/A 3.5 Libraries Are 64-bit libraries being delivered? [ ] Yes [ ] No - ARC review required Are static versions of the library being delivered? [ ] Yes - ARC review required [ ] No 4.0 Interfaces (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) 4.1 Exported Interfaces Interface Name Classification 4.2 Imported Interfaces Interface Name Classification Brief Interface Classification definitions Volatile - Fill out Check List interfaces that are very fluid and typically follow the originating community. Typically these interfaces can not be imported by other projects. Uncommitted - ARC review required interfaces that are still evolving but will most likely be present from release to release. Committed - ARC review required 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. Contracted (interface modifier) - ARC review of Contract required interfaces that do not allow another project to import can be Appendix A References Appendix B - Suggested case materials 1. man pages 2. SMF manifests --Boundary_(ID_7vT2uNQG9pwnuj4rs8/OCg)-- From carlsonj@phorcys.east.sun.com Wed Jan 30 08:18:43 2008 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 m0UGIg9n021702 for ; Wed, 30 Jan 2008 08:18:43 -0800 (PST) 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 m0UGIdeF010870; Thu, 31 Jan 2008 00:18:40 +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 <0JVG00C03TB2KH00@brm-avmta-1.central.sun.com>; Wed, 30 Jan 2008 09:18:38 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVG005OOTB0A160@brm-avmta-1.central.sun.com>; Wed, 30 Jan 2008 09:18:37 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m0UGIO24013840; Wed, 30 Jan 2008 11:18:27 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m0UGILC7013832; Wed, 30 Jan 2008 11:18:21 -0500 (EST) Date: Wed, 30 Jan 2008 11:18:21 -0500 From: James Carlson Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <479FC878.6010900@sun.com> To: John.Fischer@sun.com Cc: lsarc-ext@sun.com Message-id: <18336.41805.709677.50471@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FC878.6010900@sun.com> Status: RO Content-Length: 6131 John Fischer writes: > I am sponsoring this project for myself as a representative > of the ARC community and a C-Team producing many Indiana projects > in the near future. The attached check list is also in the > project directory. I have set a time out for Tuesday, February > 5th, 2008. I suspect I'm missing some background necessary to review this, so if you could indulge me some questions, I'd appreciate it. I'm a little confused about the relationship between this checklist and Indiana. If this is just a "how do we deal with externally-run open source" guideline, then it sounds good to have, but I'm not sure why it needs to be focused on Indiana in particular. It should be generic goodness, right? If an open source project plans to integrate into one of the existing OpenSolaris consolidations, but the project team isn't one that's working on Indiana, is the checklist unusable? (How do we verify that?) One possible answer is that this checklist is an attempt to codify rules about how projects integrate into Indiana. But if that's the case, it sounds to me like a non-sequitur, because Indiana is currently (or last I understood _was_) just a project with alpha-test bits. It's not a release or a consolidation, as far as I understand, so there's no ARC role to play. If it is now one of those release vehicles then (besides the OpenSolaris constitutional requirements, which are probably out of scope here) shouldn't we at least have some sort of release binding information? How exactly do we evaluate dependencies and stability levels without paying attention to release binding? Comments on the text of the proposal: > line. Each architecture review was conducted within Sun's control. With > the advent of Free Open Source Software processes the control that Sun as > a company can wield has been diminished. Now that Sun is moving to a more Perhaps it doesn't matter much in terms of how the checklist will be used, but I think that this discussion of "control" completely misses the point. Architectural review has always been about producing a coherent system, and not about "control." To be explicit: we do not actually need control over an external software provider in order to produce a meaningful architectural review. In fact, having control has *never* been a requirement. Instead, just like legal review, code review, laws of physics, and other such matters, the existence or absence of project team control over the contents of their delivery forms another constraint. If the ARC says "you must do X" in order to integrate, and if "X" is not possible in your constrained universe and providing a cogent argument that sways the ARC members otherwise doesn't work, then you cannot integrate. It's really as simple as that. In other words, if a project team comes to the ARC and says (for example) that they're going to depend on FooBar, but FooBar's interfaces are all Volatile or Private, and FooBar is in another consolidation, and the owner of FooBar refuses to provide a contract on the stability, what are we to do? Does it really matter that both projects are "open source" if the result will be a product that fails miserably? I don't think we can wish those problems away or just pretend that there's some magic open source dust that'll make everything just work fine. The basis of those dependency rules we use isn't some egg-headed scheme to thwart project teams in their pursuit of release velocity; it's mother nature. You depend on it, it changes, you break. > 2.2 Originating Community > 2.2.1 Community Name I'm not sure about the architectural relevance of this part, particularly the licensing question that specially calls out GPL (which version?). (Is there some other consumer of this checklist ... ?) > If conflicts exist then will this project install under /usr/gnu? > [ ] Yes > [ ] No - ARC review required > [ ] N/A Note that this option is available _only_ for FSF software. Other things don't belong in /usr/gnu, even if they're released under one of the many GPL licenses, at least per the existing approved cases. > Are any components shared with other Free Open Souce Software (FOSS)? Nit: s/Souce/Source/ > If yes are these newer versions being delivered? > [ ] Yes > [ ] No - ARC review required What newer versions? (Something's missing, because this question doesn't flow with the previous question ... it's assuming a newer version of something, but I'm not sure what.) > If yes then are the setuid/setgid privileges handled by the use of roles? > [ ] Yes > [ ] No - ARC review required I might be missing something here, but since RBAC is currently a Solaris-only facility, doesn't this at least imply that we're either forcing changes upstream or forking? (I thought the whole thrust of this proposal was to avoid changing anything ...) > Do the components create audit logs detailing what took place including what event > took place, who was involved, when the event took place? > [ ] Yes > [ ] No - ARC review required The current policy doesn't require just any old audit logs, but instead requires the use of Solaris Audit Trails. As an architectural matter, I don't think I agree with fragmenting the audit infrastructure by allowing open source projects to write audit records through other, disconnected mechanisms (such as syslog or flat files). Doing that significantly weakens the value of the Solaris auditing facility. Requiring proper auditing forces project teams to change things. :-< > Brief Interface Classification definitions Omitted from the list is the generally quite useful Consolidation Private. Is that intentional? Not sure that I fully agree with the summaries here, but I suppose it's ok as long as there's a pointer to the full descriptions. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From alan.coopersmith@sun.com Wed Jan 30 08:52:27 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 m0UGqRmB022677 for ; Wed, 30 Jan 2008 08:52:27 -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 m0UGqKAY028138 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 30 Jan 2008 09:52:27 -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 <0JVG0073FUVEYO00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 08:52:26 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVG001WBUVB4F40@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 08:52:23 -0800 (PST) Received: from [192.168.0.101] (vpn-129-150-19-95.SFBay.Sun.COM [129.150.19.95]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m0UGqJM9022632; Wed, 30 Jan 2008 08:52:22 -0800 (PST) Date: Wed, 30 Jan 2008 08:52:15 -0800 From: Alan Coopersmith Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <18336.41805.709677.50471@gargle.gargle.HOWL> To: James Carlson Cc: John.Fischer@sun.com, lsarc-ext@sun.com Message-id: <47A0AB3F.8040205@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FC878.6010900@sun.com> <18336.41805.709677.50471@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.4 (X11/20060602) Status: RO Content-Length: 1216 James Carlson wrote: > I'm a little confused about the relationship between this checklist > and Indiana. Unfortunately, we've overloaded "Project Indiana" - this part isn't about building a new distro, but about the related effort to add a whole lot of external open source to Solaris/OpenSolaris, to provide a more useful set of software out of the box, whether you're getting the packages from the Nevada CD's or the Indiana online package repository. >> If yes then are the setuid/setgid privileges handled by the use of roles? >> [ ] Yes >> [ ] No - ARC review required > > I might be missing something here, but since RBAC is currently a > Solaris-only facility, doesn't this at least imply that we're either > forcing changes upstream or forking? Isn't this just taking the upstream binary, and instead of installing it setuid/setgid adding an entry to the RBAC configuration files to allow users with specific profiles to run it with added privileges? That shouldn't require any source changes in many cases. (It didn't for the X binaries I've had to do this with.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From carlsonj@phorcys.east.sun.com Wed Jan 30 09:11:05 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0UHB5aa023429 for ; Wed, 30 Jan 2008 09:11:05 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0UHB48M003595; Wed, 30 Jan 2008 09:11:04 -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 <0JVG00919VQDR400@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jan 2008 09:11:01 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVG001LZVQB4P50@nwk-avmta-1.sfbay.Sun.COM>; Wed, 30 Jan 2008 09:11:00 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m0UHArAW014152; Wed, 30 Jan 2008 12:10:56 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m0UHAlwN014145; Wed, 30 Jan 2008 12:10:47 -0500 (EST) Date: Wed, 30 Jan 2008 12:10:47 -0500 From: James Carlson Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <47A0AB3F.8040205@sun.com> To: Alan Coopersmith Cc: John.Fischer@sun.com, lsarc-ext@sun.com Message-id: <18336.44951.523629.27406@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FC878.6010900@sun.com> <18336.41805.709677.50471@gargle.gargle.HOWL> <47A0AB3F.8040205@sun.com> Status: RO Content-Length: 3481 Alan Coopersmith writes: > James Carlson wrote: > > I'm a little confused about the relationship between this checklist > > and Indiana. > > Unfortunately, we've overloaded "Project Indiana" - this part isn't about > building a new distro, but about the related effort to add a whole lot of > external open source to Solaris/OpenSolaris, to provide a more useful set > of software out of the box, whether you're getting the packages from the > Nevada CD's or the Indiana online package repository. Ah ... I see. Still, I'm confused about whether _any_ external open source project can make use of this checklist, or only a special set that are part of this looser confederation of projects? What if Joerg comes to us tomorrow and asks to use this checklist to gain automatic approval for one of his projects? Does that work? (Not to pick on him particularly, but he came to mind. ;-}) More generally, can it work for any external source? What about purchased software? Provided that there's an upstream, and that we have less direct influence over that upstream[1], why do we care enough about the upstream development model and/or legal foundation to write special rules for things inbound from an "open" location versus things inbound from a "closed" one? How is that an architectural matter? I'm not completely positive on this (as I'm still not sure about the underlying purpose of this checklist), but it seems that we're being asked to carve out a hole. If that's so, then I'd like to know approximately where the hole will be sited, and some idea of the size. > >> If yes then are the setuid/setgid privileges handled by the use of roles? > >> [ ] Yes > >> [ ] No - ARC review required > > > > I might be missing something here, but since RBAC is currently a > > Solaris-only facility, doesn't this at least imply that we're either > > forcing changes upstream or forking? > > Isn't this just taking the upstream binary, and instead of installing it > setuid/setgid adding an entry to the RBAC configuration files to allow users > with specific profiles to run it with added privileges? That shouldn't > require any source changes in many cases. (It didn't for the X binaries > I've had to do this with.) It may ... depending on what privileges are involved and how they're used. For instance, it's possible to provide separate configuration read and write privileges for individual administrative utilities, and if the utility itself doesn't make those fine-grained checks, nothing else will. You're right that it might be "just" a packaging and delivery change. But even there, I'm not sure that all packaging changes are necessarily no-ops from a maintenance perspective. [1] I still don't see how influence comes into the picture here. It seems to be part of the fundamental assumptions of this proposal that having direct influence on the project design is necessary in order to have proper system architecture, and that we otherwise must just swallow what we're given. If it's external, we slap it together and hope for the best. It's never been that way before, and there seems no necessary reason to suppose it should be now, so I can't quite figure that out. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From John.Fischer@sun.com Wed Jan 30 10:41:14 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0UIfEGq000078 for ; Wed, 30 Jan 2008 10:41:14 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m0UIfBR7001446 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 30 Jan 2008 10:41:14 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVG00H1LZWOQN00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 10:41:12 -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 <0JVG0018TZWO4HB0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 10:41:12 -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 m0UIfCuk026237 for ; Wed, 30 Jan 2008 10:41:12 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVG00K01Z5Q9600@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 10:41:12 -0800 (PST) Received: from [192.168.10.6] ([24.10.86.139]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVG009PJZWMTSD0@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 10:41:10 -0800 (PST) Date: Wed, 30 Jan 2008 10:40:48 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <18336.44951.523629.27406@gargle.gargle.HOWL> Sender: John.Fischer@sun.com To: James Carlson Cc: Alan Coopersmith , lsarc-ext@sun.com Reply-to: John.Fischer@sun.com Message-id: <47A0C4B0.9060603@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FC878.6010900@sun.com> <18336.41805.709677.50471@gargle.gargle.HOWL> <47A0AB3F.8040205@sun.com> <18336.44951.523629.27406@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 4903 James, Great questions!! You are correct that any external open source project could use this check list. This is an attempt to help us, the ARCs and specifically LSARC, deal with the expected influx of cases that have the delivery mechanism of Indiana. For instance my group will be working on integrating 70 new projects into Open Solaris. We would use this new check list to determine if an automatic approval is appropriate or a more thorough review would be required. But you are correct the consumer of the check list could be any external open source project. The idea is that the project team would fill out the check list and then submit the paper work to sac as an automatic closed case. This way we still have a record of the interfaces. Now the basic premise of this check list is that these interfaces are defined at some stability level (mostly Volatile, though not necessarily), adhere to our security standards and installation location. If the project teams can not give these basic assurances then they must seek further review. Most of the questions revolve around various security Best Practices or Policies and the Gnu installation location PSARC case. Now in terms of open vs. closed. It could also be used for closed projects but since we control of those projects then we can do a better review. They should also adhere to more then just security and installation location Sun standards. I think that Alan already answered the sgid/suid question you had. If not just let me know. Thanks, John James Carlson wrote: > Alan Coopersmith writes: >> James Carlson wrote: >>> I'm a little confused about the relationship between this checklist >>> and Indiana. >> Unfortunately, we've overloaded "Project Indiana" - this part isn't about >> building a new distro, but about the related effort to add a whole lot of >> external open source to Solaris/OpenSolaris, to provide a more useful set >> of software out of the box, whether you're getting the packages from the >> Nevada CD's or the Indiana online package repository. > > Ah ... I see. Still, I'm confused about whether _any_ external open > source project can make use of this checklist, or only a special set > that are part of this looser confederation of projects? > > What if Joerg comes to us tomorrow and asks to use this checklist to > gain automatic approval for one of his projects? Does that work? > (Not to pick on him particularly, but he came to mind. ;-}) > > More generally, can it work for any external source? What about > purchased software? Provided that there's an upstream, and that we > have less direct influence over that upstream[1], why do we care > enough about the upstream development model and/or legal foundation to > write special rules for things inbound from an "open" location versus > things inbound from a "closed" one? How is that an architectural > matter? > > I'm not completely positive on this (as I'm still not sure about the > underlying purpose of this checklist), but it seems that we're being > asked to carve out a hole. If that's so, then I'd like to know > approximately where the hole will be sited, and some idea of the size. > >>>> If yes then are the setuid/setgid privileges handled by the use of roles? >>>> [ ] Yes >>>> [ ] No - ARC review required >>> I might be missing something here, but since RBAC is currently a >>> Solaris-only facility, doesn't this at least imply that we're either >>> forcing changes upstream or forking? >> Isn't this just taking the upstream binary, and instead of installing it >> setuid/setgid adding an entry to the RBAC configuration files to allow users >> with specific profiles to run it with added privileges? That shouldn't >> require any source changes in many cases. (It didn't for the X binaries >> I've had to do this with.) > > It may ... depending on what privileges are involved and how they're > used. For instance, it's possible to provide separate configuration > read and write privileges for individual administrative utilities, and > if the utility itself doesn't make those fine-grained checks, nothing > else will. > > You're right that it might be "just" a packaging and delivery change. > But even there, I'm not sure that all packaging changes are > necessarily no-ops from a maintenance perspective. > > > [1] I still don't see how influence comes into the picture here. It > seems to be part of the fundamental assumptions of this proposal > that having direct influence on the project design is necessary > in order to have proper system architecture, and that we > otherwise must just swallow what we're given. If it's external, > we slap it together and hope for the best. It's never been that > way before, and there seems no necessary reason to suppose it > should be now, so I can't quite figure that out. > From carlsonj@phorcys.east.sun.com Wed Jan 30 12:06:54 2008 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 m0UK6roS016667 for ; Wed, 30 Jan 2008 12:06:54 -0800 (PST) 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 m0UK6icl013169; Thu, 31 Jan 2008 04:06:50 +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 <0JVH0061J3VAGY00@brm-avmta-1.central.sun.com>; Wed, 30 Jan 2008 13:06:46 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVH005CT3V9I070@brm-avmta-1.central.sun.com>; Wed, 30 Jan 2008 13:06:45 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m0UK6jZn015490; Wed, 30 Jan 2008 15:06:45 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m0UK6jfH015487; Wed, 30 Jan 2008 15:06:45 -0500 (EST) Date: Wed, 30 Jan 2008 15:06:45 -0500 From: James Carlson Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <47A0C4B0.9060603@sun.com> To: John.Fischer@sun.com Cc: Alan Coopersmith , lsarc-ext@sun.com Message-id: <18336.55509.183678.658889@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FC878.6010900@sun.com> <18336.41805.709677.50471@gargle.gargle.HOWL> <47A0AB3F.8040205@sun.com> <18336.44951.523629.27406@gargle.gargle.HOWL> <47A0C4B0.9060603@sun.com> Status: RO Content-Length: 3918 John Fischer writes: > You are correct that any external open source project could use > this check list. OK; that alleviates probably the biggest of my concerns: having a set of "special rules." > This is an attempt to help us, the ARCs and > specifically LSARC, deal with the expected influx of cases that > have the delivery mechanism of Indiana. Unfortunately, at least in architectural terms, I have no clue what that "delivery mechanism" means. What type of release is Indiana, anyway? How can we approve the integration of projects when we don't know what the constraints on the interface changes might be? In other words, "Committed" behaves one way in a "Minor" release, but quite another in a "Major." If we don't know what we have, then we can't actually say much about the changes. > could be any external open source project. The idea is that the > project team would fill out the check list and then submit the > paper work to sac as an automatic closed case. This way we still > have a record of the interfaces. I didn't see anything in there about the stability of interfaces versus usage context (e.g., project and consolidation boundaries) and dependencies. We could codify the existing rules fairly easily for the checklist, but would this just create more trouble? For each other project [library, et cetera] that you depend on, obtain the stability levels and delivering consolidation for that other project, and check against this list. ("Fail" means "needs explicit review.") Other stability Consolidation Release Vehicle Result --------------- ------------- --------------- ------ Any Any Major Fail Committed Any Not Major OK Uncommitted Any Minor Fail Uncommitted Any Patch OK Volatile Same Any OK Volatile Other Any Fail Cons. Private Same Any Fail Cons. Private Other Any Fail Proj. Private Any Any Fail (Well, something like that.) > Now the basic premise of this check list is that these interfaces > are defined at some stability level (mostly Volatile, though not > necessarily), adhere to our security standards and installation > location. If the project teams can not give these basic assurances > then they must seek further review. Most of the questions revolve > around various security Best Practices or Policies and the Gnu > installation location PSARC case. There seem to be other assumptions here -- perhaps that the dependencies on other projects will just work themselves out (perhaps in some other forum rather than the ARC). > Now in terms of open vs. closed. It could also be used for > closed projects but since we control of those projects then we > can do a better review. They should also adhere to more then just > security and installation location Sun standards. I wasn't talking about any projects we "control." Instead, I was talking about "open source" versus "source purchased from some vendor." In terms of this checklist, and the rationale behind it, those two cases seem like the same thing to me -- they're both instances where we have no authoritative "control" over the way the software is developed. In truth, I don't think that control is or ever was an architectural matter, but since it's a (puzzling) part of this proposal, I was commenting on how it seems to have nothing to do with whether that externally-obtained source is itself developed in an open or proprietary manner. It's more of a "found software" checklist. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Brian.Cameron@sun.com Wed Jan 30 14:17:01 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0UMH100023904 for ; Wed, 30 Jan 2008 14:17:01 -0800 (PST) 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 m0UMH14u016945 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 30 Jan 2008 14:17:01 -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 <0JVH00M059WDDC00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 14:17:01 -0800 (PST) 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 <0JVH00GKH9WCH5A0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 14:17:00 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m0UMH0cr003439 for ; Wed, 30 Jan 2008 22:17:00 +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 <0JVH00C019Q0N100@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 30 Jan 2008 15:17:00 -0700 (MST) Received: from [192.168.1.191] ([200.78.19.149]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVH00I7H9W81J80@mail-amer.sun.com>; Wed, 30 Jan 2008 15:17:00 -0700 (MST) Date: Wed, 30 Jan 2008 16:16:59 -0600 From: Brian Cameron Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <479FC878.6010900@sun.com> Sender: Brian.Cameron@sun.com To: John.Fischer@sun.com Cc: lsarc-ext@sun.com, David.Comay@sun.com Message-id: <47A0F75B.20900@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FC878.6010900@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070814) Status: RO Content-Length: 2364 John: > Indicate Sun's involvement in the community > [ ] Maintainer > [ ] Contributor > [ ] Monitoring Rather than ask whether we are a contributor or a maintainer, we should ask how the project is involved. Build fixes, code enhancements, integration with Sun-specific services, G11N support, documentation support, QA, a11y. All of the above? > Will changes be feed back to the community? > [ ] Yes > [ ] No - briefly explain I think it would be good to "briefly explain" when the answer is Yes. We should tease out what sort of involvement exists, and what is planned. Only Solaris-specific build/bug fixes? G11N support? What, exactly. > Will we or are we forking from the community? > [ ] Yes - ARC review required prior to forking > [ ] No There often is debate about whether applying patches is a "fork". At what point do we define a fork? How many patches? Or do patches not have anything to do with forking? > 2.2.3 Licensing > Indicate the license for the component(s) > [ ] GPL > [ ] Other This question seems less than useful. What about LGPL, MIT, etc.? A fill-in-the-blank would be better. Perhaps should also ask if the license has any exceptions (like media programs sometimes have to allow IP plugins). > 3.1.2 Share and Sharable > Are any components shared with other Free Open Souce Software > (FOSS)? > [ ] Yes > [ ] No I am not clear what this means. Could you explain, perhaps provide an example? I see no questions about the following sorts of things which would be useful, I'd think: - degree of I18N support - existence of manpages and whether they describe the interfaces reasonably well. - existence of installed API documentation for libraries or other interface documentation (such as gtk-docs) - existence of any encryption - whether the interface duplicates the functionality of another module we already ship (is it yet another database, for example). If yes, please explain - degree of a11y support (perhaps several questions for each use case GOK, orca, theming, keynav, etc.) - Does the program follow usability style guide (such as GNOME HIG if it is a GNOME Program, or CLIP). - Does the project install a GPL library to /usr/lib? - Does the project install C++ interfaces From John.Fischer@sun.com Fri Feb 1 15:57:26 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 m11NvP00027219 for ; Fri, 1 Feb 2008 15:57:25 -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 m11NvLSM029229 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 1 Feb 2008 23:57:24 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 <0JVL00I073VMYI00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 16:57:22 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVL004LI3VLMK70@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 16:57:21 -0700 (MST) 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 m11NvLjn015183 for ; Fri, 01 Feb 2008 15:57:21 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVL007013TLI600@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 15:57:20 -0800 (PST) Received: from [192.168.10.6] ([24.10.86.139]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVL007K63VKZF80@fe-sfbay-09.sun.com>; Fri, 01 Feb 2008 15:57:20 -0800 (PST) Date: Fri, 01 Feb 2008 15:56:55 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <47A0F75B.20900@sun.com> Sender: John.Fischer@sun.com To: Brian Cameron Cc: lsarc-ext@sun.com, David.Comay@sun.com Reply-to: John.Fischer@sun.com Message-id: <47A3B1C7.9060009@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FC878.6010900@sun.com> <47A0F75B.20900@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 4283 Brian, See below. Thanks, John Brian Cameron wrote: > > John: > > > Indicate Sun's involvement in the community > > [ ] Maintainer > > [ ] Contributor > > [ ] Monitoring > > Rather than ask whether we are a contributor or a maintainer, we should > ask how the project is involved. Build fixes, code enhancements, > integration with Sun-specific services, G11N support, documentation > support, QA, a11y. All of the above? This question was placed in the check list to better understand what influence we might have on the project. It actually is informational only and could be removed. > > Will changes be feed back to the community? > > [ ] Yes > > [ ] No - briefly explain > > I think it would be good to "briefly explain" when the answer is Yes. > We should tease out what sort of involvement exists, and what is > planned. Only Solaris-specific build/bug fixes? G11N support? > What, exactly. This question was to understand why we would be forking from the community and not providing the changes back (i.e., we actually are not participating in the community). > > > Will we or are we forking from the community? > > [ ] Yes - ARC review required prior to forking > > [ ] No > > There often is debate about whether applying patches is a "fork". > At what point do we define a fork? How many patches? Or do patches > not have anything to do with forking? Exactly. If we are required to fork from the community then we need to understand that perspective as a committee and company. Thus we would want further review. If the patches are eventually delivered to the up-stream then that would not be considered a fork by me. > > 2.2.3 Licensing > > Indicate the license for the component(s) > > [ ] GPL > > [ ] Other > > This question seems less than useful. What about LGPL, MIT, etc.? > A fill-in-the-blank would be better. Perhaps should also ask if the > license has any exceptions (like media programs sometimes have to > allow IP plugins). Viral licensing is a concern from an architectural perspective. This is only what I am asking about. The other licenses that you point out are not viral. > > 3.1.2 Share and Sharable > > Are any components shared with other Free Open Souce Software > > (FOSS)? > > [ ] Yes > > [ ] No > > I am not clear what this means. Could you explain, perhaps provide > an example? This is an attempt to get the project team thinking about component packaging. If the component is interesting to other project then it should be packaged in a sharable way. Think of the NSPR & NSS issues we have had from the Mozilla organization. If those had originally been packaged in a sharable manor then we would have potentially saved ourselves much headache. > I see no questions about the following sorts of things which would > be useful, I'd think: True. That was on purpose. Several of the committee members talked about these types of issues in IRC. We decided that we would not require a full review unless the projects did not fit our security and installation model. These were the low hanging fruit or requirements. Encryption should be caught in a legal review. Though it could be added. The question we would need to ask is would we require a review if encryption was included? What if it wasn't included? If the answer is no to either one of those questions then it is not needed in the check list. For those on IRC it was a no. > - degree of I18N support > - existence of manpages and whether they describe the interfaces > reasonably well. > - existence of installed API documentation for libraries or other > interface documentation (such as gtk-docs) > - existence of any encryption > - whether the interface duplicates the functionality of another module > we already ship (is it yet another database, for example). If yes, > please explain > - degree of a11y support (perhaps several questions for each use case > GOK, orca, theming, keynav, etc.) > - Does the program follow usability style guide (such as GNOME HIG if it > is a GNOME Program, or CLIP). > - Does the project install a GPL library to /usr/lib? > - Does the project install C++ interfaces > > From Brian.Cameron@sun.com Fri Feb 1 16:44:20 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 m120iK1r029580 for ; Fri, 1 Feb 2008 16:44:20 -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 m120iHLd015118 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Sat, 2 Feb 2008 00:44:19 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 <0JVL00M0161UHC00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 17:44:18 -0700 (MST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVL004OC61TM590@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 17:44:17 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m120iHWe012061 for ; Sat, 02 Feb 2008 00:44:17 +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 <0JVL009015VD0K00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 01 Feb 2008 17:44:17 -0700 (MST) Received: from [192.168.1.77] ([189.147.109.48]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVL009ID61GWT90@mail-amer.sun.com>; Fri, 01 Feb 2008 17:44:17 -0700 (MST) Date: Fri, 01 Feb 2008 18:44:07 -0600 From: Brian Cameron Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <47A3B1C7.9060009@sun.com> Sender: Brian.Cameron@sun.com To: John.Fischer@sun.com Cc: lsarc-ext@sun.com, David.Comay@sun.com Message-id: <47A3BCD7.10305@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FC878.6010900@sun.com> <47A0F75B.20900@sun.com> <47A3B1C7.9060009@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 6343 John: >> >> > Indicate Sun's involvement in the community >> > [ ] Maintainer >> > [ ] Contributor >> > [ ] Monitoring >> >> Rather than ask whether we are a contributor or a maintainer, we should >> ask how the project is involved. Build fixes, code enhancements, >> integration with Sun-specific services, G11N support, documentation >> support, QA, a11y. All of the above? > > This question was placed in the check list to better understand what > influence we might have on the project. It actually is informational > only and could be removed. I agree it is useful. I just think it would be more useful to tease out more specifically what involvement we have. >> > Will changes be feed back to the community? >> > [ ] Yes >> > [ ] No - briefly explain >> >> I think it would be good to "briefly explain" when the answer is Yes. >> We should tease out what sort of involvement exists, and what is >> planned. Only Solaris-specific build/bug fixes? G11N support? >> What, exactly. > > This question was to understand why we would be forking from the > community and not providing the changes back (i.e., we actually > are not participating in the community). The question probably should say "fed" instead of "feed". I think I have trouble with the term "changes" being a bit vague. Perhaps a better way to word this would be "Will we work with the community to get our changes upstream?" Note that we can't always get our changes upstream because sometimes maintainers don't like our changes. But we can try. >> > Will we or are we forking from the community? >> > [ ] Yes - ARC review required prior to forking >> > [ ] No >> >> There often is debate about whether applying patches is a "fork". >> At what point do we define a fork? How many patches? Or do patches >> not have anything to do with forking? > > Exactly. If we are required to fork from the community then we > need to understand that perspective as a committee and company. > Thus we would want further review. If the patches are eventually > delivered to the up-stream then that would not be considered a fork > by me. The GNOME project has over 200 patches that are unlikely to go upstream. We have over 400 pages in total, and I am probably being generous thinking that 250 of them will eventually go upstream. However, I wouldn't characterize GNOME as being a fork. The fact we modify GNOME for branding purposes, and to support things like Trusted Solaris, is probably not really a fork. We just apply a set of changes to the base code that are probably not appropriate to go upstream. However, when I talk to some people within Sun, they seem to think if we have even a single patch, we are forking. It might be good if "fork" had a more clear definition. Otherwise you'll get random answers to the question. I think forking typically requires a separate project with its own maintainer and different goals, etc. It is not applying a patch to make a function work on Solaris. >> > 2.2.3 Licensing >> > Indicate the license for the component(s) >> > [ ] GPL >> > [ ] Other >> >> This question seems less than useful. What about LGPL, MIT, etc.? >> A fill-in-the-blank would be better. Perhaps should also ask if the >> license has any exceptions (like media programs sometimes have to >> allow IP plugins). > > Viral licensing is a concern from an architectural perspective. This > is only what I am asking about. The other licenses that you point > out are not viral. Might be better to simply ask if the license is viral then, and use GPL as an example. GPL isn't the only viral license. >> > 3.1.2 Share and Sharable >> > Are any components shared with other Free Open Souce Software >> > (FOSS)? >> > [ ] Yes >> > [ ] No >> >> I am not clear what this means. Could you explain, perhaps provide >> an example? > > This is an attempt to get the project team thinking about component > packaging. If the component is interesting to other project then > it should be packaged in a sharable way. Think of the NSPR & NSS issues > we have had from the Mozilla organization. If those had originally > been packaged in a sharable manor then we would have potentially > saved ourselves much headache. Perhaps the question could be worded better. Why does the question ask if the components are shared with other FOSS. A module could install a component used by a non-FOSS project. For example, GTK+ is shared with non-FOSS things like Adobe Reader. Perhaps "Does this module include any components that are used or shared by other projects" or something would be more clear? >> I see no questions about the following sorts of things which would >> be useful, I'd think: > > True. That was on purpose. Several of the committee members talked > about these types of issues in IRC. We decided that we would not > require a full review unless the projects did not fit our security > and installation model. These were the low hanging fruit or > requirements. Is this because ARC is not so interested in worrying about whether FOSS projects meets requirements outside of security/installation issues? > Encryption should be caught in a legal review. Though > it could be added. The question we would need to ask is would we > require a review if encryption was included? What if it wasn't > included? If the answer is no to either one of those questions > then it is not needed in the check list. For those on IRC it > was a no. Okay. >> - degree of I18N support >> - existence of manpages and whether they describe the interfaces >> reasonably well. >> - existence of installed API documentation for libraries or other >> interface documentation (such as gtk-docs) >> - existence of any encryption >> - whether the interface duplicates the functionality of another module >> we already ship (is it yet another database, for example). If yes, >> please explain >> - degree of a11y support (perhaps several questions for each use case >> GOK, orca, theming, keynav, etc.) >> - Does the program follow usability style guide (such as GNOME HIG if it >> is a GNOME Program, or CLIP). >> - Does the project install a GPL library to /usr/lib? >> - Does the project install C++ interfaces Brian From John.Fischer@sun.com Mon Feb 4 13:29:25 2008 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 m14LTOvd024007 for ; Mon, 4 Feb 2008 13:29:25 -0800 (PST) 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 m14LTMNj020432 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 5 Feb 2008 05:29:24 +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 <0JVQ00A07H0YQP00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 14:29:22 -0700 (MST) 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 <0JVQ007ICH0XSI20@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 14:29:21 -0700 (MST) 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 m14LTLSI023979 for ; Mon, 04 Feb 2008 13:29:21 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVQ00I01GJUOP00@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 13:29:21 -0800 (PST) Received: from [192.168.10.6] ([24.10.86.139]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVQ006N1H0SP590@fe-sfbay-09.sun.com>; Mon, 04 Feb 2008 13:29:16 -0800 (PST) Date: Mon, 04 Feb 2008 13:29:12 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <47A3BCD7.10305@sun.com> Sender: John.Fischer@sun.com To: Brian Cameron Cc: lsarc-ext@sun.com, David.Comay@sun.com Reply-to: John.Fischer@sun.com Message-id: <47A783A8.4020603@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FC878.6010900@sun.com> <47A0F75B.20900@sun.com> <47A3B1C7.9060009@sun.com> <47A3BCD7.10305@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 7367 Brian, See below. John Brian Cameron wrote: > > John: > >>> >>> > Indicate Sun's involvement in the community >>> > [ ] Maintainer >>> > [ ] Contributor >>> > [ ] Monitoring >>> >>> Rather than ask whether we are a contributor or a maintainer, we should >>> ask how the project is involved. Build fixes, code enhancements, >>> integration with Sun-specific services, G11N support, documentation >>> support, QA, a11y. All of the above? >> >> This question was placed in the check list to better understand what >> influence we might have on the project. It actually is informational >> only and could be removed. > > I agree it is useful. I just think it would be more useful to tease out > more specifically what involvement we have. Yes. But that will not cause us to say that the project needs further review by the committee. >>> > Will changes be feed back to the community? >>> > [ ] Yes >>> > [ ] No - briefly explain >>> >>> I think it would be good to "briefly explain" when the answer is Yes. >>> We should tease out what sort of involvement exists, and what is >>> planned. Only Solaris-specific build/bug fixes? G11N support? >>> What, exactly. >> >> This question was to understand why we would be forking from the >> community and not providing the changes back (i.e., we actually >> are not participating in the community). > > The question probably should say "fed" instead of "feed". I think > I have trouble with the term "changes" being a bit vague. Perhaps a > better way to word this would be "Will we work with the community to > get our changes upstream?" How about: Will the project team work with the upstream community to resolve architectural issues of interest to Sun? > Note that we can't always get our changes upstream because sometimes > maintainers don't like our changes. But we can try. > >>> > Will we or are we forking from the community? >>> > [ ] Yes - ARC review required prior to forking >>> > [ ] No >>> >>> There often is debate about whether applying patches is a "fork". >>> At what point do we define a fork? How many patches? Or do patches >>> not have anything to do with forking? >> >> Exactly. If we are required to fork from the community then we >> need to understand that perspective as a committee and company. >> Thus we would want further review. If the patches are eventually >> delivered to the up-stream then that would not be considered a fork >> by me. > > The GNOME project has over 200 patches that are unlikely to go upstream. > We have over 400 pages in total, and I am probably being generous > thinking that 250 of them will eventually go upstream. > > However, I wouldn't characterize GNOME as being a fork. The fact we > modify GNOME for branding purposes, and to support things like Trusted > Solaris, is probably not really a fork. We just apply a set of changes > to the base code that are probably not appropriate to go upstream. > > However, when I talk to some people within Sun, they seem to think > if we have even a single patch, we are forking. It might be good if > "fork" had a more clear definition. Otherwise you'll get random > answers to the question. > > I think forking typically requires a separate project with its own > maintainer and different goals, etc. It is not applying a patch > to make a function work on Solaris. I would not characterize the Gnome patches as forking from the community either. The team attempts to get these patches into the upstream community. In terms of branding purposes those are legitimate reasons for Sun. Again not what we are getting at for this issue. If the project can not determine if the changes they are providing are for Sun branding and whether or not they are forking then perhaps they need a review anyhow. >>> > 2.2.3 Licensing >>> > Indicate the license for the component(s) >>> > [ ] GPL >>> > [ ] Other >>> >>> This question seems less than useful. What about LGPL, MIT, etc.? >>> A fill-in-the-blank would be better. Perhaps should also ask if the >>> license has any exceptions (like media programs sometimes have to >>> allow IP plugins). >> >> Viral licensing is a concern from an architectural perspective. This >> is only what I am asking about. The other licenses that you point >> out are not viral. > > Might be better to simply ask if the license is viral then, and use > GPL as an example. GPL isn't the only viral license. How about: Is the license viral? GPL is an example of a viral license. [ ] Yes [ ] No >>> > 3.1.2 Share and Sharable >>> > Are any components shared with other Free Open Souce Software >>> > (FOSS)? >>> > [ ] Yes >>> > [ ] No >>> >>> I am not clear what this means. Could you explain, perhaps provide >>> an example? >> >> This is an attempt to get the project team thinking about component >> packaging. If the component is interesting to other project then >> it should be packaged in a sharable way. Think of the NSPR & NSS issues >> we have had from the Mozilla organization. If those had originally >> been packaged in a sharable manor then we would have potentially >> saved ourselves much headache. > > Perhaps the question could be worded better. Why does the question ask > if the components are shared with other FOSS. A module could install > a component used by a non-FOSS project. For example, GTK+ is shared > with non-FOSS things like Adobe Reader. > > Perhaps "Does this module include any components that are used or > shared by other projects" or something would be more clear? That is fine wording. >>> I see no questions about the following sorts of things which would >>> be useful, I'd think: >> >> True. That was on purpose. Several of the committee members talked >> about these types of issues in IRC. We decided that we would not >> require a full review unless the projects did not fit our security >> and installation model. These were the low hanging fruit or >> requirements. > > Is this because ARC is not so interested in worrying about whether > FOSS projects meets requirements outside of security/installation > issues? > > > Encryption should be caught in a legal review. Though >> it could be added. The question we would need to ask is would we >> require a review if encryption was included? What if it wasn't >> included? If the answer is no to either one of those questions >> then it is not needed in the check list. For those on IRC it >> was a no. > > Okay. > >>> - degree of I18N support >>> - existence of manpages and whether they describe the interfaces >>> reasonably well. >>> - existence of installed API documentation for libraries or other >>> interface documentation (such as gtk-docs) >>> - existence of any encryption >>> - whether the interface duplicates the functionality of another module >>> we already ship (is it yet another database, for example). If yes, >>> please explain >>> - degree of a11y support (perhaps several questions for each use case >>> GOK, orca, theming, keynav, etc.) >>> - Does the program follow usability style guide (such as GNOME HIG if it >>> is a GNOME Program, or CLIP). >>> - Does the project install a GPL library to /usr/lib? >>> - Does the project install C++ interfaces > > Brian From Brian.Cameron@sun.com Mon Feb 4 15:01:47 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m14N1lNL027681 for ; Mon, 4 Feb 2008 15:01:47 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m14N1lcX023976 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 4 Feb 2008 15:01:47 -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 <0JVQ00D5RLAYIX00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 15:01:46 -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 <0JVQ008ALLAWF590@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 15:01:44 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m14N1iPE028352 for ; Mon, 04 Feb 2008 23:01: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 <0JVQ00E01KI76A00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 04 Feb 2008 16:01:44 -0700 (MST) Received: from [192.168.1.64] ([189.137.195.67]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVQ00J9XLATNU00@mail-amer.sun.com>; Mon, 04 Feb 2008 16:01:44 -0700 (MST) Date: Mon, 04 Feb 2008 17:01:42 -0600 From: Brian Cameron Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <47A783A8.4020603@sun.com> Sender: Brian.Cameron@sun.com To: John.Fischer@sun.com Cc: lsarc-ext@sun.com, David.Comay@sun.com Message-id: <47A79956.5050009@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <479FC878.6010900@sun.com> <47A0F75B.20900@sun.com> <47A3B1C7.9060009@sun.com> <47A3BCD7.10305@sun.com> <47A783A8.4020603@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 6254 John: >>>> >>>> > Indicate Sun's involvement in the community >>>> > [ ] Maintainer >>>> > [ ] Contributor >>>> > [ ] Monitoring >>>> >>>> Rather than ask whether we are a contributor or a maintainer, we should >>>> ask how the project is involved. Build fixes, code enhancements, >>>> integration with Sun-specific services, G11N support, documentation >>>> support, QA, a11y. All of the above? >>> >>> This question was placed in the check list to better understand what >>> influence we might have on the project. It actually is informational >>> only and could be removed. >> >> I agree it is useful. I just think it would be more useful to tease out >> more specifically what involvement we have. > > Yes. But that will not cause us to say that the project needs further > review by the committee. Understood, but the more information we gather in this area, the better we understand our relationship, which seems a good thing. I understand, though, if people feel it is outside the scope and the question isn't modified, or if it is removed. >>>> > Will changes be feed back to the community? >>>> > [ ] Yes >>>> > [ ] No - briefly explain >>>> >>>> I think it would be good to "briefly explain" when the answer is Yes. >>>> We should tease out what sort of involvement exists, and what is >>>> planned. Only Solaris-specific build/bug fixes? G11N support? >>>> What, exactly. >>> >>> This question was to understand why we would be forking from the >>> community and not providing the changes back (i.e., we actually >>> are not participating in the community). >> >> The question probably should say "fed" instead of "feed". I think >> I have trouble with the term "changes" being a bit vague. Perhaps a >> better way to word this would be "Will we work with the community to >> get our changes upstream?" > > How about: > > Will the project team work with the upstream community to resolve > architectural issues of interest to Sun? That seems much more clear. >> Note that we can't always get our changes upstream because sometimes >> maintainers don't like our changes. But we can try. >> >>>> > Will we or are we forking from the community? >>>> > [ ] Yes - ARC review required prior to forking >>>> > [ ] No >>>> >>>> There often is debate about whether applying patches is a "fork". >>>> At what point do we define a fork? How many patches? Or do patches >>>> not have anything to do with forking? >>> >>> Exactly. If we are required to fork from the community then we >>> need to understand that perspective as a committee and company. >>> Thus we would want further review. If the patches are eventually >>> delivered to the up-stream then that would not be considered a fork >>> by me. >> >> The GNOME project has over 200 patches that are unlikely to go upstream. >> We have over 400 pages in total, and I am probably being generous >> thinking that 250 of them will eventually go upstream. >> >> However, I wouldn't characterize GNOME as being a fork. The fact we >> modify GNOME for branding purposes, and to support things like Trusted >> Solaris, is probably not really a fork. We just apply a set of changes >> to the base code that are probably not appropriate to go upstream. >> >> However, when I talk to some people within Sun, they seem to think >> if we have even a single patch, we are forking. It might be good if >> "fork" had a more clear definition. Otherwise you'll get random >> answers to the question. >> >> I think forking typically requires a separate project with its own >> maintainer and different goals, etc. It is not applying a patch >> to make a function work on Solaris. > > I would not characterize the Gnome patches as forking from the > community either. The team attempts to get these patches into > the upstream community. In terms of branding purposes those > are legitimate reasons for Sun. Again not what we are getting > at for this issue. If the project can not determine if the > changes they are providing are for Sun branding and whether or > not they are forking then perhaps they need a review anyhow. My suggestion is that it might be good to provide a bit of a definition of what is meant by fork. However, it is also reasonable to expect project teams to know this. >>>> > 2.2.3 Licensing >>>> > Indicate the license for the component(s) >>>> > [ ] GPL >>>> > [ ] Other >>>> >>>> This question seems less than useful. What about LGPL, MIT, etc.? >>>> A fill-in-the-blank would be better. Perhaps should also ask if the >>>> license has any exceptions (like media programs sometimes have to >>>> allow IP plugins). >>> >>> Viral licensing is a concern from an architectural perspective. This >>> is only what I am asking about. The other licenses that you point >>> out are not viral. >> >> Might be better to simply ask if the license is viral then, and use >> GPL as an example. GPL isn't the only viral license. > > How about: > > Is the license viral? GPL is an example of a viral license. > [ ] Yes > [ ] No I think that is a better question. >>>> > 3.1.2 Share and Sharable >>>> > Are any components shared with other Free Open Souce Software >>>> > (FOSS)? >>>> > [ ] Yes >>>> > [ ] No >>>> >>>> I am not clear what this means. Could you explain, perhaps provide >>>> an example? >>> >>> This is an attempt to get the project team thinking about component >>> packaging. If the component is interesting to other project then >>> it should be packaged in a sharable way. Think of the NSPR & NSS issues >>> we have had from the Mozilla organization. If those had originally >>> been packaged in a sharable manor then we would have potentially >>> saved ourselves much headache. >> >> Perhaps the question could be worded better. Why does the question ask >> if the components are shared with other FOSS. A module could install >> a component used by a non-FOSS project. For example, GTK+ is shared >> with non-FOSS things like Adobe Reader. >> >> Perhaps "Does this module include any components that are used or >> shared by other projects" or something would be more clear? > > That is fine wording. Brian From John.Fischer@sun.com Tue Feb 12 07:55:01 2008 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 m1CFt03h007099 for ; Tue, 12 Feb 2008 07:55:00 -0800 (PST) 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 m1CFsicm014165 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 12 Feb 2008 23:54:58 +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 <0JW400819UVLQK00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 12 Feb 2008 08:54:58 -0700 (MST) 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 <0JW400KI5UVIY8C0@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 12 Feb 2008 08:54:54 -0700 (MST) 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 m1CFssXP000916 for ; Tue, 12 Feb 2008 07:54:54 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW400K01UP37I00@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 12 Feb 2008 07:54:54 -0800 (PST) Received: from [192.168.10.6] ([24.10.86.139]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW400KNUUVGPL90@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 12 Feb 2008 07:54:52 -0800 (PST) Date: Tue, 12 Feb 2008 07:54:35 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - Indiana check list Sender: John.Fischer@sun.com To: lsarc-ext@sun.com Cc: John Fischer Reply-to: John Fischer Message-id: <47B1C13B.2040705@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_mvLa8HuTDMsqSaAJ38xvDw)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 21951 This is a multi-part message in MIME format. --Boundary_(ID_mvLa8HuTDMsqSaAJ38xvDw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT All, Based on feedback from Llyod and Brian I have updated the check list. I have attached the modified version and a diff file. Thanks, John --Boundary_(ID_mvLa8HuTDMsqSaAJ38xvDw) Content-type: text/plain; name=Indiana-Check-list Content-transfer-encoding: 7BIT Content-disposition: inline; filename=Indiana-Check-list FCL--FOSS Check List 0. Introduction 0.1 Document History Version Author Changes 0.1 John Fischer Initial Draft 0.2 John Fischer Modified based upon feedback from ARC members 0.3 John Fischer Modified based upon feedback during committee review 0.2 Purpose Architecture review at Sun has allowed the company to evolve our projects within multiple disjoint groups while still maintaining a cohesive product line. Each architecture review was conducted within Sun's control. With the advent of Free Open Source Software processes the control that Sun as a company can wield has been diminished. Now that Sun is moving to a more fluid delivery mechanism with project Indiana we need to evolve the architecture review process. This document is meant to aid in the architecture review process. Each new project must complete this check list to help ensure that the overall resulting product conforms to Sun product standards. If the project deviates from these standards further review would be necessary by an architecture review committee. 1.0 Project Information 1.1 Name of project/component 1.2 Author of document 2.0 Project Summary 2.1 Project Description 2.2 Originating Community 2.2.1 Community Name 2.2.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [ ] Contributor [ ] Monitoring Will the project team work with the upstream community to resolve architectural issues of interest to Sun? [ ] Yes [ ] No - briefly explain Will we or are we forking from the community? [ ] Yes - ARC review required prior to forking [ ] No 2.2.3 Licensing Is the license viral? GPL is an example of a viral license. [ ] Yes (briefly explain below) [ ] 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? [ ] Yes [ ] No - ARC review required Does this project install into /usr under [sbin|bin|lib|include|man|share]? [ ] Yes [ ] No or N/A Does this project install into /opt? [ ] Yes - explain below [ ] No or N/A Does this project install into a different directory structure? [ ] Yes - ARC review required [ ] 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 [ ] No If conflicts exist then will this project install under /usr/gnu? [ ] Yes [ ] No - ARC review required [ ] N/A Is this project installing into /usr/sfw? [ ] Yes - ARC review required [ ] No 3.1.1W Windows Installation - section only required for Windows Software (see http://sac.sfbay/WSARC/2002/494 for details) Does this project install software into a :\Program Files\Sun\ or :\Sun\ directory? [ ] Yes [ ] No - ARC review required Does the project use the Windows registry? [ ] Yes [ ] No - ARC review required Does the project use HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\ for the registry key? [ ] Yes [ ] No - ARC review required Is the project's stored location HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\\Path? [ ] Yes [ ] No - ARC review required 3.1.2 Share and Sharable Does the module include any components that are used or shared by other projects? [ ] Yes [ ] 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 Security 3.2.1 Secure By Default (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) Are network services enabled by default? [ ] Yes - ARC review required [ ] No [ ] N/A Are network services automatically enabled by the project during installation? [ ] Yes - ARC review required [ ] No [ ] N/A Are inbound network communications denied by default? [ ] Yes [ ] No - ARC review required [ ] N/A Is inbound data checked to prevent content-based attacks? [ ] Yes [ ] No - ARC review required [ ] N/A Is the outbound receiver authenticated? [ ] Yes [ ] No - ARC review required [ ] N/A Is the receiver authenticated prior to receiving any sensitive outbound communication? [ ] Yes [ ] No - ARC review required [ ] N/A 3.2.2 Authorization (see http://opensolaris.org/os/community/arc/bestpractices/rbac-auths for details) Are there any setuid/setgid privileged binaries in the project? [ ] Yes [ ] 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.2.3 Auditing (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details) Does this component contain administrative or security enforcing software? [ ] Yes [ ] No - continue to next section Do the components create audit logs detailing what took place including what event took place, who was involved, when the event took place? [ ] Yes [ ] No - ARC review required 3.2.4 General Security Questions (see http://opensolaris.org/os/community/arc/bestpractices/security-questions/ for details) Do the components use standard network protocols? [ ] Yes [ ] No - ARC review required Do network services for the project make decisions based upon user, host or service identities? [ ] Yes - explain below [ ] No [ ] N/A Do the components make use of secret information during authentication and/or authorization? [ ] Yes - explain below [ ] No [ ] N/A 3.5 Libraries Are 64-bit libraries being delivered? [ ] Yes [ ] No - ARC review required Are static versions of the library being delivered? [ ] Yes - ARC review required [ ] No 4.0 Interfaces (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) 4.1 Exported Interfaces Interface Name Classification Comments --------------------------- ------------------- --------------------------- Wizzy Volatile version 0.65 Bang Project Private internally used by Wizzy for extra punch SUNWwizzy Uncommitted Wizzy's packaging 4.2 Imported Interfaces Interface Name Classification Comments --------------------------- -------------------- -------------------------- Slushy Volatile Cherry Flavor Committed Stingy Contracted Volatile see contract-4 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. Security Audit Policy http://opensolaris.org/os/community/arc/policies/audit-policy/ 7. Security questionaire http://opensolaris.org/os/community/arc/bestpractices/security-questions/ 8. Interface Taxonomy http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ Appendix B - Suggested case materials 1. man pages 2. SMF manifests 3. links to contracts Appendix C - Definitions 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 --Boundary_(ID_mvLa8HuTDMsqSaAJ38xvDw) Content-type: text/plain; name=checklist-diff2.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=checklist-diff2.txt *** /shared/sac/LSARC/2008/061/Indiana-Check-list Tue Jan 29 16:45:40 2008 --- Indiana-Check-list Fri Feb 8 17:02:05 2008 *************** *** 1,10 **** ! ICL--Indiana Check List 0. Introduction 0.1 Document History ! Version Author Change 0.1 John Fischer Initial Draft 0.2 John Fischer Modified based upon feedback from ARC members ! 0.2 Purpose Architecture review at Sun has allowed the company to evolve our projects within multiple disjoint groups while still maintaining a cohesive product --- 1,11 ---- ! FCL--FOSS Check List 0. Introduction 0.1 Document History ! Version Author Changes 0.1 John Fischer Initial Draft 0.2 John Fischer Modified based upon feedback from ARC members ! 0.3 John Fischer Modified based upon feedback during committee ! review 0.2 Purpose Architecture review at Sun has allowed the company to evolve our projects within multiple disjoint groups while still maintaining a cohesive product *************** *** 11,22 **** line. Each architecture review was conducted within Sun's control. With the advent of Free Open Source Software processes the control that Sun as a company can wield has been diminished. Now that Sun is moving to a more ! fluid delivery mechanism with project Indiana we need to evolve the architecture ! review process. This document is meant to aid in the architecture review process. ! Each new project must complete this check list to help ensure that the overall ! resulting product conforms to Sun product standards. If the project deviates ! from these standards further review would be necessary by an architecture review ! committee. 1.0 Project Information 1.1 Name of project/component --- 12,24 ---- line. Each architecture review was conducted within Sun's control. With the advent of Free Open Source Software processes the control that Sun as a company can wield has been diminished. Now that Sun is moving to a more ! fluid delivery mechanism with project Indiana we need to evolve the ! architecture review process. This document is meant to aid in the ! architecture review process. Each new project must complete this check list ! to help ensure that the overall resulting product conforms to Sun product ! standards. If the project deviates from these standards further review ! would be necessary by an architecture review committee. ! 1.0 Project Information 1.1 Name of project/component *************** *** 34,40 **** [ ] Contributor [ ] Monitoring ! Will changes be feed back to the community? [ ] Yes [ ] No - briefly explain --- 36,43 ---- [ ] Contributor [ ] Monitoring ! Will the project team work with the upstream community to resolve ! architectural issues of interest to Sun? [ ] Yes [ ] No - briefly explain *************** *** 43,55 **** [ ] No 2.2.3 Licensing ! Indicate the license for the component(s) ! [ ] GPL ! [ ] Other 3.0 Technical Description 3.1 Installation & Sharable ! 3.1.1 Installation (see http://opensolaris.org/os/community/arc/policies/install-locations/ for details) Does this project follow the Install Locations best practice? [ ] Yes --- 46,58 ---- [ ] No 2.2.3 Licensing ! Is the license viral? GPL is an example of a viral license. ! [ ] Yes (briefly explain below) ! [ ] 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? [ ] Yes *************** *** 81,88 **** [ ] Yes - ARC review required [ ] No 3.1.2 Share and Sharable ! Are any components shared with other Free Open Souce Software (FOSS)? [ ] Yes [ ] No --- 84,115 ---- [ ] Yes - ARC review required [ ] No + 3.1.1W Windows Installation - section only required for Windows Software + (see http://sac.sfbay/WSARC/2002/494 for details) + Does this project install software into a + :\Program Files\Sun\ or :\Sun\ + directory? + [ ] Yes + [ ] No - ARC review required + + Does the project use the Windows registry? + [ ] Yes + [ ] No - ARC review required + + Does the project use + HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\ + for the registry key? + [ ] Yes + [ ] No - ARC review required + + Is the project's stored location + HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\\Path? + [ ] Yes + [ ] No - ARC review required + 3.1.2 Share and Sharable ! Does the module include any components that are used or shared by ! other projects? [ ] Yes [ ] No *************** *** 188,220 **** 4.0 Interfaces (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) 4.1 Exported Interfaces ! Interface Name Classification 4.2 Imported Interfaces ! Interface Name Classification ! Brief Interface Classification definitions ! Volatile - Fill out Check List interfaces that are very fluid and typically follow the originating community. Typically these interfaces can not be imported by other projects. ! Uncommitted - ARC review required interfaces that are still evolving but will most likely be present from release to release. ! Committed - ARC review required 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. ! Contracted (interface modifier) - ARC review of Contract required interfaces that do not allow another project to import can be - - Appendix A - References - - Appendix B - Suggested case materials - 1. man pages - 2. SMF manifests --- 215,296 ---- 4.0 Interfaces (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) 4.1 Exported Interfaces ! ! Interface Name Classification Comments ! --------------------------- ------------------- --------------------------- ! Wizzy Volatile version 0.65 ! Bang Project Private internally used by Wizzy ! for extra punch ! SUNWwizzy Uncommitted Wizzy's packaging 4.2 Imported Interfaces ! Interface Name Classification Comments ! --------------------------- -------------------- -------------------------- ! Slushy Volatile ! Cherry Flavor Committed ! Stingy Contracted Volatile see contract-4 ! ! ! 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. Security Audit Policy + http://opensolaris.org/os/community/arc/policies/audit-policy/ + 7. Security questionaire + http://opensolaris.org/os/community/arc/bestpractices/security-questions/ + 8. Interface Taxonomy + http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ ! Appendix B - Suggested case materials ! 1. man pages ! 2. SMF manifests ! 3. links to contracts ! ! Appendix C - Definitions ! 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 --Boundary_(ID_mvLa8HuTDMsqSaAJ38xvDw)-- From sac-owner Tue Feb 19 09:52:19 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1JHqJAr019711 for ; Tue, 19 Feb 2008 09:52:19 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1JHqJjt056164 for ; Tue, 19 Feb 2008 09:52:19 -0800 (PST) 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 m1JHqEFi000228 for ; Tue, 19 Feb 2008 09:52:14 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWH00L01YWVGR00@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Tue, 19 Feb 2008 09:52:14 -0800 (PST) Received: from [129.146.90.41] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWH00EYHYYO4HB0@fe-sfbay-09.sun.com> for sac-review@sac.sfbay.sun.com; Tue, 19 Feb 2008 09:52:01 -0800 (PST) Date: Tue, 19 Feb 2008 09:51:59 -0800 From: John Fischer Subject: LSARC/2008/061 - FOSS Check List Sender: John.Fischer@sun.com To: sac-review@sac.sfbay.sun.com, John Fischer Reply-to: John.Fischer@sun.com Message-id: <47BB173F.4030809@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_CAmTfLhPT8mozwbTWOYscA)" User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 12401 This is a multi-part message in MIME format. --Boundary_(ID_CAmTfLhPT8mozwbTWOYscA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT SAC Members, I recently ran a fast track through LSARC-ext entitled "Indiana fast track check list" (LSARC/2008/061). After a 2 week discussion the attached check list is what was derived. There were 3 main issues when the case was filed: 1. Indiana centric resolution--make it a FOSS check list 2. Solaris centric resolution--added Windows questions 3. Lengthy check list resolution--none just admit it is lengthy, like the 20 questions Since this check list will effect future cases as essentially placing them in an Automatic Approval state LSARC thought it was wise to send it out for a wider review. Thus this email. When devising the check list a few of us got together on IRC and tried to figure out what were the minimum requirements for a FOSS project. We believed that the integration points were the most critical for us and included security, installation and making a component sharable. It was our belief that though other things are desirable from a product perspective they would not cause us as a committee to derail a fast track and have a full review. The check list reflects these beliefs. Thanks, John --Boundary_(ID_CAmTfLhPT8mozwbTWOYscA) Content-type: text/plain; name=foss-check-list.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=foss-check-list.txt FCL--FOSS Check List 0. Introduction 0.1 Document History Version Author Changes 0.1 John Fischer Initial Draft 0.2 John Fischer Modified based upon feedback from ARC members 0.3 John Fischer Modified based upon feedback during committee review 0.2 Purpose Architecture review at Sun has allowed the company to evolve our projects within multiple disjoint groups while still maintaining a cohesive product line. Each architecture review was conducted within Sun's control. With the advent of Free Open Source Software processes the control that Sun as a company can wield has been diminished. Now that Sun is moving to a more fluid delivery mechanism with project Indiana we need to evolve the architecture review process. This document is meant to aid in the architecture review process. Each new project must complete this check list to help ensure that the overall resulting product conforms to Sun product standards. If the project deviates from these standards further review would be necessary by an architecture review committee. 1.0 Project Information 1.1 Name of project/component 1.2 Author of document 2.0 Project Summary 2.1 Project Description 2.2 Originating Community 2.2.1 Community Name 2.2.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [ ] Contributor [ ] Monitoring Will the project team work with the upstream community to resolve architectural issues of interest to Sun? [ ] Yes [ ] No - briefly explain Will we or are we forking from the community? [ ] Yes - ARC review required prior to forking [ ] No 2.2.3 Licensing Is the license viral? GPL is an example of a viral license. [ ] Yes (briefly explain below) [ ] 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? [ ] Yes [ ] No - ARC review required Does this project install into /usr under [sbin|bin|lib|include|man|share]? [ ] Yes [ ] No or N/A Does this project install into /opt? [ ] Yes - explain below [ ] No or N/A Does this project install into a different directory structure? [ ] Yes - ARC review required [ ] 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 [ ] No If conflicts exist then will this project install under /usr/gnu? [ ] Yes [ ] No - ARC review required [ ] N/A Is this project installing into /usr/sfw? [ ] Yes - ARC review required [ ] No 3.1.1W Windows Installation - section only required for Windows Software (see http://sac.sfbay/WSARC/2002/494 for details) Does this project install software into a :\Program Files\Sun\ or :\Sun\ directory? [ ] Yes [ ] No - ARC review required Does the project use the Windows registry? [ ] Yes [ ] No - ARC review required Does the project use HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\ for the registry key? [ ] Yes [ ] No - ARC review required Is the project's stored location HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\\Path? [ ] Yes [ ] No - ARC review required 3.1.2 Share and Sharable Does the module include any components that are used or shared by other projects? [ ] Yes [ ] 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 Security 3.2.1 Secure By Default (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) Are network services enabled by default? [ ] Yes - ARC review required [ ] No [ ] N/A Are network services automatically enabled by the project during installation? [ ] Yes - ARC review required [ ] No [ ] N/A Are inbound network communications denied by default? [ ] Yes [ ] No - ARC review required [ ] N/A Is inbound data checked to prevent content-based attacks? [ ] Yes [ ] No - ARC review required [ ] N/A Is the outbound receiver authenticated? [ ] Yes [ ] No - ARC review required [ ] N/A Is the receiver authenticated prior to receiving any sensitive outbound communication? [ ] Yes [ ] No - ARC review required [ ] N/A 3.2.2 Authorization (see http://opensolaris.org/os/community/arc/bestpractices/rbac-auths for details) Are there any setuid/setgid privileged binaries in the project? [ ] Yes [ ] 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.2.3 Auditing (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details) Does this component contain administrative or security enforcing software? [ ] Yes [ ] No - continue to next section Do the components create audit logs detailing what took place including what event took place, who was involved, when the event took place? [ ] Yes [ ] No - ARC review required 3.2.4 General Security Questions (see http://opensolaris.org/os/community/arc/bestpractices/security-questions/ for details) Do the components use standard network protocols? [ ] Yes [ ] No - ARC review required Do network services for the project make decisions based upon user, host or service identities? [ ] Yes - explain below [ ] No [ ] N/A Do the components make use of secret information during authentication and/or authorization? [ ] Yes - explain below [ ] No [ ] N/A 3.5 Libraries Are 64-bit libraries being delivered? [ ] Yes [ ] No - ARC review required Are static versions of the library being delivered? [ ] Yes - ARC review required [ ] No 4.0 Interfaces (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) 4.1 Exported Interfaces Interface Name Classification Comments --------------------------- ------------------- --------------------------- Wizzy Volatile version 0.65 Bang Project Private internally used by Wizzy for extra punch SUNWwizzy Uncommitted Wizzy's packaging 4.2 Imported Interfaces Interface Name Classification Comments --------------------------- -------------------- -------------------------- Slushy Volatile Cherry Flavor Committed Stingy Contracted Volatile see contract-4 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. Security Audit Policy http://opensolaris.org/os/community/arc/policies/audit-policy/ 7. Security questionaire http://opensolaris.org/os/community/arc/bestpractices/security-questions/ 8. Interface Taxonomy http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ Appendix B - Suggested case materials 1. man pages 2. SMF manifests 3. links to contracts Appendix C - Definitions 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 --Boundary_(ID_CAmTfLhPT8mozwbTWOYscA)-- From sac-owner Tue Feb 19 10:19:46 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1JIJkub021816 for ; Tue, 19 Feb 2008 10:19:46 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1JIJjWe011724 for ; Tue, 19 Feb 2008 10:19:45 -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 m1JIJeS8023087 for ; Tue, 19 Feb 2008 10:19:40 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWI00M01079GF00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for sac-review@sac.sfbay.sun.com; Tue, 19 Feb 2008 10:19:40 -0800 (PST) Received: from wp668.local ([208.74.177.212]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWI00EGZ08CQNB0@fe-sfbay-09.sun.com> for sac-review@sac.sfbay.sun.com; Tue, 19 Feb 2008 10:19:29 -0800 (PST) Date: Tue, 19 Feb 2008 10:19:23 -0800 From: John Plocher Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47BB173F.4030809@sun.com> Sender: John.Plocher@sun.com To: John.Fischer@sun.com Cc: sac-review@sac.sfbay.sun.com, james hughes , Kathy Jenks Message-id: <47BB1DAB.1060901@Sun.Com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_hxYMqP35h8T6vDo0/4isLA)" References: <47BB173F.4030809@sun.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 88646 This is a multi-part message in MIME format. --Boundary_(ID_hxYMqP35h8T6vDo0/4isLA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT > We believed that the integration points were the most critical for us > and included security, installation and making a component sharable. I would add the following perspective, driven in part by the recent discussions around GPM and HAL (e.g., libpolkit and RBAC): There are things that Sun/Solaris has that differentiate it from other operating systems out there; things that we do not want to devalue, obscure or hide when we include FOSS projects that overlap in those spaces. This implies that, when FOSS things are introduced that reimplement or override or ignore the work Sun has done in those areas, that the team that is integrating or using the FOSS project be required to do [something, probably significant somethings] to ensure that the strategic Solaris features be used instead. A first pass list at the Solaris things that need to be chosen over "linux versions" each and every time there is a conflict would seem to be: Secure by default, auths, audit (already there) xVm zones / Solaris Containers PRM RBAC TX ZFS SMF FMA IPv6 IPsec SCF I'm sure there are more. -John --Boundary_(ID_hxYMqP35h8T6vDo0/4isLA) Content-type: image/jpeg; name="Attached Message Part" Content-transfer-encoding: BASE64 Content-disposition: inline; filename="Attached Message Part" /9j/4AAQSkZJRgABAQAAAQABAAD/7QAcUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAA AAD/2wBDAAICAgICAQICAgICAgIDAwYEAwMDAwcFBQQGCAcICAgHCAgJCg0LCQkM CggICw8LDA0ODg4OCQsQEQ8OEQ0ODg7/2wBDAQICAgMDAwYEBAYOCQgJDg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg7/wAAR CAKAAeADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL /8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0Kx wRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEB AQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygp KjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImK kpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD8e9WvLa3kjgvGVUkG7dnnNcvp +nadeXupqchQ2cjtV3xvZSyaXDcRggxdfpx/9auO0O9uLO/nYqxWaMjBHU9j9eDX x2Cw7eEc6ctf+CffVK3JVjTmrxev5o9L8N6fd6fq4BKS20kZww9R0zXokZ24zyQe RisLw83m+GLWRztbBGMcj1roY0YuGRmwDyPWvBxc3Kq2/QmceWdo7EkXTIGK8yvS E/ab03kkGJTzx/C1eoJkuMNlcZPHvXmOo4T9p3RD90GJB09nFdeWRXPJW3i9fuMM Q37tu57tBkqmCMe9aNv/AK/PDA4/D2qhEG4Y7gBxkdv85rRgwJSAz7gOeM5rOmro TfvJWNiHBUKQMBj/APrroLRRjAJ4FYcOSDuyXB644robL7yZPI4zjAroTdkzJ92d JajhcqAoHBArftxlB90ZHAJ4FYloR5a/MRn+VdDApwASTz6dK1jFJOxxylqrsvDg ZAznrUo5A4B47mowBjqRz2PSpo8DliQeK6VG97GfN0bJk2854z0Gf0qWPhgAQygd DUQLYBCkgcjBzipRw6sFO3PHHSi7te4VF2LKY3nJGB3qZcGPjHB7VAp4HepuvI4H bjrTadrM5rXVrFhRnByoXuGFebzHzfjhp4ZhtTzGIGegT/69eiZUkhvTt0FedbiP jrZ7ueJQO2fk/wDrV7OTpJVL/wAkvyPAzx+9QXTnR6qvrwTip4z3yvH4VWRs5IDc 8ZqwhOcAY9ia4Utkezo9tS9E21gPvDP41bXA7ZzVOIgAEA8jjjrVoMCoUkqR+taw RDjZbltMDJLZHY4qyrfvQpx+HAqohIB9PTtVhCCcnAA7VoloKL926LQwVwDSg/IC CDn1qBG3DOc8YqQEjpnFVqQlzak4K7hu5HtS4BI5IGc1AG4I+YcU9SRnJH881bRt JX0Jt3PIWnA/McsBnp6VEpJXOSTilycZzx1qo6WEt02SA/Pwcc8GjJx049qYSd27 tilDHb7davk1IfYfv4GOh5zTsn7wz+fJqLcNx6896cpJXGckHFUo21FfSxLuO/gA HsMUA5Gc8DpmmkksCzE470EggbS35VUVYFFsfkKMAg8800n5TnAyelNJZuhPrxQD xkfNnABNXFJMJNXFQgcZ6elPUqHIyQe2elRjIkPQc96chA6j8h1q3HS6IvokTHsT y3t1poUgYwuAO4p+Rk5LAdBt+lKDkkgMB70nB3Ro2t0Rc5O3PB5xTc44A2+pFWNu AB1yT2qM46cjr0FS2TyshGDuHIBHrxULhRkjkCrBLbe+Cew61C4G44G4VVktBNd0 Qc88D6elQ/fO0gVOScd8VGV5J4980mnsDV9hhBz26jv2qBsFxgD8BU+CMkc88jHN MA3P329z61TjdEzk27MVW3IQOx9arTfM3UdODV843YDAkeveqzAFm5yw6+mazaTd 7Ds+WxTO4D5cAZpp+ZixHHvUpQncuGHPSoypAYc5PWk1rqO/XoV5VUIBuxjoK5yT QtNPiD+1DZwG+xjztvIzxmtu7vbSxQte3EdvGe8jgCuUk8a+GzcrEmpxHB4x0/Ov Rw+AxVSLlRi7dbX2PGxuZYClJRrVIp32bV7m75ag4yVBJwTVS6s7eZleSGGSRfuM y5x+NTWl9aalCZIJ1lTuysDj2qd0cghSQB2rzqsZU3yvRndRqU6sOaNmmflvrMsE Ohs14pkhY7Xb0BrlkGlyX9jZJHHyvyvxk1v+KYGl8GzqpJwdxwPSvIdOW6jvrXUG Miwwy43g9hzivlcrwqqUJS5rNX/LQ+/xFadGUEle/wDnqfQmixLHZNGjAxRuVBPU V0CLtGCVKg8betcl4RnN5o81xldkkhCgdBjrXYgAE7fmHfn+VeRUg4tqXQurKPtL x1HIuAehGc4Jry3xAvlftH+HGxtV0jwQP9pxXrESkkbVxn36V5b4v2w/GvwpMVHz SRrn/tp/9euvLGo4hRXZ/kcuIUeW/mj3SMkqMHkir8XB3LwpxnPOKoQAkoSeCQRk dK1IeW+UfKB07D3pQ1WoN3TZtwIdqqAMZ4Ga6Kyy0ycDPf1rCtR8ijksD171u24+ XAzjPFaze5E421sdLaDbtA24J4BrooFHl4ONp7VgWQHmcHsAOK6OEKWVs5wMN2xX RQV7HBNJrUujAGVA45PepQuSSCvTndUariMjnH+eKlVTg5BPHfrXSmtWRyt2RKBh cjqDg5p6bg20gA/lmmKC3OSdx4p64Mw647981N9diHtoydVUDA4X1qVOVCn17Go1 wBnHv9TUyjMgHJPfHWrTvcxtZaDj+B57ivM76QQfG/T5WxiSUKpPfchFelk7VOQR j3rxvxXqUa+K7HUYSpa3mR2I4wEfP8s19Fw9SdWtOC6xa+8+X4nr+xpUpyduWUX9 z1PcEYHCrsz9aq3esWOnBmuJAD2GarLqNqbJ5Y5FYhCeteLW0Nz41+Jd/DJKY9Ot cEqHxnPr+VXlOVfWHOdZ8sIK7DNs6dCVOnQ96c3p/me2aV4r0rUb0wxToZARwHBx Wn/wkOmJe+S08YfsM182eNdHi8L+KNLutFnZXkByyHG1lI4985P5V6TZ+BZrrTIr +4nH2maISMxJ6kZr6GrkeX0qNOvKo1GadlbW60PnaPEOa1atTDwpJyptXd9NT2qC 5iniBjcN61ZMiRoXc7Vzz6180WfibU/DPxFg0wSvdWwlVXjLbtwPHy+ldf8AEjxX NYeRpls2RcQh3YHlOeOPWsf9Uq31qnSjK8Zq6floaw43w6wFWvONpU3ytefke0W1 3Dc27NC0bqG2sV7HvVosCcZGK+bfAHj2y0az1K11aZh51x5sbnuSDn+n517Jo/jL RdY1YWdrdxPclcqnc/SubNOHMVhK80oNxXU9DIuLMDjqNNuolOX2b637HYb+/HX8 6eDwTkcjjioA43ANgc9f/rVLnJIG4cdOleDa2h9UpK2hODgAnb+FLuBOfXmqzzLD CZJWEaL3JwKIbiO4TdC4kUnqDkGtVF8t7aCVSKlyt6v7yx3IzyO9LkAD5hz0qNdw bIAz6U8Nl8ckelNLqEpLZIkABA6Zz1p3TqAPXikHB77fSnFs4IOCB1pWuhJd0Lkg DoPrSZ4IOOfWlHK5BIOMH3oAOAT+laKLFGS3G4O/7wpS3rgY/Sgcv1xxTiMHk54q rO6QkroQYz2AHb1qVMYBBGRzg1Dgbcg/WpoioXOCSB+FWw5tEu5ZwNh5xQvJz94i mgE892xmnAdCcjPGDSuWvNDcNjGQTjnPamYG04YEY4I4qTGcnjHTOKYcBCMEr9On WhpcuolGyGtgIBu568VXbdvJOOe/9amcbY8EbsfpUbfNzznvSWis0K3vWIG5Yrx1 /CmY4PJqR+mFyfesnVzfL4bu20tEe+CHylYZ5rSlS55qN7XaIq1OSLla9uxoMAFA 6UwLhVDY9gD1rw6XX/iZYPuuNLlk7D/RMj8x/nioG+Ini+KzlaTRYGKqSsflOuT6 da+m/wBVMS1eFSDX+JHx742w0JWq0akf+3We6gkrwyls+lKQCdoAz6GuS8Ea7qHi TweNR1LS30qbftEZzh+AdwyB1zXX4z8xz6nivmsRhp0Ksqc90/U+swleFalGquq0 uVSoVsk8Hp61EyllIHTFWnGMtkjsAaY2dp64A4B7Vm423NHdqx5tr3gKHxB4nF9q GoXv2ZV2i3jcgfj6dK86fwhoT/Eq20mNZoLVVkEjK+TkYxnNfRIQ88Z74NeGa7pU 2rfEKext7uezkllkQyIcYyoOOPWvtOH8xrz54SqNRjHTy87H59xVlOGo+zq06KlK U03fq+12c1a3DeGvinDptheLeo8oDBTwAxA/Ove1RXTg8gfxevevA7r4Va9pey80 6+jvJovmwBhgfauv8H+LLufVF0XWAyXoBCsV5JHY1pxFgaOOoxr4SfO4L3uj9bHD wzjauV15YXG03TVSV49Yr+6n3Pz68R3QtvBl2yEGVRkH2ryq01FX0xbGNA8ZUs6+ p5r1vX7KS80G4RBlTAVJPHGK8ptdHuNMgh1V0Y24UhiP4TyPyr8ayd0fq8k976ep +/4yMlUhy/DbU9h8EWgg8HRMqsN8hOG7V3C7fN7fTHQ1xHgrURqXhYFX+aKT5h65 /wD1V3Cld2cEEjk8V42MdT28+ZdTeSi5PkenQcqjaSoXGc5ryX4h3KWHxA8KXj8K ku+TI7K6mvXFACjGcH8q8O+Lxxreix7SCIZCG9eQP6V25PT9rjI38/yPNx9Rwo3R 9JW7rJbI6cqyghgcHBrThA3bcAFe1cv4Xdn+HehvKSWNlFlmPJ+QV1sH30IyxPQD k1m4uM2rmqblext2gBAYBQvT0roLcYC5AOOAKw7XIbPAxx/9at+3jJACgtjGSRWq tdFVE0kup0NnxgHB9cGult8BN2Azd+a5q1BVwuByOPTFdLagkL168Y6mumnZLQ85 txlZmgnUZO0HH41MpDIcIVye1Q8hV2ryehqVWwu5gcHpXRGN1cTd1qThVAwADxwf WpFAx1we/HWkBywAGc9OKf6FsZ6VEFITskKqgEHIOPSpwRty5zn0FMUDaDjII6g9 akUcD361d7szbsBAeNumMfdryHx1oKWekrqEJBXzcMvQ85/OvXgfnySRXm3xE1m0 t/AN5E3MySpxj3r6HhurUhjqaj1av6bHyfFWHoTy6r7TdJ2OXstP15/D1vfwSzNb yRklRzkcjFcR4bvtWi8RarFphiWeXBbPUhSeK9t8EanZyfDCxhmcYKsGBPOCTivM te0i88P+NJdV0Jz5cjZwF+UgnOK/QMtxsatavhqsUnsrrR2fU/Os2y9UaOGxdOba suaz1V0tjpdH8I6hqGsxan4jnyImz8w4HfgV1finx7Zaf4ee102RZroKEjAbOBj/ AOtXmR1/xXr0SWVuq2yMNrMuSfwqprvgbUdHjtZoSbpZl3OxOSG711U8tp1cXB4+ orraK2OavmdWlgKn9nU3Z/FN7vpp/Wh0ehWsGl6XN4p8QTCSd/njVzkk9hWW9pqf i/8AtrxJcrJHaW8JaFSc4GeB/Or2i+Etb8U31p/aRMWnw4Cx/wAIH+PFe46xoQtv gzrGkaPCDMbJ0iUDBdsVpjM6pYTEQUZKVSTSb6RjdaL5bk5fkNXMMHKUouNKKbS6 ylbd/M8u+HnhLSvEWhahLeZLRyqFIxwCprn/ABNYDwN8bLOW2LC2j8qeMk4JGcMP zU/nXpfwc0rUtK8H6kNSikikmnUorDBwAR/Wuu8YeC7HxXbweeTHeQ8RTDrg9RXJ PiKNHOasa0+ajK67rVLY9Ojwo6+RUJUIKNeNnfZuz6nl3xA+IV0dZgj8NXQ8mIb5 ZE5PqP8A69dx4N+Jel61oMMepTwWeqIMSK5AD47j2pfDnw10nR4pftSJeyyqUIcZ AB+tYuqfBbSLm9kmsLiW1Qkt5Z4C/Q965q2MyCrSWGacVHaaWr73O+hgeJaNZ4u6 k57wvou1jK+JXjpbh7fR9GvlMbIWuZY269QFyP1rrPhQ0lt4Ene6mAieUGEM31zj 9K5PUPgoDog+wak325Dkbx8rD61hW/wz+IccS2a6m9vaqfupMVH5A8V605ZLiMsW DpV1DW7bWrseRRw2fYfOXj61BzbTSSeiPoHUPF2gaSo+26nbQEn7rONx+g71ykvx d8Kxz+XFJPOMjlIzjmvIfEfwr1PR/BFzq0l9Ne3yFSY1BcnJ5JPtXnuj6RfQrLFN ZTTzzKAgwRsOc5xitcp4UyavQdVVXNLTexjnfGWe4ar7N01B6NK3M/vPuDRdasNc 0NL7T51mhJxjoR7GtoA57A44rzX4baDd6H4PlN4piluXDCI/wgA/4mvSQO4P09a/ Os0oUKWLnTou8U9GfqmSV69fBUqmIjabV2vM5/XfFOg+G4YX1u/gsvOJ8oNyXx6A c1sadf2eraPBf6fNHdWkybo5FPDCuR8ZeAtL8Z29qbySe2urXIgni5Kg4yCO44H5 V0Hh3Q7bw/4TtNJtGkeKFTgt1OTW1SGCWCg4N+1vquliKcsf9dmqkY+yt7rW9/M2 MjAzjNKASM5ApwGM/LwegJpAAeCOvXmuBI9OC7jRgsehB70qHA4wP6UvPOc/jQmC 3Oe/XtVxivvJbtpYsZyWHGO3tTlZSi5xjHekj25JbJb19qlyGztpSWljSMXIj3AM CMAjpzTOkgyV5PPtSsAI+wBOQAKOBKuQSO+e4qbX0JjO61RGzfvOcZNQsM5/h9qt McN8uM9OKimUY3DIyaiN9HcS3K+QcYwKjP3ySCc9BVhVBbncOO1RsoDndn5f0qrl Jvvci52kE+31ppUFP4D7YqXqo25PpimsSchckdRWkexE9EM49OlN28jHQVIS2c4I we/elyfLbPOeRk1L1YR1ehBtJj2nk+tMIzhsn0AFWCMHgnnt2pjqMZC4XPTFJu5S g0ykU2gDvXlGqyx2nxett4+ZrlGPbgrjNevHOeMk9jiuK8SeE31rxBZ38N0LSSIY YhckkEFT/OvWyfEUaNWSq/DKLXzPAz/A1sTRj7DWUZJ/JbkeoeMtA07xUNHub2JL xYTNIvaMDpk+p9K8Z06eXxV+0It5p0JisY5Q7MOCEHc/XH616ZrXwx0fWfFUurGe eCaVR52wDkjj9f6V1ui+HtL8P6cYNNt/LVwC8h5Z/qa9WjmGX4HDS+r3lUnHld9l ff8A4B4WIyjMsxxsPrTjGjTlzJLd22/4PqfmXeusUBklP7v3GRiuD8T6ig05NPtS jiT+DGc10nipnj8JTupYnymGe1eRaS10PElnfXIaSFeAz8gj0r8cyfBxnD2zfw9O 5+1YupKPLGP2j1vwFZiy067jAZJNwLKe3X9a9GQEvkHI6/WuY0IQzXE97A+C/DIP wrqY8kEsAVA5NcGKrOpNyfU2qxhzpR2JOdhOPx9K8N+Lyga5ojKoGYXB/Ar/AI17 sNuzBDgk456V4p8YYzs8Pz9cmdSf+/ZH9a9HI3/tkHbv+TPLzKDdByv2PcvCOwfD zQsAHFhCRn0KLXXW+d6DORXDeCHWb4WaC+NyixjXJ6fKAD/Ku6t1AmJx0GTjgGsa rtVkrdTaDemhu220uo7fzro7cHcPm6DtWDbbfLBf5Rnp1Fb1tt8zPJ9sURlaWhdT RO5uQAecoPIPvXSW4JxhsY7561zluuFBPAA79q3rVssPvZH5YrsoyS0PPl2e5rAE rwMj19KlQA4LLx0Jzjmogv7sHGO+alUjcN2cHrz0rZS6IzUCyuQpJGDj5s9alwpf Jz06E1ArKc7WBJ9etPBXG4YHocdaOW9xydkWgoHJ5GOlOwOfT3qFDuxnJqUcZwef T0qqadyajTjckKgHls81xmteEbPWruWW5kZ1k5dT0+n8q7ZlwDtxjPPrTCrdQCOO mOtduGxdWhPmpuzPOxODpYmPLUjdHCw+CY7e2EUF0YgoxtxjFWf+ENlktyv2xZAe CG5FdsuzzA2MFj61Os0S8lsCvUWb4tu/NqeVUyXBKNnDQ4a38F3FrNvt7iJGB7Jj NXT4a1Z40R7tJIyc7W5rsRdRKu7Jznt2o+3xhm5znkA967o5tjpvmf5HC8ky6Pu2 382c1Bo2vQoghljVAeBnHFXks/Ea8Boz83rn0raGpueFQkj0FSfa7k9IX5bAwuav 69Xl8cV9xH1HCwVoOX3sxVi8SRqMRp19etTb/EiH/UK2ODz3/OtdJdQeQjyzk/3u lSCHUSQzMkYxxlq0jibp80Yi+p/yuf3mP9u8QofmsM49D0pV1/VUU+bprjHXAzke 1bq2N40TB7lRzkfSnnRyygyXblvQDHNUsVhnpKK/EbweMX8Ocl6tGCviqQFVkspU bPTHWtKLxErEFoHXPVttWzoNqSSzSs3u1WBoemoo/cbgP7zE5qpYnAW0gyqOEzJN t1SAazZzQsk20qeoccVVjn8O28pkWKyibdnIUcVsDR9OGNtlCPTinHStOZNv2OEq fUVlGvhkrK6v5nU8HjHZylG68ismvaVtwbqEcd3q0mu6QxG28gBx/exmqj+HNHlk y9lGT6gmqkngvQ5v+XaROx2ymrSy5y15l9zB/wBqJe7yv70dAmp2DBdt5bev+sH+ NSQ3ttLcNHHNGzqOm7muTl8AaZJlY7i/iJHUOD1/CnWvgmzt2Ja91AgdPmAFaewy /kuqj+4wjXzVTSlTjb1f+R2uQWOcevSlAGVKZ+lcifC9xGc22ualEc8AncPypp0b xNCM2+vLKRwBPFxWdPDUHtV+9M6HjMWlrQ+5o7AnOT1FOTBQbgoJ6GuN2eNYWznT 70HjGcUC+8XxR/Po9tMx4+STim8tfSpF/Mn+1JRfvUpfdf8AI7bhTx26c9qn5EfA 3EjniuGj8Q67Cw+1+GLpcnqjbv5CrS+MrOKYre2V/Z5OP3kJxVTyqt0V/RplLOsN q5tx9U1b8DrXG0Zxkj8KaANo5Bz/AIVlWuv6Re7Vg1CB2JwF3BT9MGtcFSoKkAHo a4quHnB+9Gx3UMVTqP3JJjNozyoGBkccUBcxFWxg9wetSqOSMAnHOaa2fMxtbHrW SiranQlay6ldECzY6HvkVHKAJB0z35qyNxkYANuzVZkboBlvpQ21sTHskQEEMRgH 3zTSvb3wak2jBHJ5pCCzk42jPHrV2RN9AVcYBxjPOetN9xyO1OAIGCMj86BwMDdU yStqVFWGFcN1B45OKjKDYRngfmKmYcYOcDrxUZX5sj+VJ+YtthpyU+T1z9aib7wy eQc8+lTc4OKNoLcgHn8actXqLm100KxXBOVqEqdoAAzx06Vb25lwDkHtTCAZNqgg 9cj61mK1kflBrKW8vhu7jm5HlnOOoGOfyrkLZdLR7LRzCkgIGG4zmtXxfeLY6Cz5 K+bEUzn1GP615Bot9cxeJLO7naR404BbkHHQV8ZlmBnVw0p3tv8AefZ18TGhUhHd v8D6C0SxWwu3ELF4CfXoa6mPJ4JCjd61h6A5m0YXBBMcvzIc9q3No8xeoB/xrzJR vJczLqxXtNH/AEydQpUZHOOh715P8XFR/CGnSBQGW8wpHoUbP8hXqwyQOM45FeY/ Fkk+B7M9M3YB9/lNdWVe7i6fqcWPX7hryO2+Fs/m/B3SQ/zFS6AZ6AO2K9RtsZVd wKnqM9a8l+EoP/CobM7c/vpBkn/aNeuW6OJlIVl966MVGKxNR+bIpSkqcbdkdBb8 kIw53cgdK6C15kABBHpmudtnDEFcYyK6OzK7ySSTWMdWrlzmpWaN6DmQLkHGO3Fb VucSADPI9KyoduBzxgd614h8wC5GB1reD1ujmly82hp8+WOev6U9T8/3VPHX1qNF DDksozxx2ps1zHAufmZgMda66d5PlaMKlWPxNl8bMjgYzgj0+tTdvmIz644rmG1G Z3Kx9TxxUqi+nKnD9epNdDwjv7zscn1xO/KrnQfaIFP3waPtsQJ7rWXHYTsw8yTa O+B0q/Hp8IwJGZz2zWqhSj8RCqVpRtaw9dRJOUAwRwRVdri5kViqOcDI2j9K01ih R8IqgD04p7H5H5IyDxirVaF/diYVKNTld5bJnM6HfS6zZLLGygFdw+bIxnB/lXUx 2LYAaXJIGf8A61efeCX8ox24zhbd+cYwPN4/nXpyZCkqMHHGK9LNI+wxMqcdEjys lqLE4ONSere4iWcJwH3Nz61djtIFKt5aYI9KI9wx94DPOKc9zDDMvmMEz6nrXPTn UlK0Xc9OVOlTjdl1I48AKqEY5yKtIRu/hA6VSmmitrN7h2ARV3FifauC8MeM5Nd8 d3mnLbt9nj3kzZyAARj867MNgK1ajUrLaG/+RwYjNcPh69KhN2lPZHP+LfFmq6B8 YrdHkWLS1MbuuPvJ/Ef5/lTfiF461TQPiVollp5i+xKiT3W7kOjNjH5Cn/F/Td9r pWphQV3NbzE+hGV/D73515j4tuXvtK8NXshLSvoqxMevzRSMp/pX6hkWW4TGUsLV dNP3ZRfr0froz8izvOcbgMTjKHO9Jxmv8L3XpqvuPsbgzffGM8EHrUZ2hGZiuB3J xVLSLg3nhPSro/M01rHIScc5UGvJfHPxBt4tMvdI0yRmvzJ5Tuv8I/i5/wA9a/PM tyjEY7E+yprZ2b6LXdn6lnWf4bLcJ9YqvdaLu7bHtkU0cudjq4x2OaeFCR9ttfLX wv8AE1/a/EqHT7i6kmtrzdCyyPkbsEqR6dx+NeyfEnxFNoXgqFbSTy728l8uMjqo xliPfFevjOFa1DMqeDi789mn5dfuszycBxnh8RlFTHzjbkumvPpZ+d0d/FdW8zMk cscjA9jVk4A3DGQfSvjuaw8W6Holj4rtLq5+yTSEhw5ypz1YZ5Br6K8CeM7fxd4Z V2KJqcKgXcOe/wDeA9DW2dcLywtJV6U+eF7NroyeHuMPr1X2GJp+zqNJxT6p66ef 6eh3S87ScZHvUgBP5UL14BJ7YNP5znBHcV8k37x9s7IlTaEOQCcYx2NLhduBgMOc 5pFAzzk+uO1ShcHcRwTxzWkbMHpYQhS2BjaO/wCVNA9t2TgU/ouVHy9/UUiABQSM ZParikRstBjKpYgcEY708AqDjhT3pMYyzAtggdelSoSVBxyfSnsLpruAjU7SVzn9 afww2OoZfQ9KUDnac4PoaFGWHBqk3fQG7WRh3vhvRb4kT6fb7zyHjG1s/hXM3mj6 1oB+06Hfz39pGMtZXB3HA9D3/nXonAXIJyBSMPlYkZNd+HzCrDRu67PU87F5ZQrJ tLll3WjOa0DxHaa7byCNWguosCaB+qn29RW/IQULKvPqK8w8VWk2g+J7LxHpwKq8 mLhBwC3+BGa9IsrpL3TIrqPOyVAwB9xW2ZYanCnGvR+CfTqn1RxZRmFWdSeFru9S Fte6ez/zJ8hsqVweuc1WfAdCOasHhyvUqPxqEg7O6nHQjtXkN9j3U1cgC5lIzjPU 5ppOF28ZqYoQeT0xwaaR8m48c8c0423Y5J7DBt8vH9KTHJwTjHFTFDn5sYxyR2po 6g8H0p8t3cFpoRbcYJxg0jDLkgc+1SkcE4PHU0zOTncMdCKSV9exDa2uRkYfOOKZ sAZnzg+mfxqQjLDC4z7UP0AJ69OKnmdyhmVJyoGMZzTNq43HGPXNOwFGSeKRhmPj HBqGrPQlydnc/Gb4gWs9xDYQwbiC3zKOf89a1rfQNLHhW3sXiUOicv33HrWp4icR 6G8ixLJPEpZQw545/pXma+KZLi90pC+CJQJAB718ThY4jEYaMaeii2fZ+zoQfPPe Wx7L4ehFpoEdgzE+UTsJ7iuiXjuD7+1YulTW9wrPGxJ3Fc9iK3FIEYx0PQV5TUpS bm9TStFRm7EgOW5Y+pJPSvMfisAPANoQcZvF4P0avTU6kFCVOeteU/FuR18J6dGB hHuifyU16OVxbxVO/c4MZ/AbO4+Emf8AhUFkuBkySFT/AMDavWbdgWCEeufQ15X8 L4BF8HdIYnhi5/N2/wA/hXqUB/frjOM+uT71vjdMRO/d/mKi/cj6I3rbIuBnGSea 6O0yswUnJJ47VzEDp5gGMnOTkd66e03NOG/h71hfZmjS5brc6e3BEY+6cHHNa0PG STxjPSsmADY2OgPzVrQEMxOABnqa6IXWjOKq9WaA4BGe/wCVUvsJkuS8jbI9x2ir sR68N6D2qdB8wznBycGuunUlTbb0MnSjPRogit7eFR5cS8HkgdquLIRgKRj/AGjU HQfdPvz1pykHrkMB1FR7S+j1NYq3kW4yWXkYYd8VKhG4YPJHaqkXDYIbaetWc4GR yD0rVxuYrWxMxBb5flPvUUrMkbnO4BTkmnjAXP8AF7dKbMwFvKeo2mtaTacexzVt abZwHgiQNfuDtIFoQcnP/LSvVIRhR2yOxryjwAdt5OnBAt+Pf569TQDhVPHQg9a9 7Po/7dNeh85ww75dTa8/zL8YGQc/rXFeNbHUJrGK5snkHl5LhWx9M+1djEG3KNxz 6muR8XeLrXw9ELSUh7uWMmKPqWHfiqyKNb65BUVzPt5dQ4gdBYCo8Q+WPfzPLtQ8 c6jc+DxpTEi437TLn7y9K9h8A+Gv7B8L+bKP9MucPKSOR7V4CPDer3PhiXWBbMYh ISqAZKjrXs3w/wDHo167Gj3kbxanDESSRgOBjmvvOIqEY4HkwduRO87d+nyufm3B depLM+fME/aSilC/b/M6fx7pp1P4WalGibp4UEyYHOUOSPyzXyTcXbyXENuX3RxI xjx2DEEj8wT+Nfc5RZImR13KwwQRnINfNmq/CbVT8Q5hZBRpc0g2P02KT/StOA87 w2Gpzo15cqXvL7rNHV4gcNYnF4mniMPHmbXK0vW6b/rofQXhhXX4baAhdg406IEH t8g/WvkXxKZI/iPq8DoyyLeSEjucsRX2laQC10yK3VcLGgRcDGAABXi+s/C651H4 ySaykyrp086SSqeoxjd+o/WuHhLO8Pg8TiJVnZSV16pvT8T0uOOHMTj8NhY0Vfld n6NJX+VjzO/0yTwd8V9MkAKoiW90ue/3dw/MN+ddJ491GXxh8W7Kw03M9pAqxRlO d7vgsfywPwNe3eKPBmneKbaL7T+4uIeIpUAyB6fSq/hj4fab4buRco73FwPuO3b3 r1IcW4SVGGJmr14RcfLW2p5NTgrHqvUwlNpYac1J90lfS39bHRw6HZf8IVDok8Sy 2YthE6N/EMYNfOd/pGqfDb4jR31mzHTnfETk4V1/uNX1T0BHfGKxPEXh3TvEfh19 N1SNpLYsGG1sFSO4NfM5Dn88HVnGr70Kl+ZevU+y4k4ZhmGHg6L5KtO3LLta2noS aFqsOueG7bUrc/uplOOfukHBH55rbUIVxht1Zeh6PY6D4attM02JoreEfIDz1OSf zNawJLZ+7789a8Ou6bqzcFaN3Y+kwsakaEFUd5WV3521FSP5yM5GeeOalAAO3Jbu eaRCduDnk9euKXIyygnislF3sjbmirWHbcFlz8p96XYvH3WH1pFwAeCc0uGyM9Dx xVJXFdcuwgAYZycccUqYIzyB6GnEkKwHUccmlRtw5zntmqS01JdtEhwRg24A4x69 KQg7/m2+3vUjcKcHB96NpOCO/rVN2WgNjSvUnHtzTQDnaOgH51IuCxYAg9/WlI+X 0GOKOlxK7scv4stBfeAL9du50j8xBjuvI/rVHwVcef4KjVmcmNyBnsDyP511t1Es tjNEwJ3KRgHrmvP/AAIDHZXMDA/KADxyCrEV7dD3ssqR/lkn958zXi6Wd0al/jg1 9z/4J6BgeZyw6dDUW0FeUIx71KxIbqASM00dThWYHnjpXhL1Pp7LYiIGPmYc9+9Q yJzhuPWrLKCfmXHPc1GRk8jnqfpTjFrcJOTIj3POO9KhQMCwxmpGAyoBZW7D1qMj oTx/KhFO97IZOu6CQK4DkHHpn1rx69s/HGiapJNp8h1C1dySN2736GvYt3HzHH40 3ALjOcCvTy7MJYVv3VJPo1c8PN8np45RfPKMls4ux4+nj3X45fLu/C956ZCEZ+gx Tx8QNcnZFt/CN/I+PUn+let7eNxOT9etH/LPjjPvjFdzzbBrVYWN/VnAskx3XGSt 6I8ps9T+Imq67Fu0mx0fTM/PJcElsew716gigQKGcMwHJqRgc4596GT5en5V42Ox SrTTUFFeR6+BwTw8GnNzfdv+rH42eNr+O104RxkCR0KMpHODXmuneG7+70iW/h+U ROCPU16FrHh+fVvGp8wOLRQHLGi11+1062utNEaRvbSBTkjDCviMHiZUMMoUNZOz Z99W5a8lKroo6I6PwA0sfhmWO5Ennm4bIYewx/OvQE5lIbtXL6bcB72DaoQtF5hw OucGupXhiexHWvCrTlOpKdrX1sb1I2mk99NyRANp4x9Oa8e+L0mNL0ePjcZnYn0w AP6/pXsAJKKCW6968Q+LzE6hoi8kCOQ4xxyV6V6OSycsbTTXf8jz8fL9w7HsPw4Q L8HtEUqpBh3YPuzf416JETuXG0Op4IrhfAihfhNofDD/AEROQO+P/r13CLtZcZJH c/zqKk+avP1ZUI3svI3YeGOeGzXUWLEScEjjiuUtySo6bQcgeldTZEGUbgR3OP1p LW3kayjaOh1MB/djB59Aa14CwTjHPbFZFtnylbgA9Djmte3+4Q2ST1zW6be5xTVm aCDI6kr2JqwgAYjALDoc9aqKMxgHO31xirCMoIIyWHOc8VqpNNNmUZ3klceRuJGB jOQcUKo80hiMdx0pxfP3h8xzxSLksTntznrSem5SasWF4XaOD7U/kA8gj1Paog2R 1YcA9amByuQCfc45rpitbMhj88A9PQUMcxMcn8qaCBgnpntTnVivGcMvcVrFps55 xfI1c4DwMnl6pdAngxHgDH8Yr1CLO4Akg+h9a838HqYtYnAU7jG+ATnGJB0r02Pc cDJBBz619BnkubGy+X5HznDUIxy6EV5/mWouVOeSDWRqXhnStb1O1vb63ElzApEZ AHIOOK2EXGc889cVdUhVBxhcZFcFCtOnPmg2n5Hq1aUKseWaTXmRw2ltHZC3SKMQ AbfLxkYqvYaBpGm6i13ZWcMFw/VkGP0rRj4ycAk9fepy8aH5mA9ea1hVqWaTeu/m RKnC6k0tNiePGFJJyetSqoOO/PPeq8bBlBDBh19atAYAGCRnoatJrQuKT1JlzuC8 DA6U7B3ggAY680xBhyxHPvU3BYZ6nnrSW1y5a6NjhwMgjOc8VOMlc+veo04BJ55q bbg8MVGM/jVRitB7IUhAvQg+mOlIwDJzgnHengFk+ZugzzSfwE4ORzVJWdxuaYic J747VIAoYjGfbPem4wMAtnoOf61INxTkDp1zVyWpN03oPUDO1cY60FQGKhtpPSnI BgZPPangZDZHbk1SVrNkys0NAOTnjBpy4BIwOaADt7/WlA475zwapWv5iW4cHqOv ek2gEsQPb1peQBkn14pw4J6cetXG+oNJ6DgAeeOec5p3AIHQ9/SjgAY60gGOCSeO tWo2VtxSkhNq7SQQTTsZ5zge3rQQQRyRnrSjBjyMYHFT8Og4NXGMBtPc+hFeeeE4 /K17VEPyETyjGOg3Zr0M5IbkgdiK4Pw9uHjDWUJ+7eSAD24NevgZf7LXj6fqfP5o v9uwsrdZL8P+AdsU+Udx0JpgAVvmIBI5xUj5HzEnGOwqFSwGWyOeOeleTF23Pdnu KwxwcsM1ESPLOTwfU55qWQqUGSdwP40x0LFCwPvgUNdWVcYB+7VSQ3I6U3gSH5gc ZxQxxknPNMDAOdufakuXYq2zQ1uvyADPqKbznB5Bpe5x1J4/KgH5MnJB459aFHUj RscR8/bA44oAA64x1xRySQc/41GWbbjBPpz0pWsKc0ugjHB/kBTTjr1H9aaCNwOB +VIcqp5J4/OplLoSl5n5N6vP5Ph68lABdIiVIPt/jXz5JbXeo6vczxozuzhmx6mv eNezNpE1shwssDYYDHOO1eP6XrAN1pNoiDzfPVZOOozXyGQc8KU5RV3+n9I+vxkY 8sI1NL6/oeteD4JJdHtJpi4eBTEyP1OOK79CAQxHbtWFpZhF3cxxrsCv90dPr+lb q8rkZBxyK8apU55uTW/Q3xCkppdidOQnzYOa8H+Lj58Q6TGOggZsY9W/+tXu6BmG 5gOOmRXg3xYyfG+lL97/AETP/j7V6uQ2+tp+p52YXdFI908EA/8ACrPD5YhSLNMk /Su2j6gZzzgVz+i2v2XQbK3XlYoEQe2AK34s+YEC9uc8VxTadSTXdm8OZbmxaNtA HAOTk11Vk3zqdx6ZzXIwAo6fKAc447V1VgzFk2jOB36U3Jc12E4tRZ1lscRqC3Of wrZtQSw6Y7nFYtv/AKgMd2M1sWmTlQWA7Zrek9G0cVSTTSNBSc9atrn5mXoR1xVV WweVA6dKtAhgM5CDt6Vu3YUVpcaD8y7yuM80v7v5vcYFNZfnIGTTMrsPJBqIXSbY 3ZInU4c7QGGKtqPk4IPHOfWqkTcZOScVdQ8DAP09RW8NrENLlFCgFmHr3p/BTHGR 608A5XIODSYyvAy+fTrXQtTKSstjk/DkZTxLIG4JWUdOuJBn+dehqu3BYdcAnvXE 6IAviIqwy5ebk/72a7uPJXGCR7ivazZp4i9jwckgoYXlXd/iSJwxXAxnNSTTJDp8 k7sAsYJJ9AByajjx5oBB96mnt47nTHtpN/lOpUgc8HiuWk43SkdtdSUJcm/S/wCB 5nqvxOsLZDFYZu5OwhGa4a88R+Lr6G4v0D2NpEhc4HOMdOf8816pa+BvD+lP57wL sTkArjFeX+NvEzaxqB8LeGYA6F9srRfxn047etfqGQ/UalRLDUbxXxSl0R+RcS0c xhSvjMRaT0jCGl3087HU/CXxLqurarqVhfSvcxxwrKkjD5gd2Nv+fSvd1yISWGRj sa898A+Ek8LeE9jhX1Gc75nA/Ja75pBHGSzBTt6Z618pxBiKGJzGc8PG0fL8/mff cNYWvg8tp08TJudne776pfIsKTt5wMHvUoPIORu7Yr5j1r4neIW1+6FgsVvbRSMi BwSxwTg1a034p+JNNlgfWrFZ7OQA71G0geozwa9mXAuPVNTurvpc+cj4k5ZOq4Wl Zdbaevex9NjG0jkEHvUm0bD69q88j+ImgyeB5dWhuA4QhTCeH3Htisjwj8T4dc8V f2ZfWxtDIx+zybxz6A+9eVHhrMfZTqezdob/AC3PeqcX5Uq9Kj7VN1Nvntftc9cj XccNmphjaMjnHHNJuw5wTn/ZqO5uIbTT5bi5lSGONSzOzYAHXrXkQhOUlGKuz6Kp UjCDlJ2SHqFZyCx3DipgBjA6djWFo+u6VrltLcaVdJcxxvtk2n7vHGfStpMsOeDW tShOlNwqJprdMjD4inXpRqU5Xi9mtmSZwcsABTwpyR2PSkXG7HOT3xUg6nqKyT93 Y1erAn5uePejj3H06Uqj5jyce9OUtlSGPTpWqTadxNsa2M4ANKuM5JApTjB4JNAQ j7wyKrl00E+45cGMc5Wl4JHQ4pV4AHJI6Zp2MEgg0+o+W6IwMsxORj170oHXB2j2 qQ+v86aep5/D1pSegoqzIhynOevPFcPoQz4y1hlwQLpwcHvgc13jLjd1AI4rhfDo J8Sawy5OLyTJP0Fepgf92rvyX5ng5ndYvCrzf5HZnOzqOvNMJGCMj3zUgztPH05p hOIun/1q829j3OYi2jBzyPT0qKQ/u/mIzjrVsqOBjknr6VXZP3QXg+1So6MpvlKj EHvjn1pmOdxOSRjip/LOMc4HBJprRlcHnpUqKQKduhABnJ6jtxSchsgjFS7cKQwI OKacAE8jBpvRoTWgzf1BB3E0b8qBtIP0oAYsw5xRnMmCT9Kp62Rk7pCMQXAK4OM5 9KhKkDnG3171KcknIx/SoyScHJPtWXLroNu25+SevlE8PXdwMCeGB2jx34z/AErx uy0SY6VFq0HmC4jmD4HcZ6j8q9Q8WX32Hw8HyCElVZUHJZWODT4Y7GCW3sbeZcvh VUHjFfC5fiKmGw/ur4n+C3/M+ylGnOX7z7Oy/wAjpdAliuLFbsBxPMgMhPQmujQ7 ZAMD1HesbTrMW5RlKsoByAK2lySBnOR6YxXmOonNyRUm92x6EZPYnoDXiPxDiNz8 ZPD1swASWKJfb5pWBr3FAzsMfKwPYV5R8QkW38deDb11Ct9pILEdleM/l81epkjU MUl5P8jjxi5oJvue5W7hY14YLjGM81pQZNxG6hSMdutUIDyBheeDx71cgI8zjIxz 06VyqK502aRlrZs3LZiWORnnOOldJZZJ7YHTnANcvAwzgyEnPpkmujsm+Rc59a1d t3sXUklF31OytiPJ28Yzz6VuQEAAcEk84PNc/bsfJAGRn1rZjY9MYPatqd1ocE5P l2NI7d4OMjPerStlcHGAPTiqoyMHII9u9WFyFABwCckAV0LR7GcZNIlbBdW9Tk47 U0IDHt289aV5GIXHpxzUglTG3ABA44oS96y2NJvljYckTjaAM+uaujIPzHHpREUz wc5qdUBYHJPP5Vq09zLndiInIBIyKnRSwGeU70/YrY+ZQM49KcPkfaDkdxnpWqVk Z3vucrpiCPxYB8pCyzAE+td5GPl7n69q4qBtnjBW5+a4YAZx1XNdsuWXA6d+a9jM Zc04yfVfqzwsn92lKHZsmGAwfGeOKtpjy88HB4qsAWyowD6Yq3GPlX5jkd65YWse lJs+d/iL40vZ9VutFsy9tFE5SVweSfQUvgPWPB2g6bHcXUsR1UrmSRs/L9M17Tfe E9G1K6ee7tAzucsw6k1m/wDCuvDUjY+ynbnkcf4V+jUeIMseXxwrg4rrbqfl0+F8 5hmM8ZGpGbe3NfRdLehTm+KHhyK33RzmZhyFRST+leb6x4z1fxP4qs7XR55LGKSQ Rw84JJOMn26V7DZ+A/DluAVsUJDd+lcZ4r+HF3P4nh1Lw4yWbDHyD5drLjDD8hXR kWMySnXdk07O0papP0MOIcs4jr4aPNNSV1eMNG16mD8QdM06wtNDt7d0OqsmLnyw PmwACeO5NeseG/D9pqnwi0qz1m0SdxAVBZfmAzxg/TFc1oPw2nXVBf8AiC9k1G6O M7j2HavZoY0igSJRtVRgADoK4s+zqn9WpYahUcnB3cttddvvPT4c4bqrHV8Ziaag qiSUPLTfzdj5i1z4balpXjWOPTUludNf50fuD6Gt3xF8L9Wt49P1Pw4zm9WBTPCD tYSDncv+FfRC8ZBOR+hqRCS2DkEH6Uf685g/Zt293R/3vU2fhzlKdXR++7r+76Hz rbav8W4FjtzpolZTtDSRHP1zVfVPDXxH1nQL691i6dY4oWkFqrffIGcYHXp0NfTJ +9jJznsKRs7D3HoamlxfOnJTp0IRd90tSqnAdCrTcKuIqTVnvLT7j5w+EHiSwsZ7 /Rr6Rbae4dZIWc4VyAQV+vI/Wvo5JEkUOpBGOMHmvHfEvwj0/VNSlvtKuzplzIxZ o9uUz61zcPgH4kacPJ0/xCZYVGFH2g9PYHNenmsMpzas8TCv7OUrXjJPe1tGebk1 TPMlwywk8N7WEb8sotXte+qZ9FDHl/LjGO3pTkdH5VlfA7V8/r4X+LH2Vo21ptrL 1M4yOPpXSfDrwZ4n8Pa7dXOtaxJdWzRFVtxMzhmJHzHPfivJxWTYSjQlNYqMmtkk 9T28Dn+YYjEQpywUoRe7bWn+Z6/k7m46elKCSFXGOOB6UvLHIFOXkc8HHFfPJ+Z9 Y0De2ePWkGQcn15pzAgAjk9qcMnrkk1aSWxTV2NK556Y9DT8EHAHHv1pxYE4IOPU UoBPAz14x3okwavsR4xzz7igZJ+73pxyFHAzUgIA3Ecn3qbaAmtiFvu5fOccCuH8 LkyX+psVUA3khGD15Fd0+3Zkk8e1cX4T4hunH8dxKx+u7FenhtMJWffl/U8PGxbz DD+XN+SOtCg8jHHQUoUbiSBjpUnGMgn159KbkPHjNeYlrqj2nYjK4kB+U881DKNy sAvQcc1YxjOO1QSdD1IHtintqTLVFb7rZIznrSKR5hX+HsSeKVlIRRypye1MBI3E Kpx3xQ1fUn4RWGUJIHI455FQ4ByQOP5+9BIKdSTnn2pC21ACWAByOcVafUU5dRrA kcFcN0zxUfQADB+tO35OSAcUwkMp29OwFLlbSZLmm3YaV/dMMH05pp24Ixz1z2px Gec7TTc5J64A4zSe4otRij8XPiC032WCNQTHcLjgdWBBxXF6K1//AMJVaLPJIm3k b+2Bkfyr2PxHpsV7Z2lxNu220ocAdCB1rza81S1tvEF4XhUSRKjW7AfNgjp+tfH5 ViefC+yjG71/yPtalNykq03ZKy/U9Y0HUZJNIBcfMHIGe4rqopPMtwxwDt5Ga5jT Ht3s7NiV3zxB1C8dRk10sZUIoVCQOpzzXzUofvW7WOjE1E5XXUtLwAAAOM4FeTfF gbbDQLlRteOWQA/UIR/6DXrEZ+UbTkjoK8x+LK58D6e5IyL0duuUb/CvXy2MvrcJ dP8AgHl15fu2e4QsgQ7QGI74/KraEApgfMOnvWRpsqT6JaTDIDwKwI75UGtKIqJ+ Tu44x1zWWqlaxtF2V7G1BtygIy3fjnFdDZsBtOB7Z5rl4HO5SR8p5rpLM5wMcHnH Sqsrag7SWm52cBzGucHJzn1rbh6lsgDH51zVo2bbGRnPFblqxOBkE46VpBatnLVf Q2Q2TnOAR3qwrAqOQB6ZqiDhsJjnuamVsIC3OecE12N21ZjC7LTsCFYHv60xG3Me Vz9eaQFtgJY8c8D/AD6VCrBZWySMnrSjpK5UmlHRbm3Cx2HB5HIq+hHPzAdweuax opuMEkH+dXFlwRkYyORnGKtO7Mk9LI01KqA2eaeHUli2COhzVFZtrAA4GPWnpJud sHOKpJB5GGwx46DMS2btcHrkFMV3MeA46rnuK8/mkI8ZAHJZJIWBwO5I/pXdqSJF 3EgH1r2sarqm32R4GVuPNVS/mf8AX4F/IIJBGe1WYxwOgA9KrpnIzzg9qsoGwATx jtXHCXY9S29ywOAOOPSpFzg9PrUDOqRMznCgZLE9q4PVfE1xNqX2LSF8yU5G/GBX qYHAVcVK0Ft16I8jMs1oYGCdR3b2S3Z6MJYUxudEJ/2qnikjkUBGWQV4xN4Z8W6k u+XUZoMjgIwUc1zN8/jPwTqFtdT6hJdWcjbUDnKk9SPyr6bC8N0a79nTxCc+iPls VxfisLH21bCSVJbvTT5H0yAQQRjI6VMoAydoPHSuf8OazDrvg+11SJSiyAhl9CCQ RXPeJfHtnotybG0jN9fnjy07Htk14lLKsVXxEqEY+9HR+Vj6TF59gcNhI4qpUtCS Vu7utLHpCYDjPY5xmn7VDMFXAx0NfO9x468c29udRl0+KGxyOWQ9Pr/9avWfBXie PxT4Ze9KeVcQSeXMueAcA8e1ejmPDeLwmH9vJpxvbR3PNynjHB4/FfVYKUZ2vaSt dHaclzkginA8cYx2qvLPBAQ8siRKRjLHGasKyvEGVgVxwR3FeLyySu1ofUxmm2r6 oQbXbGBj0NOAO7oMfWl7456U7oQe2Kq+ug7C4HllQM09cAdAcCmLjBx6dqXDZA65 9atXW5L2TQ5Rx6U4D5+gP0pR16/l0pSMA4Bpxu2VaysGCQc4zn1p6IGB55prZwep 59KVcBeuDVp9yNBxxnacA5/AUuAVJ5AHTml3qI8HdjFKhDRAYJPcAURsxzdm7DOg 6cjr3oxuXkggdcVyniHxlpOgsYZZ0uNRIylrGw3H0LegpPCV1q2p2VzqmovGYbhv 9GhUECNR3/GvQnldeFD29RcsXtfr6HjQzrC1cX9VpPmkrt22Xq/0OomIFq3GCB0/ CuQ8IKTofmggFmY5x6tXV3svl6RcykFgsLEAnHaue8IoB4VhOOdueT7nirw+mCqe bX5MjELmzOku0ZfodPtG4lsfXNMGAMYwBU2GPzADr09KjGMZ/hzzivL5tT2+TQYQ QxyKrSkrlhgkDJzVnkuMHqeAKpz/ACuwwcY6+vtVcqexLbSSIN2VZtwJzwKjDBpE B25Pv1pj4DHrnucU37uMZ61Sium5mxxI3HGNv1rGute0W1u5La51OxgnX7ySShSt afG05JFcfrXg7TdWvJZ2Aimbgny1P8xXdgqeGlP9+2l5Hm5lUxcKV8NFN+bL8vir w7Hw2r2J4zhJgx/SsG9+IvhWzVvM1NXIGTsRiKxx8KdMdwZ9Su5McgIipV+D4ZeF YiHns5b0f3Z5CR+I717vsshhvKcvuR8xKXE9WyUacV53ZveG/FOm+KdMnu9M81oY pNjM6Fea6Jjjk5P1qtZ2Npp2nJa2FtHa26/djjTAH5VbYKCOSR2Ar5nFSpyqSdNW j0Pq8JCrGjFVZc0luz8orn5tLugv/PJjjHtXz99hu9bvry7jDOE5LEdu38q96u5C ti5Y/JsIc46VxNs1l4f0WOPzFkEjHLAj5uTX5vlGJlRhNwV5O1v1P0KtQ548s5Wj +vQ6rR7djZ6JOsm7yrdVcnqxxg12akMMAEDH51ytiQ1vB5ShflDKvt1rowRvQfMe 4welcXM5yd/MMTHSKLqsM55AJ4rzv4qoX+Hds6Y2peoWwf8AZYV3+/HTOcZNcT8S cN8KLhsHKTxkZ4z82M/rXoZc28RBrujzKtvZu/Y7/wAMyeb4B0OUAAvp8LED1Ma1 0SsfNGNvJ6A1xXgudpfhfoZQ5xZon5fL+XFddE2JgwIH+6amtC1a3maRmuWxuQdg zY56kV0FlJlxgBQD9ea5u3YsuO5PQd63rUjqTj1J6mkkm7+Ru20rJHZWLEwkNnPW t+1fG37vvjqa5uxYlT1z2NdHaMoA5PTBrSCWyOWoleyNE4MhYevGalRiB1VT64qs QccE4I6GpkGGXO5ea6LtNIwjPVovQoz8sRx2NRSBROycA44OM/rU6YCZVSCfUc1T dSHJZdvPX+lOcFH4mLnu0rFy3I83HG49K2FBIzgDHXBrHsyCyHDcHoa148MwHPHX Jro5U9SVzWu+hG5UTEADGO/c0KzLJuJXHcU24GJQRz+NB3GFsDnbyMUodERK19jF v2x4n8xcAhInwfRXz/Wu/YAptymeq151qjj7aHGQwtSoP0YGvRRtCq6kgEfgK9jF aUaT/roeJgdK9ePZ3/MuRP8AKMlcY6Gr8eNoI+nSs6Lpls7Qa0UHQjpXMrI9R3vc pa1DPP4YuYbU/vXAXI9D1r551vU9R8MfEjTkGYreIRzMGGd67uf5GvpxRwMnP1rw r40aYN2jakiHLb7eU9+zL/7NX3fBGKpPFLCVEuWaf32/4B+ceIGXy+p/Xqb96m4/ df8AzaPfyY1XeWXbjPJ7dq8B+JnidNYvLbQdN/0jypwzlOdz4IAH5mq8OveM9d0X TdN0+1ZLV7NFN2DlnwuDgfUGvQPBfw8tdHKajqX+lX55UMBhff6115fh8LksniMR JSqK/LFdHtdnNmtfG8RJYTDQcKTs5Ta3W9l39S9p9pc+Ef2eyqnF/FA0hyOjuf6Z rzfRtZ0TRr28vNUVtQv1OQCu5mkPX8vevY/HIP8AwrLUfl3ABSwA7b1r5S1q3nsv Ec8yMzEuZGBGepJzXvcIYeGYUa0qzs5ybfS+zt6av7z5fj/EVMtxuHhQtanBJX1S 3V7d9N/I9RuLvxf8Qbo2VtZrYaOzdNpAYDuTj9K9v8H+GYPC3hNbNX82SRt8z/3m xiuQ+HnjvS9a02LTpUhsNUjTBhACrKAPvL/hXq4ISMuWBGOo4r5riXH4uMvqTp+z gnol18/M+44PyrAziswjVdWpJWcnuu6t0PG/jO8yeHtCMMjxxm7ZXCnGcrkflg16 F4GvPtfwk0OeRwzfZVViT/d4/pXnnximW48C6JLCyyJ/aHDqQR/q3rCi8TTWvwd0 Dw7pMu3UrmNmndDzBFubn2J6CvZp5VPHZFhacdGpu77LW7Z4FXPKWW8S42tJ3Tpw su792yXrc+hYLq2mdljnikIPKhua5vxh4nHhvwx58UaS6hMSlpCT95sZJ+gr52sJ 9S8EfFS3kvXnEeUmlJ5DxP1/Hr+IruLeW5+InxXS7VZF0KzyIdwwCO7fU4/QUlwx RwleOIqTUqKjzX7vpH56F/69YjH4eWFpU+TEuXJy72T3l8tfwHeEPixeT+KP7O8S iKJJG2pMF2+WScAN7e9e/wC/eiMCGyM8V434++HEWqWI1TQ41j1OBAskQAAnUf8A s1cPo/xS1rwro40jVtLkv3gwsfmSmOSNR2OQc+1aYnJ8NnFJYjLklP7UNvmisDnu L4fryweaycqb1hUs38n/AF+B9QBvTANP7YwCa858HePo/FV+8A0m9smWPd5pw6H2 yOlejBgBk818VjMFWwdZ0aqs0fo2W5lh8dh1XoSvF/L8xSFLjLAigcDC8H+Yox68 nGeKVANu4A/lXK2+x3JIeCAwGASOvP8A9avFfib4l8XWer2ujeHrC/EVxHue7t4S zMxONqnGBj+te0bRtJYHdjuKepIbI49M16mU5hHBYhVpU1O3R7X7nk5zlksfhXh4 1XTT6re3VfM8D8E/C+7e7XWPFZlNwX3JaNJuLH1kPX8Pzr3tIkjhSKNI441ACqOF A6DApwX5BkMxz+VLgABuDnHFPNs2xOYVPaVpfLoicjyDB5VQ9lh427vq33b6mRrT iPwjqD5CkW7cg47Yqj4ZATwnaheAY17e1TeKHKeCL/acgx4HHuKl0VBH4atkwQRG ox+AqY6Zf6y/JIiV5Zt6QX4t/wCRqvjYMDPPpUOcZNTO2Byxx6AVETweOfevOaPb 05hC3BBPI6dqoTnaPlJxVwjngMCO1VJxkA+2M1UXfdGdSLKbMAMD8fU0wgc5OPan HqAQ2PWmEjnls1omzK9txhDFckjOOmajxgEnGakPHIzz603cehBp2M30Y0k+ozjH 0qMuFwex/GpAVJyVJHrimsM9M4J/Gi1r2BrW4BlGR054HvSMUVwSVXNRkNsGAfTO f1qLGD3JPpWLincmb2ufkzrMhj8K3jo+11iIA9K8Alubu7lSB2kkjR8qvpX0BqoL eGL5NxDGBsKBznHQVxXgzw9CNLvZdRjG+VvLCnqq9z+dfD5Ri6WHw9SpJa3Vj7PF 05VVCEV3udR4duUvb6CaByI4oAj55ycYrt+PNG/AHXgVyui6LHpd2728+Y5Sfkxx XUAjGQN3rnpXmYnllNOm9DRzcrKW6sTiQFOC+ScjFcx47hWb4S6rn5gPLYY7Ydf/ AK9dOjL5g2k5PQelcf8AEC5Nt8Mrldygyskaj1yQf5CtsAm61N+a/M5qyXLd9jd+ H4dPhTpIkBDoj9R23tj9CK7eIguTjK54yK5vw2qR+D7ARYCeSp4GBggGukgJ8xOu SOM9KrESU8RJ9LsiDimkjdgGHAw/qOelbtqYzsbBBz8wHpWFbh9i9cY655JroLYj jj8jS5L6I6HHm1R0tllGCZ3A8E4ro7Ussv0rmbJmZwQvzE8Z71vxZEuRuB7VcLpn NUS5rGzuy3OTx0qVMY5zt74qsrcBs9+eKnjHQHOBn610K/Lqc9rSZdjYhcHPXmpZ VD26sBwPzqFMYJI3AetTE5tmUA4PatmotahypO5HFkAcY55Gela1uw2MWOWxkish AxIxkLkjNX4sE9T78VUZPoGqehalw5DHABpI8AHA7feqQgtEN3IzmoIwhleMqcg8 HNaLluiG3dGVrMSP5b4/5ZSLj8jn9K7aIlrKBgQVKgg9uma5LVUXyYDjOS/BPHKm ultnZ/DlsUJL+UpGPoK9SpKUsLTXr+Z4+HX+21l3sbUIy2Qec1oIcEKCOBWfHu4G Md60UXLDLGueK6HdZ2uWBj/69ea/Fi3E/wAMEm2gtDdo2e+DlT/OvTAOMdT2rlfH 1kb34T6vEqlmjiEoH+4wb+le9w7W9lmNCf8AeX52PnuKcP7bJ8TBatxb+5XX5FT4 VzCf4OWK/e8qaVBnnHzH/GvSlOUGcZ9a8Q+CupCbwpq+mMQZbe5WVQO6uuP5qfzr 2xMhBkYA9a6+JaXs80rxt9pv79RcIYhV8mw8072ik/lp+hS1qy/tPwlqNgDh57dk U+hIOP1xXzaUjXxX4fvbhAYhcRw3SMM/xgEH8C35V9SEvv4UmvNtS8CSXniOSaOR Y7OWdZih6qc5P6/zr1eGM6pYWNSnVdk/8rP9D57jjh2vmE6NahG8otX+Tuvlvf1O E8X/AA0vdI1VtZ8N+Y0CtvMEZw8R65WqsnxD8VX3gU+H7fT7qbWJf3YulUq23oTj H3vpX0vjKc4zUcVhYx3TTxW0Ec7dXWMAmtKHGDlRhHE0lUlD4W9169yq/AkIYidT B13SjNPmitn6djxJ/B+rR/s3aZps8clxqVrcm4EO7JAYsNvPoGq18OPAdzb3Emq6 1B5cm4bI26jHODXtqDEo6k+/FWF6Y7e3esXxVi54apRVkpNttebu0d0OBsuWNp4x 3bhFRSe3uqyfqcp4h8F6L4luYJ9Qjk82L5Q8ZwWHoa29L0nT9J01LTT7eO3iUYwo xn61pYGCec049Ov4E14s8bXnRjSlNuK2XQ+jhl+FpVpVo00py3dtWOX7uKyr7QtH 1T5r/TrO5P8AekiBb861QcAdacOSe3vUUq06dpRbTOmpQp1Y8k43RS0/TLDTLXyb C1gs4/4hGuM4rSAVgT1P86iXdg5xnOPrUg68g/Sm5yk7yd7ip04xXLFWSHNx0xjH QU5DtXaDg9B6UwDI5ABz+dPTIU4HP1pIu7b2HnOACOlOABYD0469MU0fK2cY7g9a XIK7sHpRdDlDS45SQnXnrinDDID/ABYyOOKYTgcryB3pp3bvm5I6+9N3BqzOZ8YS 7fBVwqsVLsqkDvyK2LMGKwjQc4HWsPxcSdMsIuSZL2MEe2ea34OLJD044NenVjbB U13bf5L9DxaEubMqr7KK/N/qS559aacgemfU044CdTnPWm5PQk8deK81LU9jyISS CONx9aqzZCZJ71bJHmFeCPrUEoAUnac56jtVR0dyGm2UG3Fdy547n+lMO4EE5yak PCnPXOMGgbj0644z2qlIXs721IM5OSCG701vlBC9B1OalzlSe1IwUEgAgY544pp6 mTjaOpGileAMjvUQT5cHmpwAMAk4NMIUyc5o1Qre6uhA2SONuDUZ7gAAH2681aKg qxBKt7VHtAfnBB6is2rEtcztc/JO93NpkrhljRYz1PFed/8ACYC3jnRo089GGwrj DA9a7/VCq+GrsueBFk55rw200+bW/EjxWqAfToMCvhsmw1GpTnKrsj7TFVp0qcXF +82e1W+qh9Asr3ZuEvI2Hg11qHdwu0jHORXkmiw3dr5WkXKyJEkucMOMn0r1hN4X BIUDgEVx4jDxptqH3+Q51IThFtavcuKVOMrlh0APWvNvicWbwxpsAY83DNt/3Y2N eiJkYXoM1wnxDJXw3plwAdkV+u89gpVgarLW4YmDOHGL9y7Ha+DblbjwLpvzZ/0a IMB6hQD+tdnCMyfNjcBx2FeF/CnVpZXvNMbJ8qLehz/tAf1r3WE5fqxOM81rjaLp V5RYUpxmkzctcGNem8Dnity1I8oAgBQcgVh2/wBwEAgZzzW9A3QbTx0/+tSu1ZG9 11Z0dkc3EbAYx3reiyJSCAa56yIBQksD6d66NN284yPl5x3pNe9ojKrFXu2aEZzE vcZxjFXYyd4wAU6GqKEhuoI9f51bByp+9jtiteboY8uly5DIMkcYzTifvHIz7n6V WjJ80dc5HA71byHKgkH15q1C60JUncdGPlXHTpir0IBfsBjOD3qGGMY5HXnir0eM ZzjPv1rojGK+YNtEiqPLHJBHSmxxMt6W4CFamVkJ4JC4p4P71cA7SM5FXBmUn+BR 1SMiC2OP+WmG/EGtvR+fD1pj/nmMVm6kWOmxNuYlZlxge/8A9etLRG3eHrfAIwuD +Zr03rhY+p5cJf7bO3VL9DdiVRwcjjn3q6nABAwvpVNCQfl5PcVcXIQc5I61zQVt bHY3ctIBgYHT1qR4o5rWSKVcoyFSD0IIxioPNEVuXkO3AyWzwK4DW/FV9PC8OhQm d92BI33f/r162XYKtialqeiXXojyM1zbDYKlepq30WrfyOm0DwrpHh3ULu508LG8 6hGG7qAcj+ZrrFdSchlI+tfMljqvi3xDqs9pY6i4uEQu0eOwIB/nWlJffETQAlxP 5lzCByCmRnv05r6/E8LVqlVqpiIub77vsfDZdxvQp4dSoYOSo66pab66I+kBjB5x Sr945yfavP8Awb43tvEifZJh9n1JU3GLOdwHUiu/DAPk5Ga+UxuArYOs6VVWaPvc szTD4/Dxr4eV4v8AqxY4KnoMdKlUAIdxyo6c1yeu+LdI8OWe6/uFWRvuRryzfhXJ 6N8T9N1LxNBYTW81qszhEkfGMk8A/jXoYTIMdXo+2hTfKlucGM4qyrC4lYapVSm3 a3Z+fb5nrO4A4A7dc08NkcYzzg4qruYSHnntWTr2u2vhzwrcajd7iEOEjXq7dlFc WHwtSvUjTpq7k7Hq4zH0cNQlVqy5YxV2zpFYB8dDjNSc7s4B6V8s3njrx7JbtrqR vaaSsgDBEBRcnAySP14r23wJ4rXxX4RaeQIl/bMEuY16EkZDD2I/ka+izThfF4LD qu5RlFOztrZ9mfLZHxrhMyxTw6hKMmrx5lbmXdHdZBJ6ccUZ+UcD8a5zxF4l07w1 oDXl/ISzHEUK/elb0FeeWmveO9cY3trCmk2JP7uMw7mI9yR/SubAZHXr0vatqEOj el/Q7Mz4nw2Fr/V4p1KlrtRV7Lz7HtIOTg9T1NSA/KAeaoWDXTabbm8EYuSg8zb0 zV/nIwO9eXKHK2r+R9FRkpR5thxIySBgZp4JIPPGPzqHOATing8DpSb2BS6EwxgA ZA75pRjZnjAHNNAOepOD2pqn5yCKUX5DfQmJyxHXJ456Uwn5+SMfw/SsGLxJp9x4 8l8OwtI99FAZnIHyDsVz6jI/OtstuLdc9uK2r4epRlacbX1+8yo4iliFzU5XSbXz WjOR8UyE6loUYBO+8BJ+gNdLDxbR5IB28iuU8Rnd4r8PoTjDyN+grrBxEmOQBiu3 F/7tQXk/zZ5eAX+24h+a/wDSUO69B70hzn29KQkg5yTQxyD6elecrWPZScmiNmHP Az9KrzEiPnPHrVgk8Y6nHSq8gZj1xQrBO2pWJUnIxnB/Co2HzAetOKnyscgdzimp xDjnPbNa6amTd9BCMdsk96awyvXOBxmnO3IJLHH60jEkg4wO2amy6A10ISw3AHAb rimnAcHjkV5Vr2leOk8U3N1pc8M9o5yi7wCo+hrAkh+KIct5CbR0Aden+TX0tHIq VWCksTBX8z5DFcSV6NSUJYSbs7aK9/M9zPUZwOvWoyWMhHt+NeD3Fz8WIYiI7MOw 6YK/416t4WuNdn8HwyeI4I7XU2zujjIIAzwfrXBmOUrCQUvaxlrsndnXlWdSxs3B 0Jwt/MrH5Ta5Mn9gzWZkCS3EZWMe9YHhvSW0mzkkZVM8jctnoOeKu+JrK4m0mOaJ 8tEQx4rz288Q6lBepasWUQkAhup4Ffl+AwlSrh3Tpy33+R+m4jEQi1OcetkevlTK 6PJGrnPcdK3ImJCMT1GcGuRtdchn1KwhhZCssQLeoOORXXbssq4wMZxXmOjOOklY 68RbS3qWgxPzEHGawfF1j9v+HWpwLnckXnKAM8p839MfjW4pYgHkAVMVWSFkZSQV IIJ7VdOpKE4yXTU4q0FKm4nkPwjGfFupuSMLagdM9XH+FfRERYuo2k4PGa+dvhhm y+J2q2LEnFs6HjGSsij/ABr6GjQs24MNwPJ616edNrFNrqkcGDi3S06HRWmRENyg HoM10FuACAOB0HpXPWmdg3cL/OuhgO5d/HuB0rkjLZnfKTWiWhu2y7GGcZxya6ND llwQ4ArmrY88qQ2eea6WPG1COnb0q010OeUdEaAKgfKcD0FWF64yufp0qtz5aZzg HkAVYiO7BG4nFbp8z82Q01qW0B3cHJqwjEAEEZ74qsueByfXFWFThSOB0JrSKitD Jyu77FqNiWY7s4PpVyNg0WTt69qqwoAnRsetXokGw4DqcdfWtVvcWlidVDNkrj61 YUZHOOOKZHjAx696k6E9hnBq229DNp2uyHUAp0aQHggg8fUVc0EoNGCKc7ZHAOP9 o1BdqTol0OD+7PH0p3h5lWyuY/4VnJPYcgGvQpvnwkrdGea7rHLzTOpjwELZP4VY QkjBx7YqvH8q4YDGe3Q1ZGCp49uOlYxd9Drd0UNYtZ73w5cWts7Rs4xkHBx3puj6 VBp+lRxbASoxgjpWso9gO3tUynngYI7Cu+li6kKPsYvS9zgeX0pYn2zXvWsfN+g3 Nt4Z+Plys0i29qk9xE5Y4CoeV5/AV32ufFDRoLN4NNjGpXDLtCKvy5NeVeMdGnuf jhf2dqQJrm7QIDxy6g1mi01nwvrUVzf6Z5hjPzKwOx8deR0r9onleX46dHE1Xebg mo3tfqfz/QznNcup18Lh1akqkk5Wvy62fl5nofw00LWLr4gDxJdRPZWi722kY3l8 8Y9Oa9t8QatHo3ha81KTH7mMlQeC57D88VyfhPx3outJHbJtsbsDHkEAZ+nbFJ8R pgdK0e1YZinvgXHqqqzH+Qr4zHRxWOzuCxVPl8v7sbv5n6NgKmDyzhupLAVebrf+ 9Kyu+1tNPI47wpoUnifxXd6rrjm5uU2ySI3AXJO1cduhrzbU7m4k+IU0/wDZhsSL gMkAG0AKeB+leo/Di/aP4heK45m2xeQrtk4C7GI/9mqDQ7n/AIT744Xd2YgNIsIj tOzhuflGfU8n6V9lTx9XCYvE1Ksf3cYR9FdL3UvN/kfnn9lUsfluBhRk1WqTk31v Z2cpPfRL8TPm8X+MNe1OaPTLqG2nVDLHbxfeIXnGT1NZY8Rat4wNlZao6SxWm52x x5jHCrkeo5puq2f9hftEwQaQ5yNShaNFOcbypK/q34GpfEdwmhePten0+Abf7Txg rwNq5P6uK9bD4fD3gqFNJygpRdrNX0d/v/M8fF1sZGnN4mtKSjUcJq7adtVb5r8j 6Km8PWh+Gc2gyxr5b2pjOP7xH3vrnvXhvwcvZbbx7d2hJCXFgzMO2UZT/wCzH866 jSPjNp01kE1iwntpx1eH50PuO4ryzwr4lg8M+MZtWltmuSbeSNIlcLyxB5PpxXiZ XkeYxy/HYavDWdmvN9X+R9bnnE+UvNcuxWGqe7C6lo7paWTVvNneu3/Cc/tCGC7l P9mWTPsQtgbUIB/M19DQwxQxCGFI44kGAoHSviuG7t08awXmoLdxWMt0J5khYq7R l92AeMj/AAr7G0rWdN1nSY7zTruG6hbgsjfdPow6g+1eZxpgKlFUfZ3dNRsrbK36 s9jwyzOlXWJ9q17aUnJ3erT8n0WxrEAMCCCe1OB+Uk9KjGMcZ608Aehr8+62P1pL TmHn7owRntmn9RnBOah53AHB9KlXPzZyKdnexLWpIegbgYr598c/F650/wAQ6loO hQxJPBIYZLp23Pu77U9Qe/P0r6A3fLgjj1rIPh7Qm8QDV30jTn1Lr9pMK+Z9c46+ 9e5kuYYPB1XUxFH2mmi6J+Z4XEOW43HUFRw1f2V3q+rXZdjiPhjoV1Y+GX1jVoXj 1a/JdjNnzVUnIBz68GvTT0OeMH0p54yD19fWo8kNyMD3rgzDGzxmIlWqbt/0vuPS yvLaWX4WGHp/DFW9e7fm3qcZrTK/xH0SMgErDK4z27V2AJAP9K4nU2B+LmlpwpFk 5Xjrz2rtBwOua1zGLjSoL+7+rOLKnzV8S/79vuSF3AKATTCflPoPfpQec9DTWwX9 O/XrXnaM9iN2xm4HaQwA7Y6Gomb90CWO4HgkU7cCVB3dM0OV2ryF7df0qle3mNvd FVyd2MlVNR7jkcE8Z5p5IYBu4qJyBgA5pJpag0rCllxuLHBqMn5jjHI4FICAvf0N Rs64GCcdDVuVjJ3JSCSAMg1Gf7vCiozMpXcvzAEVC0rKoAUk+/WhyTs0OXVk33n+ ZRgHv0xUbYwQr4B7AVCdx5P/AOuk/hBGcL71HP2I5bbn5OTwC60/yicBsZryjStF bXPGOotcljDEzKzgYyRwP5V600nk2jNu2qFHJFULK3jsbecxoimWQucDGTX51gsb LDwmo7vRfqfX16MqvKpbLoYOg+HptL8SMbgF4QG8qTP5V38bgMoYZ4+92NZ4m3ru HPOcDoavQuzDJLBu/FZ1MVUrSvLcUqfK1yvTQujleRz2AqdGOT0HHaqkfAJAAA65 OMVchIPUHB7USSt3Jmk9+p4/4Nfy/wBofVVz9+W5Udv4yf6V9Dw7TcKMHOPwr5x0 AG2/acljJB3Xk+T/ALysf619EwHEgwGPFexm2tWLXVJnBgnaD9TobQrwMj1FdDas zHAXGBgYrnLQsFDZIb0HY10NorCUMQQx7/jXHbsdtNpaHQ2uRDnvnnNdIufs6Dqw 4zmuctg6omd3Pc9q6GI5sQ3cHAAq027mdZ677F5ZMHHGOhq1F8pYAY45461TXJHJ 6DJzVqPIYgfMe3Faxavy9TFLR36GgnD4C8Ht7VbXHlZI6evaqoT92Tz+VWIjwT6+ /wCtbXWzRhoX0Ax9RzViHsN3y9arR8oMZJx0xxVhGbhdwAPbFXHrYiyaSLiZXjAw BwalGcZyvPH1qIZ39yByRT93znkZ7571pZjlGysWWUPZSq/KFSB+NZfhiQk6jE2O HR+nqv8A9atRSTEwPAxjpWHoLGPxPfxE5/dDj6MRXp4WKeGqpb6P8UeRjlbGUXe2 6/A7uNgo5GST1zVpCc54FZ8Z3NjIz6YrQAHlcsADXGj0WtLE+Ssgzg1MPu9c4qEZ 3E8496lwdxGSOa3irEtroeEeIYTH+0zp7tuCvc2r59Ocf0r3W4061vbIxXcMU8RG MOMjFeaeKPDeo3nxT0nVbOMuirH5mATgo+7P5GvXOAuOB6Z6V9XnGMhUoYV05axh Z+Vj4nhjLqlCvjlWj7s6ja800eEeKfhpPZz/ANqeHCxw25oAcMp9VNc5Jq2u6lFp djrFpcCKxkJM7J1BXaM9q+ntxK7iQSfSqd9YWmpabNZ3MavDKuGwMH6134DjCtTj CFeKnbaT3V9H+B5+aeHuGq1KlTC1HT5t4r4W1Zq69UfL8jXel2fjKSPKfaRHbh17 K8hY/oCK6jw54o0zwV8L47a0jN7r12xleJByD0XP0HavYZPC2jPotzZNBujnAD7j zkZwf1NR6T4M0LSrhZktY5rhcYkkXJ46V6tbijAV6LhUpt6p26OySV/LQ8nAcEZn hK8HQqxS5XG+7jeTb5V31tc89+Hvg/U7vxcfF/iUGO4LmW2iY8lz/GR2wDxVPV9J udQ8eeIdNSFnmbURKB0yj+Vz/wCO179tGcgY9qkS2txdNcrCguCMGQry2OnNeXDi 3ELEzrTWrSSXRWd1Y+hrcDYV4OnhacmkpXbe8m1Z3PFPFHwkNz4h+3aDLHbQSufO t34VCe68dPaup8PfDDw/paQzX1uup3vVmmbKD2C16YOEJHJpQQEOCAccmuTEcT5j VoRoOq+Vff8ANnoUODsnw2LliYUVzP5pei2Rx/iXwVo3iawSKe3S2niTbBcQgBox 2HuOnFeK3HgDxt4av3udIkmuEUH97ZSFWb0ynevpoEjpzxxk02eIXFhPbs8qCRSr NG2GAIxkHtXRlHE+MwUPZJ80O0tUc2ecF5bmU/ayThUW0ouz2Pmmz+KXifS7n7Pq bRSyRna8c8QWQEduMc17z4R16fxD4Oi1O6snsJGZl2uCNwH8Qz2rItPhz4RtdRe8 Olpd3LEktdSGXk9Sc967pEVFCRqEVQAFUYA+ldef5tl+KS+rUFF9Xt+COPhPIM2y +cni8U6kekd7ed3qSfw89eoqYHnjk/pUGRkY+97dRUo79SMdTXymrVz7lO8iQ4J5 x60v8XoKaeBgnv3oBGznI9Km9y2vMG6AZ4zUbNhMYBNOb7g4Pr1qNmyQRninYfLf Q4m9Zf8AhctkBjiwY9f9quz3BVIBGQK4q6P/ABem25Gf7OPB4z89dngtgMecc16u Zp8tFP8AlR4OS/HiP8b/ACQ7OOlQM3znkE9sGpM8EjOfYYqqxzPw2PWvNUj2/QVz nAIJz68VC7EIcEYB9P8APpVsKpiXIG3HOTWc5GSFOBSTKsiMv8mDx9elMLsXJGCO cClfJbAOD1+tIVwxJx6YpNX0KS1vYjLtuAxn6Uzb1bkDGBnirEUZaEn9BUjIogHQ H3FXurkVHrYo7TxhQM+vU075BgHB6YApCQOeT82T70xt2QD+tJNkysrAdu/GDgHk Ux85OcelK7DAx055xUZOUGCenb1qGY6tn5HaxIU8J3jDqYGC/XHFebXXiyaTRLa1 jXbMnySNjqBXp2oWxu9BmhThmi615rp/hK5udLnu5gI5A/yRnv8AWvjcreGVNur0 Z9PjXN2UPn6Hoej3S/YLOGQESyLuBPeulUANnsR2rybQ3vbfx5Db3ZIAUhQ3TGO1 erJzgglQOT6muXF0FTqKzvfUttSSaXr6liIIIxxkD061eiJXBP3u4FUQ2U4465A7 nFXYSd+TgMT1FcyhJbCu0tUePWuF/aiG04zdn9Y6+h4AC4HzbeuPSvnRW8n9qBfl +9fADPHVB/jX0PH8zYyNvbHNexmT/hSX8qPOwr0l6nQ2u0gZXJzjiuntNxhXjnsK 5e0A2jGPwHOK6ezJ2gbiOfXBrBuS1XY7raWZ0cPRV5245Irdh/49CoG0dRWLbMAg Jz7+1b9uymIjLYxx3zTUUnsYzbav2J0z5StgZ9c1dhDb1yRx046VAroEwcAFqsRM C5HfPrWsEuxDvZ6ls9DhgfbnmrKcFflGCe1VWJB6EAd6lRwXXOTWyvbQybaNOPBw Mj/GrCAFguNxI6HrVROoxn8quLgEHnIPbvVqPVleqJkYYHQexNSDDFuR6HFQAlnM hGPTPep1znOcevrmnGxmpNluPG9dwyD0OM4rB07anj65Xgbo3AwPRgf61vxdMZOf UVgRnZ8Q492PmDAk/wC6D/SvSy9Scaq/u/kePmj5Z0H/AHvzO3j5kUgZ+lX0k/ck 84B6dqz0OI/TA9auK2WYAA+xrnTUkehsi8pX2IqQHAywGByfwqsr8ADk4/CpRiSB 0YldykHB7VvBJ2uTJPlbiZ6+JdG+0tCLyDzAcNlhkVwfxC8W32my6OujTx+XP5jS PjPTbgfqaqXHwtga7klt7hQjEnacj8K43xT4SutB0m2up/MnhMmxQJM4OCeh+hr9 FyHAZO8ZTcKnM/5Wt9D8i4qzTiGGW1lOkoJfai9rP9T6I0vVYr7wxp180kQee2SR xu6EqCf61rJIs4zG6Pg8lTmvm3RvDHinVPDMF3Y301tZMhKAzkHAPHAre+GviRdP ubjQdYkuYLySctG9w5IJ6bRmuHG8NU/Z1Z4epzuD1S3S/wCAezlXGVapVoU8ZQdO NRaSb0bsrff5nvJK5GcdcVKpDjIbI9c1xXjDXzoPgm5u43Rbl/3dvnkFj398dfwr D+GEusXXhe+vdUnlmimlH2fzDk4AOSPxP6V5NLKJvASxk3ZXsl39P66H0U+IKTza OXwjzNxcm+i7X9T1cYD47dfrVlRhc5zkcVTVsjv681NGx2g856GvKceY+heuhNtA GNh9yTRlQwO00m5ySDj7vpSgDkNuORQrrcOXqiQ5LA4wfQU4hcAALnHOKaNwOcda XnIK4yeOa1UhOIAAEEdDzj3p2PmwTg/WkzgjI/LpS8hMEYI79auKuSw43DOCamQn Byagyd4OBnPBqTJ29SD1NJJvQUWk7kvTaSR9KXPy9ievApnXbngUHDMCMjI602ht XQrMQM4HIqIkdcU7nOAOPrTSMk+vrTTdwtocPdKR8abdmUYOncH/AIHXZEr5jZx6 5rkLgN/wuOzDAf8AHiSBn/b5rr2+8QuMEcD0NelmLvGj/hR42TRcZV1/fl+g09Cc q3pzVU8k+mOOamI5PPUdarkrtxkg56GvLl3Pbile4pc+Xtzx1qu5wD27VI2QOxA7 +tRMfXn1ptlT1Z574j+JHh3w14iOnaj9se5Cgt5MXAzz3IrCX4y+E5IzuTU4yW4B gB/Hg12ms+D/AA5rt59q1PS7W5uCApkIIbHbkGuck+FngqRuNJeM/wCzO4/rX1WF r5AqMVWpz5urT6nxWMwvEft5PD1ocutk10/4AyD4ueD/ADgrX91GD2e3bH8q24vi J4Quowqa3ZIc9JCU/nXLS/CPwe+dtteR/wC7cn+tZ8nwa0Bi3kX2qQD+HLq2P0rs VPhqps6kfuZyN8WU3e1KX3o9Vg1TTbtEa1vbW43DI2SBiRV4ZYZCgnnOCa8W0/4O WNj4jtdR/wCEg1jEMgdUixGWx2LDtXsG1lwMnb/KvnszoYSnNLDVHJPq1Y+myqvj alJvF01B9k7jtw5BXn1pM7lwAB7U0uDjBxTdzYIGcD3ry+V3Wh3c5+T4crYs+RjZ k5rKfVbOLQZLstGEUEbTxk46UmqSPH4YlZNyEjJx2rxi5uZppZolkdoC+dtfD5bl qxN23azPqcVXVKipLVs9X0O/i1l5LwwpG8DYVycEZFduuFRclTwOnavMfDy248EP HZlmvmceYo616PbCRbCIS5EnljPHfFRi6UY1ZKOiWhaXNSUm9WXg2PmJXIar0f3z yCuOMVnKmFBIJz3q3CwEZPUluawikY20seO6qfL/AGlrZl+X/Tbbk+4SvoyLh0zy Sew4r5y8RMI/2g7CTGP9ItmOPqv+FfRUbMrqQRjvXqY3SjR/wo4sG9Z+p0Fu+0YA yQDzXT2fMZHHB6kcVy1nkuAV2j+VdPZOQn3RWKUnE7V7zvI6mBThScfgP1rasx84 H8JGBnrWJbklEOCD9eK3LfPmq/NXTu2YVWrWRcUDLg4zmrERAvACRux2FQ/8tzgn B5/CnliZuD04ya0UbWMW3uaIY7z0zipEJHU49KgBOzqOnpUob93wOR7VelkQ20jT jY44YDHtVlQWzyM+9Uo2JwzY5HPtVteoAI+uKqKui9SwOgA455/Gp1J9QR6g1EjN swBheuT2qVASxz1+lW49iJp9C6pwGAwPUVgXII8b2b8cuMfiCK248AgZJrC1LEev 2kp55XqOmG/+vXqZar1Gu6Z5Gcx/dQl2kn+J3CHIGDn12irKkbcqwBJ/KqsJAXBw RxxirS4A6gH0rkTtrY9K6LKDcvBXP1qZGyRgr055qBSzKvJ3McZBqVBhz1JJrZao zS0LgzhSSCPSuA+JUZk8AwkBeLtByPUMv9a75SQAMj8a5Lx4mfhxPIQT5c8b8f74 r3uHp+yzGjJfzfnofO8WUIzyjEQ6cr/DUseAx/xaXSlUgna2R9WNcv8AELwolzpr a3p4SK5txukxxuA54963/h1IG+Fdkhz8jyLnGO/Suc8aa1qGr6w3hbRYp95YJczK vy4PYV7+XqvTz2o6ckkpScm9uW+p8zmsMPW4YownBycoRUUt+a2noee2l7qXjXxL ouh6jdYt4zgNnr1JJ98cV9QWVpb2Glw2dsipbxKFUCvnLxL4Qu/CqaZq9lcSMU2+ c6j/AFcnZvoa9r8J+IU8Q+Fo58hbxAFuE9G9foa7uK+XEYajiMM/3KurLpK+7Xme b4fuWCxtfB45f7Q7O7d+aKWyfl/Wx16cgZ49amUgR5B/CqqN8ygfKe/FShufWvgY qNz9YSsTDuc4z0p+Tt5+ZcVEDlRnsOlOGAdo3GqeoorYsZ4O5h0z160oIKjDqBjv UCnCkE4OOlPXJOCeSMHjiqVgaV7ku4cNuBAFeeX3xI0q11ee1TTtXuvKYq0kcPyH Hpmu+DYZQSPl7gVzlz4V0C7u5Z7jT4ZJXYlmywJJ5z1r1ssqYKnJ/WYOS8nY8TOM NmNaEVg6ig763VzmH+I4eQJaaJdJIf8An7kEYH4ck1q6ZL4o11xLc3KaRYk5C2sG GYf7z/0Fb1hoWi6fKTZ6baxN/eCZb8zzW5vCnr8w7ZrpxWY4VJxw1JR83qzgwOTY 3mUsXiHLyWi/AnUYRFJzjjPrTyRnrgYqNGygxkj1zS5yOQK8XW59QnpoKee/HXFR ElkwpGe9PyeB1NMP3+CcY5FSNNWOSvAB8V7ItyhtD19mrqGYggA/4muZvB/xc3Tm B627DPfqK6VicErketd+Od40rfyo8zLo8tSt/jf6EMh3DjbjvUBYA5IwPXrUkjYy Dtz6VWJ53Fuewrgt0PVTs00OZhs5x2qIt8xAYZ9PWiRsZ43HPOKjbqcFc9aEge40 sw5HygHJBqNicHnJzzSPw3OF7gCmEkjk8daeltdx2aY1iSD0J7YNG4DPOD2wKRmI BJODSLncDkknqaum9kYzQucnBbHNMccDB69AKsSpsAx1xhvSoN2VGMDjilpsTe6s M6DPp60HoSwFKzYAJPPoKj3ZQnGPqeKJvuSo2Vj8lru3a60CeBMFpIyoyOAcVyOg +HI7WC4e/hWSZiURW9PX8a7JZMaaSFywTv0rDj12zaGR5XCNCpz6Gvz/AA9SvGnK ENmfTzVOTUpIg0zSG0nxY8sBBtZAeGP3fau4ifccFR05561xmia9ban9peZTEsRG CSBkHNdhEpwHUkbhkU8VGv7Rc+/U2fs1TvBaPYtKRvHPOO/arMIwxO0k+vtVVCOG yCOOQOKtRJh+px606dN20MII8d8WsU+NlnIowQYGH519FwkuFD4Xvn0r528XAH41 aePnAPkAk9fvV9BWxPkw/wB4gEeteljW/YUfQ4sOuWpP1OkteMkjoMjFdPZbjkDk Z/KuWtznGM+4PY109my8gdv1rCN0jqTXNZnVWuSi45P8q3bdsr0HsRxWBZnI5zkE AV0FvyCOc+tVG78jGorvQvPncpPRh/Caj+4uc/N609iGt1+Y8e3FN25UAE57VvdN 2Od+RdRswIRjrg4q2hYY54/WqMSsUOMkgjGa0FzjGOOnSnFPqW7svRMxXjknpira EZyaqRnGCfxAqdCTg4IHpWy8ybcpcRxgAZ6847cU5SQ5KsOB1NQBsAc9f0qZBk4B J4z071Vrom7ehdjOT97A6ZrG1zGbNgwVsn8ORWsjDA7eme9Y/iHiytm+7iTk/ga7 sta+sxXqjyc4b+qSfa35nZxMGgVgFBIB9MVdQ/u/Q+9Zdm5ezhbvsHIHB4rRjOT0 NZSSuehGV4rQvLgDtup5O1wcn6Z4qJCFbGSW7+1SpwSR3NUtxWfUso2VBzz71geM ojN8LtaVRudLYyDn+7839K3Yj8hPUdK8l1H4p2Np40v9E1HT5RaI7RPJnqOh464x XvZHgMViK6nh48zhZtejPnuI8xweHwzp4mfKqicU+mqN/wCGE6v4FuYgWYx3bEbh 2YKf8a9GWCFGEiwxCRjywUZJridC8S+EPsYj0q9s4FYAtGGAP4iukXXNJHzf2hbA kd3GK2zShia2MqT9lJcz2sYZDXweHy6jR9vGXIrXui9f2VvqGlT2lygkt5UKup96 8OtYNW8E/EFIoLa5urFpljYxpnfExOCfcc17wJA6Ahi2e/Y1wHizx5p/h2f7IiG9 1IrnykI+T3J7V15BVxjlPC0oc6ktU9l5+Rx8VYXLoqljq9T2cqb0kt35ed+x6QpA ByRuHfNPU5U7sbvUV8+2HxevBqiR6lpSxW7HB2P8wHqAQM17fp2pW2qaPBfWcnm2 0oyp71hmmQYvL0pVo6PZrVHdk3FOAzVtYeXvR3T0frY2VxjqetPydpC9cdT3quGx jqR6VKCSM/hg14zXU+iT6WHgggdyRSqcDAOaZn5D3OeDTk5TnOKaSYbDi3JwSDnG aTdgBcj60ZIY+tNI+fpkdM1pqZ9boeGIwCfmNOJwy4x6GmgYU+oPQ0AcdyPpTauR Z2sWI3Ux7Tzz1I61IeU/GoDwCopjMxOMkpii2t2VflViz5gJcrnIFNMijPIUY6Dv UDdDjI7VCMqMZBJHek2mVBsxNRb/AIrbSH3AZVx+naujYbYh1rk9WdU8T6I3zbt7 jp0ytdAJCxB34QdAR+tduLi/ZUf8P6s8vLZXxFdPfm/9tQ5wobb35qD+NQCD+NSO +AeflqAsd+1cYA7CuKNr3PXk7LURj8wGQO44qInqQcrjninMylAuBkjH09KhJygO 7LEUltqJyabsDuM89e9MJxyW4NK5B7896Yche+fetG9SHdJsbk7sA++aQkg5Hb3p HDb93QY7im8l+owT0xTt1M1K2jHsxIClsj60wYBYk5bPWkO7b0x9BTSMMODSum7I E7LzBmXbnPHse1RmQ4PQDGAc0uFABVTx7U0hBGFYAnuBUzj2M7u5+UEQVrMD5Tlc 47Y9q8Z1+BrbxDNAoZUOGAx617JbjFpGwGRgcGsK/wBLsrnXHv5ZDmEguvpj/Ir4 rLcUsPWk3qv1PrMTRnVpOC0Whxnhsos8mnS/uZppB8zDpjt+tezoAgRRlgBjNea6 dDaa7rZvbUGGa3ky3o4zwa9Is1dVZZAck4Ge9a46rz1ttXuiaTlGiqd9FsWwC0R+ U5zViMGNgvG73NRKjZ+UtuHtVyMfMM5+g7Vkoe7foTKelzxvxr+5+MelyHgFIXJx 6SH/AAr361wbSEEFfkAANeCfE2No/Fel3QPJtto/4C5P/s1e9WLB7C3baWDLkfjX djIJ4ak+1zhw9vaVEdHZdR0Lfqa6SyJVuec46VzNuPlG3IXuRXT2CjfjIB+vSuRR SSZ26vpqdVaEbFwfm71v24IAKhcd65+zJ7Hj3FdBAzBU5OSOOea3ha12jmqaMvgf 6FwBwfzpOnBxntn0oU5hKkH8DQo2sM9M81s1bWxlFJFm3IO7AG6raZKjOAcVVhOC y43DHHvVlc7evTsaItplWL0bHG0sAD3FXBkDlqz0bnJYkHkfWriZC5bLE84rRO5E 290WlHIAAx6VIp2kkbfaoYyN45wT2z0qwgIkxu5P5U+bSwkrtFiM5Xrge9ZuvgDQ 1J6CUHI+hrTiO2MAgp9etUtZVm0B+ASGU/rXdl7SxMX5nn5rD/ZKjt0NvTXL6VbE EtlAevtWunDjnGelYOjN/wASS2wS3yAEDmtxfv55J/lSrRSqNeZ1Yd/uY+iLq4L8 nnPOatLtJ6jHXFVYyRt54PWrCn3xz0zVQtcNd7FheJCcDGOPauZ1zwRoXiDdJd2i i5PSVBhq6YAY689vWpQwRN5bYF5OT+tdmGxNahUUqUmn5HNicLQxFJwrxUo+Z4Pq nwps9O0+e9/tZbe1hUktLkYAry7QdD1DxR4pGm6aF8hDme4/hRQev1PpXonjPXr/ AMa+L08J+Hyz2yvieQH5Sw6k+w5+tez+F/DNl4Y8NxWFki7yN00p6yN6k1+n1M+x eV5evrE+avPVJ/ZXd+bPx3D8K4DOMzcsNT5cPTdm/wCd+XkJe3EXhX4XSSB3nWws wqF25cgADP1OK868G6EdS8WXd7qircTRhZJ2cZ3SP0A9hg/lXofi+FZvAN6j/wCq Lpu+m9a818PeModNk1gR2N1fzzXO5fKH8Kjjn8TXhZNTrVMtrOgrzk7N7aaf8E9r iGvhqOe4aGKdqUI3S3116fcd3408NW2qeA7421hG+pQxNJa+Uu1iwGdv49Kzvhpp +q6D4Huh4gKWby3PmQws4yi7RnP19KzH8QeM9buSml2UVhH/AHmbc2PWsrWfDF5F o02q+KvEFyLZBllLkrk8ABR3rrw+Fn9U+o4isrSd7L3pX7LsZ4vG0VjHmWFwsm4x acn7sbd31Z6lceNfDFlK0U+r2fmL94K+4r9cdK3tL1Sz1bSo77Tp0ubZzhXXpkcY r5K0rQLrxP4pez0NTHZqRvlkx8ik4yfc4PFfU/h3RLXw74Wt9JtC8kUeSzueWY9T XHxJk2By6nGnCbdR7rsju4M4izPN6k6tanGNFaJq92/8u+h0HO4ZJwO1SAYGQAT9 KjBO454xTy2BkdO9fHo/Qmrajm5G7I9qQEY5AH0pRgnPNBxuOAcCnzNa3JaSHDJA 3HJHOacvTpk+o6U0ZzjIx2qZS3lFeSAeQDTuugRg9GxnHWlAypHAHb3owNwpxJKn GdvYYqgtcgP+qPXP1qMjcD1z2qV8E5J6/lUZ4ycnFJINFoc1rQH9taM2MuLk8euV P+FbRb9yHwvT17Vh+IGCtpThul6oPPqDW5kfZx9Old2I1w9H5/mzycG4rGV16P8A BCbsyckDnsajIUyEZ5z1FPOWPQMD6GmMG8xRzjtXDFM9OUtLDQpEmWPvjPWmHAT5 hgg9acxLOTgnPcnrUefl2nJ7EVSutSXZACQnOQo756VH1bBOGHtT3GRtUZHvUbsR ET1IHTPWrUSeZ7dhjyqqFmKrgcknAHvWFca/ods7x3GrWKMRyvmgkV5Smj+OvG2r 3FxrFzc+GtI8wiO2P3yoPGAOPqx/KtuL4SeHljPnXeq3MnUkzBc/kK+njluWULLE V25dVBXS8rs+Qnm2cYr3sNhlGPRzdm/kr/idlF4q0C5lEMWr2MjuMKBMPmPtW4h3 t/Cy44PrXla/CXw3HqkM6yXzRxOGMLSAhiOmTjNepjChVCleMZHYdq8zNIYGDX1W Ta63R6mU1cxkpfXYxTW3K3qLv+UseP6UyQ5gOQCSAASOaRmfYAoLAnnjFRtliFYk cd68lqyukespN6H5RRlk04u2QQhwD06V5Vr1/cx63cKkhVLiJSyjp/nivU7dRJp6 xt6Yz7elcxq3hdNR1sTxy+TEVxjaMDAr4nLK9KnXbqH1mMcp0OSC1v8AoQ+D4Xsf C13qgKuXYKFz0A7/AK16PZSmewt52+86BjketeYadb3mkeIUsZizWzMAB2avV4FU RRojYQDCgV1YpqdRyvdPb0M6K5aShFaotR42Mozu5GM1YiACDt6HNVEZvNyzMFzw PanTXSwWhmwCPu4I5rBqK0HCTnNJb7HnHxRiJi0aVRlQZFJ9zsI/ka9T8N3f2rwT pMjsCzWyE889BXnfjQW91pNpNdFo4YZPzyOg/Kut8Lhrrwnp725YWwXauR0A4roq Tc8IkujYU8A4VW5ytc9Et7hFYqGAxyOa37a8VJDtACjkYrmbGyU4y5IzXWWdnHv9 G7k1lFS0ud3+zKzszpbG+ZpYk6gnoB1rrYHBCgjt1rm7OGJYlbnI6ZrooUO1QGYe +OBWijdanJjKkJJOKsayIDbkHIHY1MsYLAZIGOlV0cCA4OD24qWF18s5BIP6VtJa aM8+MepYjQIBwF9qkAyOOPYVWVioJJG4DipVfKg7iQeg9aqK0E5K5bX/AFgXjHtW hGygAb8jsKzFyJF5zk4q7EcIQfrxVcl9EC3L8f3h06cYp4xv64x05qBclAR97sKl U/Icg03GwW11LqMwfdkAnof1qvq/Ph25zg/LkH8amTHJyTUWo/vPDd4vI/ctkH6V 14O6rxfmjlx6/wBnqLyf5FvQpN/h+3Ug98c10CN0yPzrlfDrZ8PxEEkhsV1MWQRk j8Oa6MUlGtP1Znl3v4am/JFxW64B69asRHDHGSMVVXIc5yBnn2qwhJA+Yjnk1zpN JHRfQuLjaMHmvL/id4qfSdATSbN8X10vzMDzGnQ/ielenAnauchq868WfD+PxNra X63b28m0K2Txx0PSvpeGq2Eo4+NXE/DHX59D5fjChj6+XTo4Je9KyfTTqN+Heg6f 4b8Lrc3csB1W6AkmdjygPRa9D/tXTtpP2y3/AO+q8mHwod/9fq9y69PmkarUXwk0 4IVlv7lgevzE16+NWV4uvOtVxDbf908PL553hMPGhSwcYxjteX46Iv8Ai3x7oMDp oSSG9urlgP3Q3KhyCM/lVrwZZWkuta0s0ERx5csQI4w2/wD+tVzSfh94a029a5ig FzdhSA8jbimeCat+HtEvtM8QTzyEm3e3KPnuwZdpH4A0VMVgoYGdHDtqyTu927r9 NAoZdmVTMqWKxajJaq0doqz6+rOxSKOL5Yo0WMHstZ+r6Pa694euNNvk328o5x2I 5BHpWseHOCwXuafFx0BA718rTq1ITVSL1R91Ww1OrTdKcbxa1R82at8OfEnha8k1 Xw1eTXUEXJWLImUfT+L6V3PgP4knVruPR9dCw6gx2wzdBK391h2avXuQ5wBzXzV8 VdIt9E8bWOp6cwtZLxGdlQY2yRsp3j0+8Pyr9EyjHxz6+DxkU5te7Prddz8uz3Kp 8NJZhgJNU7rng9mm7aeZ9NLyB6+ppytyQApwBmsvRbmS+8K6ZeykiS4tI5XHuygn 9TWoM81+fum4Nx7H6hCfPBS7knRc/wBaOBJn39aTd8gzzTgR2z+NRe+w12H8Z5O3 A4yKeOY84A7UzjjOeeue1O4wR8wHuaLaj5nceQAoBGCPyNMyMNkc56ihfZm9Dim7 hlSCR7UO4JuyGP3B6549qiYZAHGcc8VKSN/ck1HnnHPXpUryC11qcx4nJWz05s/d v4j/AOPCtxcCJeV5GCRWD4sfb4dgfO3beREn6MDW2udiEccV6lZf7JSa7y/Q8XD2 /tCv6Rf5khwW/wBZx6A1ExATOPl7e1BL+4xzg96b1BO5lJHr1rzkm9T1rrlANhDh dx7ZqM8nk80EjcvLcHjjqKjbnOM7R61oouxm2uobj0xjHrTTk5Jxj2oJATPX6803 JA4bHrQthRfcaQNnB5HrUSsGTacZFSN9wgnnOajYgDK46ZyRT6XSFJa2GOrE8HAY dz0qMjc6ANnntQxY5J+92HYU3ODlmIb37U+XuQ7O4MNpAJJGeCDwaiOQ55zt4BxQ eQcls0xs4PJPtjiocnsTfQ/KSzbdbIxGFKZznPaka4ge8lRZVEsQ5Ddce1Q2HOnw 4BHHPoeK4DxGLuK8N7ExSKZjGSvbHavhMPhVXquF7H2c6k6VF1EtEd1peoW2r3Vx HEI2kgJ6jqOldZDgKoOCw9K8U8K3Jsr25cqf3kexeMnJxXrmkGU6SjTBhISTz9a7 q2ChRqNR2MaM5VqXtG/kbAChlPctwc9KfLAs1uYnIC5BwD0OaYMqMDIz1BHIqSI4 fbg59amMdxarW9mcN8RYEj8C2pUHi8UfQbX/APrV0Hw2lLfDaBSdwjndSCffP9ay fiMhf4fpJyQtwhOe3BFWPhcwbwLMucul4w4H+yldUYr6o79/8jhlzPEyv2PZ7Qn5 d2SuOMV09qPm4G49eTXLWrfLjdn2NdDZtgKe2KwUVZM61JXsdfaHOBkZNbsJw4AH UfWsG1OHBHH1HNb0RyoJJ44x1qqXkRV8jRGAcdPpUsRyvABJGetVySOASc8EY6VJ CxUZzwP0rXl6mEb2ZL0J+6AeM96sRnCjJGTnrUTcx8HJ7Yp6Z8rd0bHTHQUox0YJ JlteuQRV2IjoGGT0qhF8rZOSc5GauoMYOeM5rdaaMSTWxoL3/WnpuEe4ndg81GjZ QbxgjvTxww5I9OelLbYtx6ltBgF8g47UXI/4lNwp3cxMOnIGDTFbD461bKhoXHYr jPY1tTb5l6oxxEFKnJepQ8NN/wASHOQPm5rsIx3GMelcT4WcHSZkOflcZ9eldnGc 4YgK2OQDXdmFliZ3ODKHfBU7di2vUdM+9WExtHyjJOPrVZSCQckYPfvU8ZAbaSem eKwWljuu2XhwBkjnr604HkDP41Cuc9WYZ9aRgxhZVIDknBrWEU3cyqNq7Ri694t0 fw9bZvrhTKfuxLyzfhXm83irxp4nmMWgaedNsnyFnkHzH3HpXL3ekavpXjp9S13S 7nWIlYkNENwOelejab8R9BjEdvPb3OmjHR4iAPxr9Ehl9LB0ozwtJVpPq9UvRH5V LNsRmFacMdVeHgnZRWjfrL/I1vB/hnVtIunv9V1ae9uZFIkjZsqPoK9BDDnpxVCy 1Cz1GyS4sriKeEjIZGyKusT0J+bvXxuYYmvWrOdZWl6W/A/RcpwdDDYeNPDu8emt /wASUE7QF49ST1qOW6t7WBZLq5jtlPAaR8ZPtQpGACenasXxB4Z0bxTosdprFu08 Mb74yG2lW9RWOFjS9ovatqPWx0Yt1lBulZy6X2HX3i/w5p1o0t1q1ojDoqvuY/gO a8Pvor74o/FKGSCCe10G3AjMjgj93nLEf7Tf4V6pY/DnwnYGIrp5uGT7vnNurf1K aDRPBuo3UMMcCW1s8qoigA4UkfqBX1mXZjhcHU5cFFupP3VKXS+miR8RmmVY7H0+ bMZxjSh7zjG/vWXVv8kjjfEfxGtNAujpOkWJv7qABG2nEcWBjbx1I9Kx9O+MRF6s eraQYUbnMT/MP+AkCqvwusIr7VNSv71RcvHjlwDudyST7nj9a9d1Dw7oeq2/l32m 2sg/hYRhWz9RXfjpZPgKzwlShzNWvK+t3ZniZRHP82wyzClilT5m+WHLeNk7K47R fE+ieIlk/sy+jnmiA82E8OgPTI64966Nc4AIHArjPDngvw94Vu7q50m2kW5uRiSS SUu23Odoz0Ga64knOcDA6+lfHYxYd1n9XvydL7n6Rljxaw0PrTXtOvLt+JNuO0D1 60uAeeP8aiDDGd2RjjjrTgygKTz7CuPd6nZZEigc9u4NICWKjIz35pu4H2FHbjoO tHK7FK17jM/IFA59c0ZAXjHXmkJOc9VxQzEkZBA64q1sZKXmcj41b/i311Iedrq3 T0YV0kf+rQ4Xnr7VzfjJWk+GepDG3930PYZFbliwl0iCY/eaNW/TrXpTj/sVO/8A NL8oni0ZNZnVXeEPzkPPMhORz78GmMSVwCcehqU42PlmXn0phZAoIQj61510es9S IqckACm7GIY46c9akMrhQF+XbULsTIQ2c+9WtiJO3QfsG7LlAMetQkqGKgZ/rQeV AGSfX1pnRQcHPepWg3uNY7QTuHSmHDfKmOR60rEMSoJHPcVCw3biOFxx71d7aIzV 0Jkt8vyjHr2pjFfnDKOmBmlIUIOSw7kCm4x97d04zTb7E6iOQYlPOe/cio3yEUE8 +1Px8m44GabgEd/xqG9GJWPyV047dIVgVRSgIJzzwKpXdraahbi0kkVSrbwPQmpt K2voluM7v3QJz0xgVyviOS4t9Sa6tkaNEYLuz06/4V8PQoueIcYuzPsHUUaTk1or GvBLpb+I4bO2xHNDyHXpkDpXfW8u5skEjHPFeHaDLs8RGeVjuZHwT3YjA/nXsWjC VdEjacusjuxG49q6sZgvZyXvN2RGGre1pOW2uxurhmLHqfQZFWYc4XOMYwAD1qlx t5449asR4EnGDjpWcNtEKKcWZXi3Tn1PwXJbRbTL5iEEn7ozyayPhSx/4RbUFz0u +nrlR/hXdhSYDu+9t59685+FLsLLWI2OAssZx9Qw/pXVRlehNLujllb28fNHu1qV 2jgbiea6Sy5AIAA7elcvZs2Rzx1xiumtVbaAGAJOTWeqjsdHNtY6yzO0jI3HsT1r oIMbQeSB6d65y05IxjHat+3OwDOQMetXHUVTY0yfl3Z+WnoeegxTQAY/mAUH2pqs xkz0BrSW1jCOhZyfLwOQakUDyxwu45781XJPINSRH5AAPz6UotC0TL8bN5YDfy7V cQhVzk+3FURkN3GR2q0D8mAW9c1skTZp6mjExNvkYPOOKlXJ6belVIshQOTnjpVg HnHtTbSY0i4nXJwKsoS3mKMEHJxVROPUEd81bjbO4ZyPbvQm+gOKtZmR4ZbYb9Mb dtwQBXaRHK468Vwvh4/8T3VosHIky3p1NdxEedu4gegr1czX7+T9DycjTWEgvVfi XV+8CSc5q0m4Nkc46GqUbYfBJJzkZ61ZViXHQfWuONtD1OW+vYvKflHH4U7cQ3VS e1VlbMIGeAe9TIxDYHAIHGM1pF9SGtSdgrxkMA4PUHvWPqPh3R9Us2gu7KB1bodn IPrV+5uoLWxmubiTy4IwWd2OAAK53wt4x0zxXcaommecY7KRUaRlwr7gSCD+Br08 PSxcaTr001GL1aPOxdTBzqLD1bOUlon1XU8q1aw1f4ceJY9S0mVptGkkwY2Py5/u n0Poa9z0bV7bW/C9lqdmxMM6bsHqp7j8DWP41tI7v4Va4soDeXavIuezINwP5iuD +Dl5JL4Y1uxdmdLa7V4+egdTkfmp/Ovp8ZNZjk7xc1+8pySb7p238z4rLKbynPvq FN/uqsXJL+Vre3k7HsclxHBbPNKypGilnLHAAHesLw94z0TxJf3Npp87NNCN211K l1zjcK8l8datq0fxEudKN08OmzWqmRexTByf0NcH4CvZLH4x6IysVEs5hf3VwRj8 8V34Hg+nVyyeIk7y5eaNvS9meTj+PasM8hhIQtBS5ZX3etrrtbc+hvF/j3T/AApq VrazQSXl1Kpdo4iPkUHqc+p/lVHxtr9ofgpLqMG6e2v4UWJ1GcB+59OK8J8c6g2q +Oby+DeZE7lIjnogJC/ngn8a9g8KxNefsueROvmAWlwqb1zgBnxXbickwuW4bB4h xfNzRUvO+v4M4cJxLis5rZhhYy9zlk4abWdvxTOc+HPjLw/o2j6jbajdG2mknDxk xkgrjHUfjXpJ+JvhNGwt+0wA/hiP9a8x+H3hvQtdvNR+32nneSVMag4BGWBz/wCO 167H4J8LQx7Rotm4YYO5ODXPxJLJ44+o6kJubtfVJapG3B8M9qZVS+rzpxpq6V02 9+uyNHw54p0jxRpk95pFx58MMvky5QghsA4/UV0hbkg4xjkVm2NjY6ZaCDT7SCyt x92KFAij8BVzkx5ZSdxxx3r4Ov7J1W6atF7XP0/C+2jRiqrTn1aVkWVJ3Zz+dPBw QCRn1PaoEI5X+IelS5IkIxzmskraM6o6u5JjJwcZpvIyP5U3Py55HPpQcf8A6qFs OUQyduT+GO9J/AMMM0HhuOcUwZEWM4/HPNOK0JvZHOeK03/D/U0wSPJ6A+lW9GlL +EdMfGSbZDyefuimeIct4L1XOR/o7HP0HWq/h9ifBOllTnECjP0Ar0028uX+J/kj 5/SObvzgvwk/8zWxgEHaR2OKYeuAcfSpCx28liO/NQ5G/PJBrz2/e1PZcEnZikZb kE+wprZMfHH49aG/1mOMetNZgVHG4U09QlGyEyfLBB47VETgkE5PcU7I4B6H0qN8 53jP4U0rkzbsrCnlRx82eKYeI8hRg8cdaiDOQQeoHPtQcFMgEt39DTskyYvmQ0sf L4wEJ59TUZZtgGcAjgmlPLkZwPWoyu5hk5qn5id1sKvXH3gfepAwU4HIHrUYQqex OMmgkgEdMCsL6mEU4x00PyL0nB8PW7dP3S/yFF9p9ve2k0DyFfMcOePSm6Pk+H4M rx5ajHfp1rA16/uNP16B0YqgQZH97rmvi6dOc8RJQdnqfbSUVSbe2ly4+i6dZtaB JwlwH6t0Y5rvLR/3SI4BYD8q8Wjmu9Z8VI6qzIHzt7Ko5r2HTLmK7tzNGCADtzXb Xw9WPKpyv1ZjhnCpFyhHRO1zWXKnkDHapkfEpYEMc85FQcBcnDAdeM0+NgUAA49c Vz2bevQm91ZI1Vy2CwwSfzrzv4aDyte8SwAMu2VPl9MNJxXocIzDxnA7n+leceAS YviH4mgHznzjgHviRh/Wt8HF2qLpZHPUjy1oP1PebV1KD+Fup5robZui/LuxxXNW jZYYxxxiuktchVOfp3qlsmjaV7q51lmqBgTn8DXQQHMaYUNnua5q0JZQTk4OTk10 luBhchjk96cY36DqWS0NVQDGBzu6U0heR0FCcrjODn8qaQAeMkA4/CtnHVPsc8F0 JcLt54yKImKtjJP1po3kDC8Dj6VMsfzgnOPftSCSLSMDtxjH06VdQ5AH6CqK5Eoy M8Y6VZT7qgYq7MVzRjwQ3AJz1I6VPu2nsB2qnG2SOuM5NTEtjIOT2yetO5a1tYvo 2AOxqxG+wFutUA5AAPIPHTvVqNsrtO4j26iqgrikrmPojgeL9TXn73JruI2AQHPO K4DTmCfEG8G4/MvOO/Su6U7oxjPt6V62Y39qn3S/I8bJdaEl2k1+JoRsC5wAO/Iq 4jDIGMnvWfCWySc49qvLgnjg1wXa2PXtbUsAjG3g85qwgGw9jnqKqr1yevpVhMru I3knpVwvykP0ON+INjc6j8Obiytid7OplUd1zzWR4Fu/Dnh3wj/Z7TwWt2HLXJkw pZvU5r0raZFIkGVPBBrktc0jwi1/DFqq28U9wcRBiAzH2r6bLcdGrhfqVRNq/N7u +3U+PzTLKlLG/wBpUpRUrKPvbb9OzOJ+IHxB0+78OzaDoMhvbi5+SWSE7lVe4GOp NdR8MfDtxoPgWSS+QR317L50qd1UDCg/qfxrf0rwZ4e0m8+02dhCJRyrsMkH2rpn bAx0ye9b5hnVD6ksFhItQvdt7t6E5Vw/ilmEsxx01KpayS2ijxb4pxhfEGlSRpm4 lt5Ijj03L/ia878RabcaR48s3tg0bLbQSI6jGD5a5I/EGvpbUdEsNWu4JruPe8Kk Ie4yc/0q3caPpl7JHJc2UMrooRWK8hfSvYyni9YOjSp8t1GMk/m1b7rHzOd8BVcf iMRXVRRlOUXHySTT++9zwKy8F6nq/wAIJbixhi/tC7vFaMSnbsiQEDn8TXsnhDRr vSvhXYaPqIiNykTrKYjkZZmP9a6aKGKGFYYUEcaDCqvQCpv54rxsy4jxOMXLL4eb mXl0X3H0eRcJYPLbThrLl5W+/d28zzTwL4Z1Dw/rN010uIXRlXn3Ugn8jXqJLbsA nH8qYo6YHFc94h8WaT4ZtI5NQkcySf6uKMZdq561XE5ti7qN5vovI6sJQweR4BRc uWnHq/M6cDkDaakVTswN3XjJrH0TWLHXfD8Wo2EheCQkEsMFSOCCOxrWBLfKAQcf nXm1qc6VRwkrNaNM9qjWp1qcalOV1JXT7pkiFcjIGQetTE4wV455OaiblAAwzu49 qdzwXOOv0qG3dGiWpIp6DjFKByOfyqLcARnkEZyadn5ehPcU4vuTO3QQ5ySx4qMk hsjaeOc9BQGCqPlPI6CmZJUgc4/lSa8g6mdrwDeENTUjhrSQH/vk1meGG8zwHpp5 DCHnNbGpKzaLex9AYXGc+q1z/hKQN4EsiARhSOPqa9SCvl0l2mvyPCrNRzeD7wf4 NHTAcYPv3qJxhDwR7intkSHIxjvUWecEk+vFeco9z17q6GlsjBHU+tRnaMZxnrzT mwqjgk5qF0z9cVcdWZylZ7CBwz54wOQcdKa5GwgqdtKSN2epI4x2phkIkK8tj26U uUXOrWZGzfKMDjsB3prEbQBgY7V5/rfxB03RPFsmmahHJblSNpdSu/PdT0NdBZeJ 9B1CKN7fUbbLdFdgD+terVyjFqlGoqbaZ40M+wMq0qXtUpLo9DePzNgDHrSgYVmx 8x9e1CESFTG6MpGQwI5p2AQCdxcntXnTg1o0ekqkZaiHapIPJ96aTjjGfrUh2glT u3dj6U04JbCsc8CueaTKUrJ3PyE0XJ8P25POUAB7ZxXP+K7SWeW2eFHkwMNtGcel bei8+H4NrDmPnnr7Vf8APUSFAMsoA2kZr4xVZUcS5pXs2fYumqlPlvZbHBaQZdI1 1re5ix58fllvTPpXqOk20NlpqxRSBlLbsnqa5jWYYP7ON9cAo0PKMBzn0q14Xvrn VdPZ5SBsk2kjvxmuupWqVoe0S8mZUl7KXsk/kdoMEEgjHuPepI8jHPHpVZSQ24bW 5xk1Mpbe5bjHYDpUrRltPl1RrxgpGoHzZI/WvNfCH7v446/ESMETE4/66Kc16LCA dvJz3rzjw85h/aJ1ZS2CyScnn+6a2wq1qLbT9Tmq6Tp9r/oe82wXICk5HANdHaZL kfKSO9czZtgrgk89AOK6W0bLYxz0z6URvv2NElKx1VmT5aNuBHb2ro7cnapJCHpw K5q0ZliXJ2nvxiuit97KACQaune5rWjeLNfhFwAOck5FLx0GPfFMV/3XB7ZAHegh SxY/Lj9K0SvqccW73RIp2tjg+3pU+cvgE5PYCqocbtoznqKtIykkls46YqeiXUGl a6LRzxkAA9zx+FPVispUHA+tQPygO48DODSgZjBzjPTiq0HFovLJyADyOxqwWJiA zkiqERAkBLcnkZHWrStyeoAPp1qrWSJT6l1DhjySd2DmrcfzRnAYd896z4y2R1xn uauQn5AevY1opq1il2ZjRYT4lsBgbou/0ruEHI5HsK4KQhPiXbEkgtFj+dd3Byin pxxmvWxy0pyX8qPIyf3XWi+kn+hpRYwSSCB1A71dUkquPWqCNjk5Q+tXkJII7Y+l ecrbs9izWxbUjbk59qmBK98D2qspHpkj9Klzz1+nvVw0M3sWl/1WfU55r5g+Jupv q/xAC26XERs08gN0G4MSSK+nA+UwTg49evtXzr8T45rPxbGYWMcc0e/cvHzZOf6V 91wHOmsxd1rZ2/U/NPFD2v8AZMXB+6pK/wChtWvxauILK3ivNIuGZEVXcMDuIGCe 1dBa/FrQpZU+2RXFijELvkGQK0/BNpp2pfC3Rrq5toJpzDtlkIGSwJB/lWb4wtvA On6as+u2tpuQ5jhX7znHTArebyyvipYdYWXMm1o+zsZU45zQwkMTPHR5Gk7Sj0aX VanqUE8MtlFcRSo8MiB0cHhgeQRVjzFCbgyqvUnPFeDavd6zc/BiXWVaTRdPhWNN Psozhlj3BQWPuO1chceNNXvfhbY6RBc3Kzw7/PmVj5jqD8i565xnP4VlgeD6mKgp wmrc3K/L/Pt6mmZ8f0cDUcKlJ35VKPS93ZK3Tv6H1SzJsLlhtxy2eAK4LS/iJoep ePDocHmBy5SK4YjZKw7D69q8e0XxxeL8JtW0We5llvZNq2srsS2x/vjPXgD9a5q5 s7jQPFmkXafu3kWK6jPTA3kfj939a9zBcFUqarU8Q/e1UPkr3/T7z5/MvEOtUq4e eFVo6Op83bl/Bu/ofZHCjPUmvnDVbWbxl4j8UXyFyltDI1ucg/LFnYo+pDGve9dv X0/wdq14nLQWkjj6hSR+teZ/C2zV/CGrHbw7eTnHUbcEfp+teLw5VeCwlbGrdOMV 992e5xdRjmOYYbL38LjObXmlZfqQfBe7kbRNdst5ZI5oplHoXVgcf98CvcFLD7xw PWvnj4Ms1v4h160cMrm3iJz6ozA/+hV9B7mP3cj1zzXPxrBQzitZb2f3pHocA1XU yOjfdXX3SZP8oOT1X1PWnD5j1BwO3WojxjgH8PSn7vmAwSy18u9dD7FRuh4HygHJ x0p2FJbIGQOmKYxIkGT+HqKFbIbfgY6Z60JaA7rRjCN3IU5pp4QbfvfWnNu37gOP TPSomdcE9fSkrhZN3I7g7raRcEkqeGrk/BrAeBoFyDtLD9a6p3LQsMHJ61xPg3/k WXjPyhJ3GOvQ16uGi3gKq84/qfP4uoo5rQv1jP8A9tO2LDAwSRTHXnIAOBzmlXJB PI5pvOB/FmvOaSPZaVhjjLZxlfXNRuRtJ7YxxUjAhgMdTzjvSD7rcH2zV62sY31a IQo3AZyuOc1EV6nGBjAwasEllJU57YI61EWyORg+lNX2BxTWhn3mm2GpWRgv7O2v ISfuTRhh9eRXD3Xwv8J3bu0FpcadIw4NrOyL+XI/SvRTIR8uMEHk9zQFB256mu3D Y7EYf+HNr0ZwYrLMLidKtNS9Ujx2T4V3dpLu0PxlrViwz8so3qPyIqWLQfibYHbb eKNLv0HQ3ELZ/L/69euEjlCMDoQKa3yg8Mfau95/jJq02peqT/Q8x8M4GM3KCcf8 La/Jnmsd18SrUj7RY+H9SXH/ACylZG/M1dTxB4qjkYXPhKVj2MF2rZ/PFdu3J4BH IpVBUlgTg8dK46mYQa96lH7rfkbU8unB2jWkkvO/53Px50L/AJF6ENhQB1rM1ea7 stfF7CoCHC+oPtWh4ebd4ehDDcOe/vWtf2gu9Pa3YAKXBJ7n1r87lVVPFSutLn6N RgpwSWmxw+u64dRsra2jyg+9Ko7nt/Wun0UHSIrC1IUTXGHkB7E//WrkrrRLu21Z pUibyFfcvc4zXpllDFNFbXsyt9p8sfNmvSrOkqEYQenU58In7WU6i1N1cCMF+Sxz x3pynJJdgUBwRVcEBh0JIz6CpkO4lgpUkZPGTXm3s9tDss7NGrCw4C4JPQ15rYN5 X7SVwOm7cOfeIGvSY9pYbByACMnrXmmwx/tJw8H58f8Aokj+ldWDs5SSXR/ocWJ3 g13PfLTJKscdeM10loxBAwRnsRXL2JG1D17101oSXJxkfSknY2UErWOotmPlAk7s 859K6a3Yh4/QdhXMWj5iTDnP05FdFbNhQSScHqauDuwm30NraWQM20ep9RTXIPAP 4+tNU5gAXGfTrmnE4TjCrn0rdtHM9dRANq4GPoe5qVWIAB79gKYCxUkHPtihiQgY fKcYGBzU3uzRRtoXlbdECcZ96mVzkADC8A+1VIm/0bBJAHapwcr15zTewrdiYcnj HGcHrmrAOMYwuTx2xVPcckA4qSN3wDg4zzzRGLuDXc0kOScfNn1NaURJHXI+lZaN 8wLA/TpV6HG4nv8A5zWkIpoqNkvUxL9vL8eacSCeMZPfmu+gGE5OM+1cBrjGHX9K nwVG/H45Brv4x8mQScnjFetilejRfl+p4uV6V8Ql/MvxRdjzjPy/U1ejGG5LEEdM Vnrjvx7Yq7GMY5OO2ecV56ir3PZdi4uARkHd9O1S/wAOcj61AG+QEkginZywH8Pp 0p2uzNRdyXcwY5xxXiXxciuXGmSLal7aMMHmHQMex/AV7Vkhe55xXFeP7Z7v4a3x UEmICTA5xgivouGcV9WzKlJ9Xb79D5TjXALF5LXgt0r/AHa/oeOeG9X8XTaJFoGi qEhSQ5kRORuJOD2A5r0TRfhpG2px6p4muZNUvFO4RO25Ac8Z9fpWZ8Jbjbd+ILBh 85EU6D2IIP8ASvbskKuWB/mDX0PE2c16GLqUKUVBPdpau+ur+Z8rwVkOHxWBo4vE SdSXRPaNtNF5WOE+JpMfwdvkUADfHwBjo4rzL4caOL3xZA0kYMUCGaTd0JPQfyr1 fx/Y3Go/D6e0gR3keWM7QO24Gq/gDRrvTNCuJ71PLuJmCgHGQoz/AD/pTy/N1h+H 6lOMvflJ/jb/AIJlnGSTxnFVKUoPkhFNu2l03ZfkfP8AY6Zt8dSaTGhVmvjboD2U Pgn8hXovxat47PxJoTqqRWqWgRW6ABH6frXpNn4H0y18dS647tJM0xlWMjhCSDkf jXTajo2l6wsK6nZQ3giYlBKuQCa7sXxhRlj6VaKbjGLTXm1+hxZdwFXjl1ehUajO c0097KL0OV+IupXkPwqkuNOhiuYLkqs79kiYfeA754H41x3w58XaRpugy6dfym0u JJy6uw+RgQMDPbvXdfEApB8J7qOMKi740VQOAN44+lcV4V8DaN4h+HcN9cpPaX0j t+9hk59uDxUZbPBLIZRxKai57re+6uGcU8xfFKeDac40r2lta9ml2vv6lb4fOkHx z1yKJg8Evn7SvIIEgIP5V771DDIH1r5v8I6MdF/aZmsku5bhIBLGu4AEgqDg19Hk 7u/5V53Gii8dGcXo4Rf4HveHbnHLJwlvGc0/Xr+Y9emV5OeM1IcFRggE9RnNRjGO eT2pxKmT0FfIM+7vZokJJTcVPXGe9IWIGDgDkAY4qJ5Pm+9kg4qEyjz1UuoYqSFz yQCOfpyKpJ2Jk00tdB8k3zhR17cVCSfQZ7cUh+8NvJ/u0FiEyB+Bp8qM3OW40ksh yOSOlcf4PGNOv1IyBeydP96uwJLLjgfSuP8ACTf6PqoJztv5F68/er18Nb6nWXnH 9TwMak8xw8vKf6HaZJ+XcAMcVGD82Rggd8Uu9cKe5FM3cnPTPHevLfY9gCTjA+bJ qPcQO2w+ppxG1BzkZyTnpSbS6AHPAyeKvl01M78vqMkU7s/KTnueTTGOTkqQOecV YIAG7qT3prMoC5IK46ZpMEk7lchcg47ZwaEVm6sBg8etPZ0AyDkjNQNLtjIxhc5J qn2uDaW5JJyMk5O76VETgbSFBHv1qHzeOvfOc0u/5MjmlYzUuZ3HtISx4UCq5Y4I 6Z9qazqBkEcDjmqk0rH7pyntUyjZkSbtfqfj/o0nl+F0kJACbiBjkc1pTaxDbwWz NhhM2AwPbuf1rBsi3/CDSYK5b5OOuCa5h3le7it5XYLE5XBP3eea+aWCjWqzb6Nn 1rxU6NOGm+h6+jq+6Nl37u1X0ISNVULjHT2rnNMmabWblwzeQq/J6Hmt/cAoIxkj jPWvMjT5LrudFduGt7ss7iMPu4IxkVciYmRmU7VqkpO35cHHH4VNGoM/IPT17ela UpK70Eovp1NiI7cdCPr1rzu/JT9orTZCDhtmABnIwRXoMRUqAQR6ADmvOdcPl/HX SHDAjEXUcY3MK7sKr1Gu6f6HJipNcvqj3W0b9ygBUriumtGYyAkADrkDiuLtrr7u 3djPYV0NrO5kAwcE+nWs4NR2O90KjO4tMDoefrXR2pBjIypPpiuKsXmZlVAwweGF dbZbi2RnIraFn6kunyrc6BDsQAFQO+B/WpVIJ4HP0xVSPmPDA5HpUynbJhSSOgFb RfMmjj5FfyJASCNu3k//AKqMgAZwGzxULMuMc+tGcEdcHocdKlpopJ7I0EBEOGIJ /lT95AI4PPb0qvGzZOcKPpg1Ln5OO45xVct9WGvTQsKcgY2rTlYjjcCAfWogVyBz 9Qf1p+No9TjIyOTVS7ox5W7Gkrbhxgcd60IMAZxkgfWsm3VgO/J/WteBeM/dbPBo Ub6oave5ieJU/wBHsJRgbZwN3pkV3lvJvt42BGCoOPwrjPEqlvD8bYztlBya6jT3 D6Vbngkxg/pXrVtcHSfZtHjYR8uYV4vqos2EIL4yBnvVuM4jK5B/HP1qkpGeuD6V YQ/N368V5vLY9u9maCk8d/WnjPJwMfrVUON4HLevNTBsdM/jWrXREq5LglSuQpqr e2sd9o11ayYMc0RU496sgsHwM47ZqUdPw5GK1pTdOSknqjKtSU4uLWj3+Z5b4L8O XukeJ47uZNqtavBL+DAqc16vyoI4BqMKM+i96e2SBkEj9K7cwzCeMre1nu0eVlGW 08uw6w9LZa/eLgE7iQTnmpE6YBx0xg1W85FlCeYu/PTPNTr94FuAD09DWD5lZNHW 5KTuncsHCqM8npjvUqHtgH3IrivFni+w8JaELy6V57hs+Tbp1bHU/QZ5PvWn4V15 PEvgLTtaS2mtVu4i6xSDBGCRn6HHHtXdLLsRTw6xEo2g3ZPucEMww1TFSw0JXnFX a9fw+RmfEC3uL34eyW1ojyztPH8oGScHJqx4HsLrTvhtbWlzGYLgM5KsPukniury ASMdOetKOEzuOPUVusxn9RWFUdObmv1ucX9jU1mTx7k3Jx5bdLXueIeCND8Uf8LN l1jXbeXzFldZbh+N56ZA9OmK91DehGKj3bZMAdaY8gVQDncOStGb5rVzCsqs4pWS St5E5Fk1DK6Do05Npttt93uWtwGckn1pnmqBxge+aoiWRmbltuc8dqmUr8uBnPI4 rzrI9rnvrcm4JOMYz16VG6RPcJcFFMqgosncLnJGfTIFOA/hIwvp60v8RO32wOKf QlvYj3HPGPqe9OJwDnbj0zQeeo+gxUTeYGzgAY6iqSVjNzlbckbGzkgA+9cN4QYe fr4U5A1ObA9s/pXabsknJzjBWuE8IYXXfE6klf8AiZy4z0xxXsYSP+x1/wDt38z5 7Mm/7RwnZ8/5L/I77O2HOB9MUEbl3DlCPWmFzntu7Z4GKbliv7vGPpXkvue49dCY NGsQxhvrULSlnwo2j1qEuc4YA464qPJJPBAHQ4q1EiTuTmU4OQc8/hUGfkxmm7jg Ngmo9xHQknoKIxtoS1dkryAlsKAAarOcocbRkc5pQW3nPB96jY9TljkdqqLS3E22 7ld2YckAE/nSGYnHG04wealcZkAKliOgqrgNLnG1sDHHFK72Jd0PfczDkMT3xVfk A9DxxxUzZVtrEdc4zUO4n73H04FTJW2InbfqfkNoBiPh8LIu7a5PT3qpPoQkuLmU S/vHYso9yc07RGCeHZZWyEQkt2q5dapbR6B9phk3SbtqoeoNfKydWNeXJ1Z9f+6e HhzdEXdCjuIBLHcRlMYAAP15FdGCpkIY/j0rE0m5N1pUNzI37w5x+BrbQZXO4ED2 rhm5SqyvoVOktGtV+hbUEoMhenX1qxCcxDcM4OfrVVCNmCAAPyqxEcueduemKuMY p3No2ur9jUi9ABnORxg15z4mjx8YtCJA+byc4P8A01NehxfKp3DaSeeK4DxWpX4l +HpDgEug5HpJ/wDXrowLXtdet/yOTFtOF+t0ez2UMZC5zkeldXaIiqpABJ9a5qyD 5+bIHvXS2oJXPYHtVRjrc0m5ydzp7YqjgdGrqLT/AFuOMFea5a06phAT2xXTWxBc Z4Pb3rVpbCk273NyNh5ZBBK+meh9aaSNuMcdiTUURALoMqepzT8Y75IFXFcq1Mm7 sc5UbSqqfrTWbDL8o9KQ4DAjk9/anA/ICWJ/Gr5k43LS925OpPyqcjnjHpU6Elt5 444qFADjnJxjODVgPuyACxHWhxZN09SQnJ5Iz3qRjukHqBx61Fk+bj259KdMcNkD ouBVNMjmd1fYvW4BkzkBfTvW5BjYwAzz+dYVrggdQcc+layNgAepzWkeiFqtSrr6 b/CVzuC5BBxn3ra0ImTw1aEhFHl4OO1ZepDf4YuwoyPLJwOvFT+F5CfDMAweCR1r 1Hd4HXdS/NHkQi45rdfah+T/AOCdYpXdyAPSplY7lyoK9sVXHDgKBjHFS5Hox/xr zk7ntLbUtBgQuTnnnmp1dSSDyM1VUgrtBOOuakA+Xp9SKFfoCle6LyEkbshsHj2q vd3cNhptxeXLLHBEhZ2J4FPUt0A56+xrkvGpdvCMNsCQLi8hiYexYZruwGHjWxEK ctm9TzM4xUqGFqVFulp6nWWl9Fd7ljPzoql0PVCwyAa5bx74nbwx4NMlsytfXL+T aqfXHLY9AP6VraEEWLU50BLTXrk5HZQFH8q8a+Isv9r/ABh0/SGkKQQrFDnsjSON zfkV/KvpeHsroVc0UZq8ILmfnbp97+4+T4mzithsmU4ytOpaKfbm6/ccPf6h4k08 6ZrE9/dRXF4pmgJlJ3AHGSOmD6V9NeFfE9j4l0RZLWRXuYlRbmMjGxiBn8M5/Kvn f4j3UOrfFWx0HRQrJaJHY20an5VfOMfqAf8Adq18ONRfw/8AGWXTrv5Fut1pKCMY kU/KT+II/Gvvc9yuGYZUqzio1Yx5klpp2+78T4LhvMqmV5q6MZc1KcuVt911T83+ BseO2l1344w6MeYEaC0AJyBvIZj/AOPfpX0Rmz0/RIooxHa2VrDhRjCoij9AAK+c 9IzfftLzyS5cDVZSATkjZuA/l+lemfFDUTYfDOa3V9r3ki24Cn+HBZvwwMfjXhZ3 gpVcRgsAtlGN/nu/wuexw7mMcPhMxzKSu3N2+S0X42OA1n4u6vca9Imh28MVoCRG 0iF5HA/ix2Ht+tex+Cteu/EPgeHUbyBIJSxQ7VIDkdwDXN/Dzwna6R4Siv7m3VtR vo1klZ0BMaHlUHpwefUmvSY444oljhEcKAZAUbQPoBXk5/j8ukvq+FoqKi7c3V2P a4by3MoSWKxddtzXwdFfb7vJFjzAUXOOe+eRTGUSOWBJJ7jmghywA4yeoPWnkfLj +EDvXytraI+yT022AKiqzDGM5NIuMly3UcYNSDYI8d/rUYUA4xgHt1p9Q5nYep4w SuB796ceMgjP40iD5QCOTThwwJHHcilryonma6jA24A7Svrmo9x3cYY9APepcY5x gkYBqBhn5sH1/CmiFdiNI27oFGO9efeEpM+KPFIPONTk3Ln6V3hdWjzy3YZFedeE Gz4t8WAYP/EyfAz09TXt5al9SxPpH8z5vNW1mODXdy/9JPR2kBO3AIHQg+lREk/K BgZ9aRmGAeSPUimtlTk968lLU99t9QYqF4PA7ZprONnAYY4JppOHxnj2NNYllCrg mqUbvQltiljjGRjP500t8vb39cUgK+bnBAwe9RSfKMkZHOBnjFGnQIu0RS4yASB3 /GojkBlHQ9c0pwQFOeTwTUe0gA8n0OOKpwM5XaELDy85XOBx61CWyQwwPTmpTlP4 CT0NQ5O/FJrXYlq1kwJw+TgsRTDnPIH9CKRwVz6AdQabjuBux3qKl7Mn3r/M/HbT kMnhm4QHkt2H0NYF2kkV60L8bT0/Wun0BwulykjIEnPtxUDWUVxrk95cuotXJKkH jPQCvn6dZU60+bb9T6mdGVTDwUTT0tjLBp0dvnZFzKPfqa7FCTEye3BFctotv9nl lMbCSNjhWHeulDY2+YuSeRjvXnVZLndjslLRJ9C2jYiAb5SMjAzip4v9ezAc/Xmq u5VHUGrKNt5BOT3x3rkje9mTZ3u+hrQbsqMDHfIzxXA+Nvk8V+H5GcYDHt0wy13c BDKG7Yx04rgPiE2260QgnK+Yd34pXdg1evG/n+TMcZJey/rue32ZAVSDnjGT0NdH auAmMAqOTjqK5qzbhQ+QfbvXRQECMNk5xjaB1oS1TZcovV3Oqs2HlJjAPHfpXS27 c8AdPTNcpZMFiU46HuK6W3yVbB689a6Y8t22Dbmlbc2oziT5j36ipwBt6++aoxsR O3sOVq6pwgUDIxWrcVZGULSV/UVmyMMM5PXPSkAxLwABj0pSD5mF3YHH1qI4Ld85 5qVZ6I1so3vqXY2ABGQB1GKnBAJADDJ5/SqKc8ce1Xo2ySTyfatOXYy5XJpdCXrt OduOBzRIcOzE446UdG4IHrxUbMCQMN6YFKN0kNdItFy1k/d5Jzk561rKxZs8n0Nc /E+JWVcEY4+v9a1YWYYAyPbFdHLdKxEm+hpyBH0+WMgcqR1xis3wfMW0GdMkFJSC PwFaKEsuOM4rn/CMoS71S1ySUmz68ZNeph6d8HUS6cr/AEPDxT5cxoN9VJfkz0VZ FRQFIJOMVYDZIGCw9zWdG2Bkc56CrKEcbevfmvLlBo9yGu5eiIyO3OPrVuLCqC2B xnFUUOWHHTn6VaV93B3ADqKcIml9dC6p3MGyAM8AVxvjosnh+wkRdwGpQbuOAN4/ xrskOFAG5sn0rlvGyyHwBeSRgMYWWXnr8rA/0r1snko42m33R4HEdPmy2t6N/dqa vh9dugh2UbmmkZvxY182fEJpR8TtaljLI/noFIOCMIpBH5V9I+HJTP4aikX7u9iu PTNeEfEy1a3+Jly7qwhuQkqsVwCcbSP0/WvteC6ijm9WMt2n+aPz3j+m3keGnDaL i/8AyUsfCfwRdXGvjxVqiMLeJmNkr9ZnORvPsOce9SfFbw9LpXimHxJY71iuXBmZ ODHMuCD+Pr6ivT/ho8rfCGwVwwCSSKgPpvOK6nWNKtdb0O4029QvbyoQ3+z6EH16 flUVuJK9DPZ1ajvFNxt05b/0/U9Cnw3QxXD9OlTVpySmn15mr/8AA9D53+Hd2918 VrS7uDunnkkdzjqzBif1Jruvi0yt/wAI1FKxWCS6fzDjheEH8ia5Pw74Y1fQfjFY WckMjRQ3GVuAMK6c5P5Zr0/4j+HbjXfA6/YojNe20gljjB5ZcEMv4g5/CvXzPGYd Z7QrRmuVxtftdSS/M+XynL8X/q7iqLpvmU72fWzi367Mg8T/ABHsPDuoNYWVv9vu kIVxv2oh9M+vsKzNG+Kqy3mzWtLaziJws0bFgv1BwfxrxO21Se08SLdyxRy3UMpZ o7pd3zf7Qrpdb8XaVf2SJeaTHaXjL8lzaYAU9BlT1Feq+E8JCnGlGjzprWV9b9zw lxpmVSpKp7bkknpDlvFrtfe/qfU9tdQXtmk9rLHc27p8ro2QfxqwAqqQx6jPNeLf Ca+u2e806Qt9mQB2Xsje31/pXtUgbYTxgdK/Mc2y76jjJ0U7pH7DkGbPMcvp4lRt zdPTR/LQODsycKDyfSpVKhO49BjAqJR8vXavUHFLggkgk47YxXlpW0PaehIpy2cH A9TRngngd/fFNUkhdy89alGN27qM9qckTbQiJAiOTn61UZmK4yDzzmrDEbzknAOD VMrwSQBn2qrK5HM+gNlYyCBn17ivOPBZL+LPFj9N2pydT6ECvSHPygbt4Awa848F EtrvidznDalNx3HzCvbyxS+pYm/938z5nN/+Rng7P+b8l/mehnBBbj6HtUZPHTce hx2pwHAP6elN4GSV4xXk7H0aSaGFhnGR9DSYxGSox9KaGAwcZB75prudvKc9/pTj Bojm3bD7zDBxt7E96YSDKcrggcZNKWYsAoOccH1qNnJiwThh2xS1tqZxaauIzblB CjdjimlyowQB6Zo3gRgEduOKjy5XJ+UdieKqzvdoalroN3nysE5HYGoS+DjGB3Oa lPvwPQUhIIIXIwOPak4q1jN3ktWRr1zjjsKYSAC3JPY+lSEEMuX6tznrUZZVyx3D 1rKcrjjdaM/HbRwW0a7xy2SR7nHFYUkswDQEkDfkiui8P4axnjOcF+cHmsa9t3/t y5EaEqhz+Arw6Ml7eaZ9FOLWHhys6fT/ADbRNPtf+WjndIo9z0rq15XaCoPQE8Vz WizrexLJID9piJG49+OtdCCSqhhxXiYltVHfR9TvvFxSS6FpCoVVfB7g5q0khkO0 gg5yTVJGwgIJ4YcdqnilCljg7W/hBpOLumTGUVotrG1DywLDj6dK4T4h4ZdIOfmz Jkf9813FvyeQSv8AKuK8fZ/svTD2WVgMdOQP8K6cHU/2iNv60M8auajdns1gf3EL ZHKjjGO1dLbNyOMjHAJ6VyGnP/oNsd3Plrz1I4rq7VwCCSCR09TTg7O9jVqK6nS2 LMY+cY6Y9K6a2OJOOeOc81ytow3D5uO/FdNauFwwye5ziul7mSnaxsRkG6JTAOMn FWwf3hPIHTFZyN+9I5ORjrzirwbIHOcjH1rRO+pNGS1J8cFQeP51HjjpnnOaQHDg Hg+5oYgBQGOe2RRBu9im4tXJEIwMA8+9XY8YxnHpxVCLJyoBOegHarQILhcb8cYP FVoggm1dF/quFP1qBl+U5IyBTS5SMHduzTXdSp5IHQeuKpSVmiZtXJIsAKw2nHBI +takTYJ5I9/Ss5SJIyoPbqPWrsDFcDkHHPtW8bJaGcrdTajOVXIGPcVy2hkQ/ErV 4M8sNxA4B5FdJGfmJG45x1rlLZvs3xtdApBmgyOP9n/61evlSbp14v8Alv8Ac7ng ZtK1fDT7Tt96aPS0IKcdRwKuRtzxxgd6oxk+WQQato2TtH3iexxXlPVH0UWX48eV uA6/hU6EEnPGfSqoBwBjGD3qdD+7XnPFCjzaJDu7tFxTgZU8nrk9aLq3iutMltpu Y5UKv9DwahVsHJOTn0rhPHer+ItKg06fRYTLHljcnbn0x0/GvQy/BzxWIjTjJRb2 b8jzc5x9PB4SVWcHJLdLXfQ9EsrSGxsktbcFIlPygH8azNb8P6X4ht0TUIRI6H5X /iFeGj4v61FEsR0+F7gEDG45z9MfpWg/jzxrb+HW1m50uOCyXADSAjOehr6ynwrm VCrGfOoyb011d+x8VV4zynEUZQ9lKcLarlukl/ke72FjbaXo1tYWcYigiTao/mat 42LnueufWvHh8X9Li0yylms7l5XjHn7MEIe+Oma9P0zVbPWNDg1CxlWa1kGQQent XjZhk2Ownv4iDV29fM93Lc+y/HP2eFqJuK2S6f19xdyHl3ELnPFTiVeh25HPIrnd T1/RdGeP+0tRtbR3GVWRwG/KtC1u7bUNOjvLSeO4tpPmRlOQfyrjeHrQpqcotJ7P /I7IYyjKUqcZrmW6v+Zj6v4S8Oa7NJLf2Mb3BPM0WVfn1Irml+E/hGS7SR4r6RUI KxNcHH8v616E89vDt3SJHGT1Zhiq8epWBk2pf2pPGR5q16mFx+Zwp2pyko/M8jF5 dlM581WnBy87XLmkaTYaLYtDYW6wg/fJJLNjpk1r58w/dwP96qkc6PGuxwwI4Kkc 1YQlRkZPPHavKrzqSm5T38z2cNTpQpqNNLlXRD1BIAG3bjjFK3XaD34NMU/N8q5J 6c0quRnfnn+Id6zdxt7EpYkrnjjvSAsMtuLD6VGxYADLE98CmF/3XzAgnr70W0Ju K5+QDj61CT3Bz9e1SvhixJIPHbpUb9MA8Z/OnqTJ6O5Ew4+YjJ615z4EK/atecEN nUJTwPVzj+VekEbmwM5rzf4f5NjqsgY4N9Icd/vtXvYJf7BiHfrBfi/8j5bHq+aY Rduf8ononzDOGBz78VGCfMwQCKeWy5JHf0ppwWPb1NeK1d6H0MWk/d7jGAIA6H8q iILDnkGpsEDcSGJPQVAWwd2P8RVxulqa1GuoyMgN9wEjPTtTWU7uQCf4eKeScgAH d2JqNmck4Y4z2oitTGMlaxGSS+7r6gimHOcZBHXjinsTvyu4ZPc8mvNta8KeM7rW J73SfH95pwkYtHayWSvCg/u9ckV1UKcKjanNR9TKrUkrWVz0NSMYwuQemajYsT0B 47dK8r2/GeycKJvBWtqFwCySQsf1xSnWPi3DAA/hHw1cPnqmpsgP6Gtnl9naNSL+ f/AIdeyXus9QbIYA/MfalA44JBB4ry8a/wDFTAP/AAg+ig55/wCJtnA/75pRrHxQ Zvn8K6FACOCdRLc/98isZZZJ/wDLyP3ijiElzWf3H5haGzC3n2nHzj86lmvIre5n R413YxuHfjoaZ4eKh7gMCenArN1dH/tqQk/6w7h9K+P9mpYmUWfYU68qeHUluaGi 3JFxKGIWNuuT0NdxGf8ARwvXIySTXn9jGJY0t44z524lmz19Pyrvk4RU68dBXFmE V7S6N6a/dRcnqyzG4AyD7VOj/vsZ25PIAz3qqOIwOcHg1NHwy7ic554rjj8LEuaM lFmvCxAEZJZccEiuS8dhV0PT8BdwnOT/AMB6V1EBViSSeCB/9euT8ckf2HadW/f8 E/7prfCN/WI9rk4uUY0ZW6nq+jt/xLbdj8x8hMYOR93muwtCAqAAkehrjdHBj0m0 RtuVjUcL1IArrLV2YA/NkHBOetaKC9o2KbR09oAkxGOD+nrXS2p2nj7x4ArlrZgH BLHbxz3FdPbNuTH908+9dSTbQr2vY1o22zAnZuK+maubyZGPUnseOKoqSJVbP0zV sHLfIFyORWkotIVNWbT7koIBGwnnPIHWn4wMDp71EJcgkgjnGT2qQHIJ+9n16YqY xltfYqyav1LIb5AEC5I609QCeQc4z6moF5UY7jnAqZCdp+YjjnNUr7sbqKyQ/cvG R+dDMuRuOMDnFMYg7ThiPf0oPLngDPAAppe9cSXUso3VV6k1ejLByc4J6D0qhGGM mSOMdTWhHnADAFu/tW8G1G9iasLo1bdgV+Y5PfHeuQ1N3t/jDoky42SpsY475Irq YWODu3Ahutcl4szHrfh+6RWyLjaSBnPQ/wBDXvZK71+V/ajJfgfM5/LlwkZr7M4v 8UepRMQ2G6duelX4TlueB1rMiAIyMoR2NX4Th+D06n2rx7W2Z78LuzLqZ3BcjOOc VaQYbr8ueecVVhkBX/GrGfx9O1C3Zet7kucN7etOT51dXQDIwMjOaYrHeOw+lKG+ RQSCAK2hG0jOWsdD5yeKHTf2tUVkTym1AFQy5GHXj9TXr/xEhWf4O6xHgKUjV8Y7 q4NeT/E2BtK+Kul60iAK0aSZ9WjfJH5YrS8aeNzdazqfhxIdti9pGYpQ2Sz5SQ54 6bePwr9Tnh8Rja2X4mlraMb/APbrV/zPx6ONoYDDZhhqml5SSX+KLt+CMjQfCtpq vhHVWnkCXMUGy0Bb70pGfz4x+NT/AA/8WN4e8F+I47lTKkSrNbIzYzIx27fpkg/g a5xfDmra1qct1pTM4sJQwQPghjg5A9eOtdQvgTWB4EuZYrfN48yslvnkovX8cn9K 93GVsJKM6WLqp80o6Ppt+a/U+Wymnj4RpVcJQalGMryXW9/xu/w8iDwz4L1PxxfT eJNfvJktZJTtx96YjuPRB0H0r1LxLOfBPwlWLTI1CqRCGI5Tdn5vrXkOjfFDWPD8 i6Nd2ME0NliIxFdjoF4x9a7DxV420fxN8HbpLdzFdvJGpt2X5kOc5+mAea8rH5fm dXMaLrRUqPMrJbJefyPfweYZVRyut7OTjXcXdvdvyfm/mcpo/gvxD4v0WLVP7Wjk gkdtpnkZmXaSDkVzvirw+PCOqWthLfx399NH5pijhKiJOQGJ9zn8q7Lwr8QLLwz8 Ok077LLc3qyyPlmCJ8xyOf8A61cZrfiHWdc1R/7ajtrGV2Uu6wEOIxkopzzgbmIH vX0OAeaPHzVWypK9lpdq+jtufM42OTrL4eyu6rSu9bJ21X59zZ8KHxHPdxnRptUY RkeZ5UhMa56jB46V9Uab9qXRbf7YwludmJGAxk+tcj4Gu/DDeDba28O3UEqRKBIC cSFu5Ydck12bvtf1bHABr844qzWpi8Q4ypcnK+2vzP0zg7JYYGhzxrc7kls7xXoX 9xzu4UdgD1ppb5mPr0WqwfA6YanrJmQHPGelfKxTe59i07alrLAdQBnAyahOxSvQ D2phL42k7jUbbSmev41XZoztpcslxsxjd3JzULMAmAoNRq/yNjlTxTy2VxzwO9Ul qTGberGk4RselebfDgg6Fe4AX98SOOPvN0r0WVh9nbgcjHNec/DhceGJ2AxGSCD3 6tXuYVf8J2Iv3h/7cfKZg285wlv5Z/8Atp6QWB3bj9fembjhgCRng80E/IQOCfam b+PmJUDk88GvHS0PqIyt0Bs9sdajxmM5Ckg8807cq5DPgds9TULMq5UL82acdWS7 LcVmwegKsaaD+5OAd2ePl6UAqQA4yT6DinHpu+6wPTHekk0rCcnuyHa4THOeCB70 zJPcA9jmpXYkYcn8RioSQFA/iz17fSi99kJu+w08Ln5dpHPvUWRgA4Vj609lzGeM fjxUZHyH19M9KbSdmLfQjLYbG4AnvnmonIZShPPXkVLxnpls81XdcyjLOB3OM1i7 MX2dj8edCYrPcY9OP1pbqeA60xuELiNOOev+c1HohHnyg5x3qjqbBtamK54bB/Di vB9mpYiXofRqo4YeL0NnQ2VtZZ4xgMp49BXXAYY4wMdyK4/QysdzHu6yDA56V1iv 8pHAUep6V5uOX712O+nD3Yyk9y2GLN/d5xjFTKckOAR61WDttXnOT2HFOR3DgMCc juOtckVdoUppu7NeDhFcYx3571zXjgp/YViM/MJ+eP8AZNdDbEbFOVGe3euW8bM/ 9iWKsMEzEkH6f/XrbCJvEQfRM58TdUW0eqaO+7TrV8BR5asAO3ArsLbOcYC47Vxe jnGl23X/AFS9+egzXY2TAYHzY7471td82p1OmkkjpoPlCMTgEZwDxXSWh/1fJBYc j0rmIXHylgDj36V0VnhgoAZRnr6it435bsyclzbm0GBwmc1byy4OQcDjiqg+XGSR zziphuGCM5I45re+nqZ1E7ssqeMhVA/u5605SRDzjPcDtVcZMJBXLDqe4FKo3EfM QTxSaW4lJ8uhoRkbeNg44NWQBtAJ/CqERIIU7wvQcccVdTJAGDj2p8zubc3kSMAs WRk7e4qHd1xz6ccipwcvz93pioHVc4IYKRVRvJiTe5aXa23AGTxz0q/Gy7WIwWrM hBI5wVJHGOTWjD93cc/5Faxb2MpTdjQhXcvIC4OePSue8Y3MdpoFretGsjx3A2eg JHU1vpkx9AR2zXJ+Pv8Akn7Hc24TIenFe7kMVLHUo9G7ffofO8RSkssrSW6Vz0iw nN1p9vKcAPGrfmK01KjG089DxXN+HZDJ4L0xxyhtY24/3RXQKTtP8IJrzsRFKbiu jPXwsm6EW+qLq9M7hgdM1bRgIiflBxzWcuVAK9u2M1YWTdksePSoimaptOxbUgDH fv2xShgMl/ugEmq4IPy42+460DaYW3Ekdwa1i03dvQxmmk0eQ/EbUtG13wlBJZXc Et3Z3PyruG7DDDcfgD+FeeeG9LuvEXxAsoWQtHFbnznGcIix7Bn3ztFevX3w60i6 u/PjM1vn5mUc96XwJ4b1LQtV1o3kcSQTlBA68swUv+nINfpWHzzBYXKpUsPN8y2v /eetj8lr8PZhi85hVxcUoPdx2dlpf12NLwbo93puo3ss8RhimhQMPV1/+tXogBEQ CnDAdQajGBJgDOTzmjdwMgYHUCvhsZjJYqtKpLf/ACR+j5dl9LCYdUYPRX/O588e GYdKsfij4ti8RLC1veSyRF5lGARIWB/HNcjrOlW1t48m0/RJjqcJcGBYfnJB5K8e lfR2oeENJ1TUmuZYWSZwN7IR831q5pXhPRNFk+0WVmiXOMeaeT+dfeUuL6NGUq0U 3KSS5fs3Wlz84q8FYyvBUKjioRk2pfas+h4n4AvfBlrLKNdghj1WOUtFPPllwMYG Oikc1zGt3Wn6n8X7ya4v1/sy5vh5lwp/5ZZ5Iz6D2r3zVvhx4b1bVDeS209vO7Zl aCTYGPuKnPw58INpkdq2kxbY+BIWIc+5PU1rR4ry6FeWItLmmrNdF6GVXhDM50YY ZuHLB3T1vL1PFbjwja2+sQSeFfFemXkzk/Z4lu1iuC3ZRjqfyrXj8RfETwwwTUku pYl43XUG9cD0cf1New6J4B8MaHqEd5Z6YjXcbExzzMZHXI7E9K62VQYXG0sp6g9D XFX4wpyl7OVNVYf3kr/gd+G4Lqxh7RVXSn/dba/HX8Tyjwz8SpNb8VQ6Vc6PLFM5 wLiF9yDjOSDyP1r1tJDuAOM1j2+lWFtqL3dvaW0Fy6hHdIwpYDkA4rSBbJBYADp7 18rmWIw1atzUKfIu1769T7DKsHiqFDlxFXnlfe1i2xOzqOTxUW7bF0B5zzTgwbHH 41Xwcksdx9AOa4YWZ3T0Y8yKAFznJyPWpV+YHkkVVABl/vEDIJ9PSpA2xeu76DtW l1Yya0ux8mFiYkDbjOc815z8NmX/AIRKZh90lcfm1eiTti2c7gMLjPSvG/hnrMD+ bpMiMJRErh+zcnPHbp+te9l9KU8sxDirpOD+6/8AmfLZrVhSznCcz3U19/Key7z5 zHpjrxUDSHIIHGepoDAF1+Zt3T3FMYgpkA5B7V4e7sfSSqPfuAkGCxwcHOevHvTc qVH3QOoFMwm0ZPB6Uw4UfKST0z60pXa8yp3SuTggYzgDHrS+YuzkZJ7HtVUOxP3R 6cUhdyACwBHvTsm7MyjK3vMm3Db1zjnnimHBTB2n3FMBycnnGO1M3YJA6dsUctxq SWw7aQATgio2OCDxjHJzSlvnAI2+gzUZYEkZx9e1JpLSwSbS0Y3J2FnAVvWombae q5Ax9Kk6ngqVzgelRP8Acxkbm9qwqRvFWDmtHQ/HLSCBdS5OPlpZrUS3sm91Dtlg T3qLSQp1Fg2SNvSl1V8X+1Rt+UV4rTddpH0lNxWH5pK9ixobhtVEbH5VUkHGa7KN wUIPKkcg1xWkkWyNdSAkNlEH8z/KuuV2MSMQoGBla87HxTqaG+HU3SUm/IvZ/d/J tz3GKkBXf8/XrnFQLIgORkAk9KlQ5Iz1HJFcEY2ep0817GlCwRAcDIIrmfGrFtNs Tg7WlJzjpx0ro0JAywOM8YPeuY8ZHOl2HJ/1h4PbiujB3+sROfGWVN/I9U0ja2m2 pPOY1Oc9OK62yJJUEZzjpXGaSV+wwMMj5F4z2xXY2hIbgkgcdK25vfsdN/3af9dD pbYgIRyWz0zXSWDAoMlSQOMGuctsHABII9RW7ZkAD1IAGK2pe9uczVndG5uXAIwQ Tz7VaBBPIz9RVcY8vlcZ5J9alXAJOTyOma2ltuPVuxMCQhA2kkc+9OQ7pRkAgHpi o8japUADd9eKQZLfzpxV1oQm9EjQRwEBbAx7datgk9OSDkAmsyN+D9/A6AcHNXkY Byg3HaDmiUbBTcmrF0MWGG6dTmmMNp4A9sc1GHUYOG471KTklhkKOR8venFJLXYr rox4XoTjHue9XY2GAwADHGapKQrHJPvkcVoRqwGMnBHINa076Nmcnd6FyMZ2nGBm uQ+IJI+HEpAC5mTk/WuygyxJHB9qoa3pMeteG57GVmUtjBxnBFexldeNHF06ktk0 eRnOFliMDVpw3lGxY8Ivn4daIQ2T9jjHHGcDFdcjBo92cAdPrXJ+HrD+yPCtjYCR pjDGAxJ79a6aEEjJB2jis8ZyTxEnHZt2OjBc8MPCMlqkvvLoJaMnK571YBBhBwQ3 Qmqqg7c8nP61Iobphge9YqNzb21ltctFh8u3BfvzUi7S5LBDuHOKgSNi2DnOelWl QZUclc4FPls/IzlJgu3OflGe9P8AMijUbmVcHFYXiLWbXw74ae/n+d9wWGPP32Oc D6VxmkWPiDxRbC+1K6/s60l+aJFXJYeoHHHvXsYbLOaiq9SXLHb19DwcXnXJiPqt KPPO13bZLzfQ9SSWCYDYysD6Gp9pwQCuccmuS0Pw7c6VrEkk2oNdW/8AAoTHPvXV SSxxRl5CAq8kk9q569GlGpyU5XXc7MLiq8qXPWhyvXS/Ym2SIOhyfQVI4BQBsZI4 5zXC6n4+0fTTl5WkQthDHyWPoPWuusNSN3pNvd+S8azxBxGwwygjPNVXy/EUIxlO Nk9jPD5xhsRUnClNStv5F2M4TG5iep5qZBuQYXnb0PQ1CJYdv8W7vzzUqvEyqQwy V7/4Vzum7nUqiEJAkyxA5wOaBJgkblIxyfWpSkbSL8wHsD0pjQNwA+R2x3pKC6MT l1GYjY5XAPpjmkO4khecn0ppgkQghjnvg0u5wFDA4APGOtFtAUo7MQOVQjOATx9a C7DADZyP4qcCrMc7VUd6j+QplgQAefetVHUiTjGL1DzAM5wT2x1/Ol83EZBGGUDH PWk2DB4dQeQcfpUohR0UAydBz6U1Gy1M4y5k7le5k/4l0xzn5CcA+1fN/wAObh0+ J1mrN/r4HUk/7uRX0tNYpLZvCZG+ddpIHqK+dbXTY/Dv7RFjpsM0kkEM4jVpOpDR j07819nw1OEsFjKHVxv9yf6tHwPFsJxzDBVvsqVvm2n+SZ9CZ5wMVGTg4wOPSmFs scnOT3NR7znpwO+P6V8fa+x9tq3YeW24G4DBPSozIqsuQuSO9MkckKMZAPamkgqR kjI4AFX01QlJvqTeZzwFOPXjilzgHvz3qA5K8AggZHPWnc5XOV65IFJJLcJSvK/U cWxnAGevPpRjDbm4JGOOtRu2F45+vQ00tyec+h9qbegnK6sSblJ5XcccY71Flcbs NjHy+tGSVBz1xgioi43ZO9R25/Ws2lrcvk927RIArAAknuKaXO8ltpx61EW+YnPC 88im7i3LAlTyKiXkF0o8qPx00ohdSJ3bcqRmp9SgaTUAwxt2gfLVTTiRqYx6Grk7 ldW8skDJ4Oa8Kd1Wuux9LhlCVC0u4aeollSBzgAnArsEG4BMbicHPeuLs2J1kQxj dliODXX87wvQ459q8/HJ8yOqnNOKXTYsjKrncMA9u2amVx5qAHPHTv8ASqny7MAj BFSoxX5ccA8571wo1S5WtDVRiY1G1hz0Ncx4wYnT7JW+Y+YTnPTiukhIWEKxOCeo rnPF7BtOsQQOJGxj0xWmC/3mJy45Xpt+h6XpDMNOtUBX/VL8zH2FdnYk+ZkY9Rmu J0sFtNtc7ifKUgH1xXX2hO4DGTnnBqpRd3Y6JK9rL+rHXWrfMBjJPcCty2+Vtjdz +Nc/aPztGMdQa34CflIPPA55rthFpWMZtNXW5ut8tsfmb2wKsK48oMOOMc1UQsYs OML1IA6VLA24dTkDnHrWmlgWsmWgw5wAT1696SNvmfnPPOe1MQ8fMSD3NNDESNlR jHGDV07t2a0Fd2v2L0bAEkEfjVuNgxzuyCcHmqCqMgk9uTVlAuAvJA5yRVJpXQot 3LoYkDbjBGRxUgZvmAPJH5VBHuxuORznHpU24bsLzntSS7hJrmuWkBIYtzjqPX2r RjQD5sdsdelZ0BG4cEk9MCtGIFd2Cdp6Z7VrTi7WZLl722xbhXgk4z09qtoreWuW Ax6VWRgAGDFsk9qmkcCxeTphSee3FbRu9DCpKKi2zJ8PXsl7d66zkERX+yMegCLx +ea7SH5Yxng56eteZfD6Z7jQ9YnbrJqkmCDnstekRAghh1PH8q9XNaKp4ucLbf5H j5NVdTBQm+uv4lxJPm2gYII5JxVhSxPYA9aqA5zk8jqKcCdgyT7k1wpaHqaJLqX+ cDDdD2NSK24ZLYHYniqyuFVVwSOuMVYG1mBA98A8ihprVClCN73OB8f6Bda1otpJ YlnmtpC3l4+9kDNc7YePL3SoY7TV7KSF4k28IQBjjpXp+r6nDpXh2+1GdWeO3iZy ijkkA4Fcr4TvoPF3gd7nWILKWea4kzFgEooOFHPPQV9dgMTN5f8AvqXPTg7Lum9T 4bMsAv7Tbw1ZwqyjdrdNLRXOj0vxVo+pxxrHcRiYjO1jgmuH+JXiQWsdvokL5Nwp e6IP/LPoF/Hn8ql13wAtvD9s8OySQSqM+QeQ30OeDXj97eXM3iy1u71/OmjZAVk5 4U9D6172QZPgq2I+s0XdRv7r6PofN8T53mFGg8HiY8rlb3ls11+fc9s8JeCILSxt tV1hFutVdQ4jkGVtx2UD1H86d8RNfvNI0W0tdPuPsks7sTIoGQq44H1J/Q13Wm6j b6jpcV1bOsiOuePWvJ/i5aSyDRZQvyK7xtnoM4I/kfyry8mq1MXnMFiu70fo7I9n PcPSwOQSWDdlpqt91d3MtYPiNb6ZDqKS3M6NGJB5UgdgCMjK/j+la3h74p+XqaaX 4pjWydjtS6I2Ln/aU9Pr/KvSvDN4LvwbYlnUTCMI/PPHGavXGiaTfTCW906wuZFP 35YA2PzFaYvOaU1OjiqCurpNaNE5fw/VpqnXweJdmk2parU2EkQxiTcGzjp396nw wiyh/HPWqqjJHXk8ip0LNhT296+OhofbRjoSq0x9Bz69KXdiRd4U9s+lR4DrxuyC MZ/pTEJMrAn1/wA4rTTUlR1SLZhjkQHCDnn3pTBDjjGcdAaoJlWKg4PQ96UruJ3F 8D1NDumQkmnpqXGgB2/Pz3PrSrGykgPwB37ms5xtcEk7uQP0pBI3P7xh71VtLDjH S5qlgEY8E45wa+a/F9wv/C/LO8UOiie3bP8AeAcAn8QK9+aRihRjkYwQTnivAviR bR23jXRWhAQGHap9MSf/AGVfU8IuKxU4/wA0ZL9T4vjeM5YSnNLSM0/0/U9xK/OB nKg9x1qNz1G7kZzjvT1yRnBwBwM1XdsP0ODXy6Suro+vfKnoNP3McZ+lRliR1AIN PLYBGSwPeo2J2nJySeBmhszlFJFiJiSSSFweSRxVjnAbj0OKqROfLHIAHJBNTAnA bKbcdKNVa4RloKRknuPSojllBAITH5UrMTGVwBjvzzVdm4Izuz2xTa2L5bbMdlsY 9Oh9KacBj1HsR0oPBJBwPQ8iouTjKnOetRJsbi3KwEEsRjAx6UZwvAP1FNK5yCce tRtx3IGPWpm3azM2rao/HrTyBq0YPQ5zUmpAC9Mi9G4P5VBZYGpIScc1d1BN1yiZ GCuRXizdqy9D6GjHmw7XUh0yRYtSMj8EIdv1rp7aczQhmwOvSuWMWyRQDXUWjLHE IRn5VySa4sYk/eO3DwdOm4svrjaCWIH931qQMvnNjHuD1qsWX7pAbr35FWEfkkc5 9e1eY0zod3qakbdNvI/Ouc8W7jptjzld5yM9Djit2LOC2GHPQntXN+KWZodPVmO0 sxxj/dqsBG2IicmJX7t33PTNIAGn220nIiUfXgc12Nk4LD/2WuM00lYYAMZCgZI9 q7GzGUAOdoPUDmtPtas6pK0EdZblPlO4hs9z2rftG/e5DAcda5y1Y5Xco4PArobY 7j2+ma7KWqRjyq9zcRiZS2VJB6/hUqsAdvQk8j06VXjOVOQVzxT8gzb2wTj16fSt 01fyJcZPUuAbiQ3Jx2qMN++IVfl7YpgcYyeOxB60hYAjA5zg88VcexnOTT0ZfTkD 1x0q0hAGWHzZAHtVGJl7HAxuAFWA+4DBxntiiUN+w42tfdl+NxtwGVsntUquoJGR ketVoSBjkqe+elSHhuOfUUJL4SrtpPsaETBSDyMVoxtnPTA71kxEdM8dSK04SAg2 nj0NbpaIybVmjQRiMZbvnNLcuU0e6IAbbGxHvxUaFdg4OfTNTSRia3khIwHUqQfQ 1vRl7yfmcldN02m9Wv0OH+FFyj+EL2MFTKt4WYZ7EDmvVkwJV4xjk4NeAWd3c+Bf Gl5DMjNp875BVeh5r2HTPEGm6jbo8M8bNnP3hX02f4Kcq7xNNXjKz0+R8zw5j6cM NHDVHacNGnps9DqVI+YDBAOOlHAwBgcZ6VVF1b7golUA8nBp/nRsmQy4x614Hs52 1R9HKsnsy+rHYSTzUpIyO3rVNJlYD5lGegzUgYGTGcjHQ0csrXJc73cWJeWkWoad c2dwu+3mQq4PcEV4ZqfgbxH4e1SW78N3s00XXERIbHuO9e9Bjvxn34pGb99k8+/r XtZVnNfAtqGsXunszws4yTD49JzupLZrc8AXxB8R/L+zrb3hkHGRB83T6VseG/h1 fanHeXviVmtZJotsEStllYnO8+n0r2UzRRWzySbUXpnHOauQSK7I6sCWPWvVr8WV ZJ08PCNNve2/keRhuDaXMquInKotUubY8EMfi3wFfvJFE93pgbiRclGHuOxo8T+P tM8ReAXs5LeWG/V1kjJwVBB57+hNfQMkavE6siyIRypGc/hXNXHgzw1eS+dPo9m0 nchMfyrsw/EWFnUhVxNK84veP6nn4nhTFUqc6OErWpy3jLVfJnz/AOGV8T6jFcSe Hrhnlt8NJB520kHPQH6V6Bo2vfEyDV0guvDs2oWgIEzSgIwH+y3ANWPB3gnVvDfx Yvrtdo0gxyJE+7lwSpUEe2K9i3/Mctzj17V0Z9xBTnWlCnCM4tKztqrr80c/DfDk 6VONSU505Ju6vo/l/wAOOjld7VJGXynYAtHn7pI5Bq3HHmLO7FVgcgHIz6mp/N/d bRuA/iOa+EWqP0G3LothWODhegGck0gO0BhgfWolbDfePXrUmccAHaCeD3p7smMd LsAm9B8oGBSSBgCOOh70gDl/lBOe4FMkVl3ZB4HUVpFomULLUdwqDOQc5yaZ5iD5 srjuMUwvnpj8ecUxgrBc5A6YFO5C00ZKWRuS2CR0I5NeKfE//kafDwQguyyDAPP3 k/xr2baQnyL07+teNfERZJ/iDoKLDLLGi/OQpwMyDr+VfQcLySx3N2UvyPluME/7 Pa31j+aPXwWWINuHTqeucVBIcruyV46nvTuNq88/lmoWLDCr16Yr5+e59HHXYjJA h6jJPTNRnhlzk5p+U34JPuMdaaxO7HQgZpJrmuEtVZEiY37W61J0UlRjjmoVYAN6 HpzShs/eXn69acnbcuNrKwBySPXtzSbtueeOpHrUW4b2ADA7sg1E8uOu4e9Jpu1x OSS3Ji5wQOnc1ExwygkHvn0oWQnJAY9QQetMD8lC27Peh/y9RJt6ikHcApA9cVHk qnVWPWhiGlHzMCOCfWmsx8ohFGc9R6VlU0RSa1Px8tiBfpnpu5rQ1IbblZFxggdK zYcfa1yMjdzW1qKq1vk53lRj0NeNVdqsT38NFuhIyxL5uoKecZ7GultyChkTJOcY IziuWjUod9dTY4Fju65GTiufGJJKx04WUpRfNu3cuRsGjU99x5Pap1ZCmMjB6AVA HVULFSoJ9aVSwkO4ZIPFeZJHVG8VG5qxbSpUlscHFc94okDSaeMg/fP/AKD/AIVs xSgRAdOeh7VheI9zatYJklcEgH3I/wAK0wK/2hX8/wAjkxNROlb0PTrFhhVyvBx1 rrrEjeCfvnknHSuKsHYSEbQwz1rr7FvmyzEEnoO9YwT0OqUr2OttiAApABHcV0Fv gbQM/QcVz1rkwqRuznjNbsO3CnknHeu+gnY56sehuox553KT29KlYpjkszAYH0qv Gw+UKCM44PSrByx5AUYxxXRC7MoaXHg8gthl/n1pzACNWBwR19KgBUIRgZ6AGpg5 MLFmPXFaqCewlaTt1sXoX+VRnkcYNWoz8xyQoz3rMhclxnuKvo2CWK9qHFXsaQld XLiA7wc4alO1pmyD9ajBXCnr7ZpTIAp56nOPSlZXuyqrsaEaDaAxAI6HFaUTfu8h N3PUHrWREdysctj88mrysAnHOcHgda2il3Mp6XsjZizt2nAO7gVaDNnJ4IGKoxMN gc/KfSratiVSSR7iuiJjuhl7pNhqdo0d1DHKGGASOVz3FebX3w8vbW6abRbuVCWy EVv6V6vG/wA+1Q2QO4wKsoxD8J27V6eBzXE4R2g9Oz2PFx2S4TGq9WGq6rR/eeYW /hfxJ5K+dqMu/ADdOta0fhzxBDGAt+x46lq9ADENkA8fpTlPy52kDoDXa8+rz6L7 jjjw1g4y0vf1Zwy6d4nhTCz+Z0xk9anjk8UW5w0O4Z5IBPT8ea7cnI4XLZ6DvU6g 5Bx+FQs2k1aUIv5DlkEab9ypJfM4w+ItVhc/adPlUZwBgjP6VYXxbEWCPbSoT1O3 NdcAr53KM/oahksbSWMiSCJievyitfreFk7SpfcQ8vxsf4df70YT67p11aNH5ioc AjeOhzW7p2oWH2VYEuYmKrjBIz/nrXNXmjWLXKeXalQRk7e5zjFI3hGIZEF1MpJz 83IFZRp5dVqSlFuL0RUp5zh6UItRnF3dlozv454/LGHVvfNShi/QgfWvMv8AhHda toitreRuB0BYpTxH4qtkP7qSbHdJQf5iulZbRnfkqr56HA85xMNKmHl8tT1AbiQB gZ7HtSNgnoCPb1ry9tb8SwSAS2eoBexNvu4z6g1C/jTV4A6z2uVAyd8DgirjkdaX wtP5ifFGFivejJfI9XDZUALkYycGnK24NgBhivJR8RbpVbzbK2IHIzIy/wDstOX4 lIsIaWxtVUjqLo+vX7tX/q7i29I/iZR4uy57ya+TPWlJwcHntikJbcCM4/PNeVf8 LJClQNPt2+l2Pw7VC3xSQ5YabbluQQt6OP8Ax2inw3jpXaj+JEuLssirOo/uZ62J JEwV4fGABzxUUkkkm4HA9cCvObH4hRXRzLbWtuAOgud34dBWtaeLLWSwkuL021qA xCYl3ZHrWVbJcVTunHVHXT4jwVbWEtDrN2OecAcnPFOSRd47nPbvXmGp/EnTbdlW zS3u2OdwefZj26GuWm+Keq7mMNto6sxwBuds/qK6cPwzjakb2SXmzzcRxnllOfLz OXoj3vcNpP3iD61w+sXX23xiuloQiRmN5pSuR1J2Aj+I8fhVHw/4yXVUWC4tp4py g23McZKbu/HUAH1rqbPTI7cRlnM9yoyZG+8xPUn3rkdF4OpL2m/T/M74YmGY04+w +G+vy6al44JOeOBndTOCc5BcZ49BUjhssWywPORUQk24AyMdB7V5Tlr6nsON2MPD Lgc/SoiQTk+nWp9wCdOM9qgcbSTk/T1q5b2QnJiIT5gyN6MO3alOUc8d/pim8+YN m7HpimMWLHqM98fpRpa5LtrYazD58gduvpULPlQAvHYHkU47Wyfmz0ANRbjtKhc5 569KrcJWl6C56gPg5/8A10j/AHQAMEfkKABsI9D+BphI+UgMB6HtWdrtjg7aXHlQ GxgE/XrTPlII49iTSM/yEnO7HXPFMBPlZ5B9aycncv2aWyPyCQ4uFI9a27h8rGrc LgBc/wD66wl/1wx61pXjF40cE7QO/XNeRVjeaPcws3GDaEUh7s2+0E9B9a27ZCtk oYD5Rzgda5u1OLsSE4PUfWuigbdao7sS2ecdhXNio20OuhJzjzsu7jt2kgg8j/8A XTi+4HB4x8xxVdHAUDJ5+7UiEqRnIAPPvXA4m0m9F3NOE4A6KM9+h9q53WcN4psV AG0qvI75Y1uxNluAynOBmsLUyzeL9PB5bCYBH+0arBr99fyZhircit3PSLJumCfU cdK6yydsAggknnHeuNs8hwxBwPSuvsyglHB49ua5YLXY62lJK+52VoRsUjhSa3rZ 1bapznB59a5i1bKkjdj1xXQWhBBByo61302rHNOTU0dBC2CRtIIOMZqfJMnQfN15 61RjJVH5IIPH/wBerKuME9RjrXbFu1jDnbdmStuU7lAIzxjvT/MBBwFBI4z0qMHf x97vkDrTCQoAO7rjPetF73QJy5b67mlCAAOAOM5FXUI2ZyCc+lZ6SMqhudoHeraM Noycr2GMYo5bq5vRaTsWwSVGBx6VKMCLdhW4qoC/nDnj+6e9S89OSQe9VvuTKN3e xfhH7xWyeTzitNCpATIIz1NY8e4NjJxkgc9K0Y3ww+8CeuRWq2stUZubfQ14TiMA FAM8qPWraHKYAByc9OlZsEnzElGAPoMiryNlflwe3J61sk07HO02tC5Fjzz2U+nW risuecntwKoRsBL90jHc8VdVgWzjb7VSbvqEdtCxk7TkfSng7QAAc9c55qMn+IZ4 6HHSnEngknOOwxVRWmpnPS6TJl49c9fWpiWJUqQFHU56/SoV3EKCTjNODDJy2Oc4 qoxs9SJaxJ1JVtjEnGSaduYKGIXn7xPaolZ3kY5UemamJ/dEZL9ue5rW2uhDd9ho miSZN7IGdsLj1q5u/hx+Xes6W2jdoppid6NlcnpzVwMN3zDIHSphGWqaCpKCjG2j 6k+csem/+VSRMS3YDruPaoV4GR07gVIshy+CwBHTtWq8jCSUbNss4TcCcEEk89qc wjLbTGg44471XBwAVJJzUm/EWSowp6HtVwbSRlJR2GvaWkkzM0MLNjncgNRnTdMd jvsrRmPrEKfu3uCPlxStJtQ8lTgjjvWkatVOybMVRpN35Vb0KraVpO8btPsm7HMC 8D8qF0jSdrKum2WM/wDPAY/lUglYLgA7e5qRJvUE5zkcVftquvvMmOGo83wL7iNb DTY2GzTrJDzjbCo/pTzZae0ePsNscDgGIVJlGIUjBJ60/wCVkKhmxj6/pUe2nvzf iaLDwvrFFRtOsDtK2dgec8wrnP1xThYWqhcWdqhByCIwP6VKSeDkEZ4HpT0YYLHI Ocda0eIm+rJVClrZIYVVIwVRFHcAY/WpFKYAGAB1OOabIcsDg7D696iIBfqfb1rn lJsuMFpyossoKFG4x0FUXH7zPy4zzVgtgkBnB474qKRgY+AxNKSuxNe9Yqlj8xLY +n9KTcWXLD9eKU/MSrEqM8VCwUSBF/EEfrTitLGdV21JCQrscKB0yTTCfl+Vgcci o2fMuMEEdxz/AJFBVw3QhsYz+NOMX1HKas10GFgshAAZSM9MZprYVzkLtz0qQ+WE Hytnt71Exj8v0ajYJNJXRG+0EDaOnSmsQAOMk9T6U90Bi3AE9uRUe35DwcY5/wAa zVmrsvlVhgYb2AA9frTsk253EDHWmeuG3LjigfdI5wenvSm+qFeXKfkIP9YPrV+4 OYygHYVQH+sH1q5LIFIK8jjNeRO90e1h5RUJXZFGPLn2kbiR0rat/ntkyAccDnms WIl79W5xnmtmMKuPLPUZz6GufEdDakk4Ptcv5BYcAYHAI6U8HaWK9Oo96gXcIs8K R1+tORgJCVyOa4Gjqu3ZGnEMCME5wM4xWFfEnxxaY6ho84+ua2IHyAGABA6g9Kxb j9549Tp99Ov0BzTwq9+XoyMQouMbb3R6HaHEqgnjHAFdVaMysEJ4PoK5W0bDLzkn 9a6e0ckgAKOpwRXJT5mkb1Ipx3szs7NgUUlQcj04NbsHEeSBjPXPSubsh8hxJuIG ODwK6G2PKpgjHUk8e1dtK97sxqvRam5Ew8tgSOmQAKnEgZ1AOfU1UiUlM4LcYPFO JZc8kr6V2xTasjm5WkXg/BIIAPvSYXcGONozu4qqJMqpI5HQjvipRJ0UEZ9a1p2T skVWTabNEHKnn2qxHwgBI6457d6pZPQNk44IFW4iPL2uxwBmqb5RJt+RbZmwuRtP Uc8mnqy4Xociqp4kJRh93PPOBQMgkggArg4H+e2aW9rjlKV9jYjYDClcqScVfiZS NoUAdz3rGifeisuNx75/StGJyZuWwQO47Voko6FSldWZrwnCkcnPcdqvqcKVLfMD 6c1lxMpZcdPfpV9CyyDIG3Hbnn611RSdtTmirJNs0BJnaevuatxMu/rxjj3rPQhi Acbh1z61djPycfqvSnpGyM1Nt3LackBTx9OBT1YEBcZwKiQ4hQEgDr1qUFSM8AVa VzJ6LcmDsYuCo555pCc+vHHApBj7P046gUzO48cD1pqKRMuxcVslWOOD61L5iIC2 75ieM+1VORgg5APTHWnniTjaR147Voo3kJssuwIDBQwbgGnqysoZiBkc5qqzHaNu 3avtjNW0O0AZYZ/HFaWbWxlJ3foPR2zheEHJJqWM/MfcdO1MGPmy2CeMU9cADJyf SrjKyBra7JlwVAXLAnmgkYPygDPGe1NDMIwF7Dg0052DJ6nv0os+5EmraoGfMgCg 4I4ApznEe0qMjoKjUEOoCkZ6VI+SqqQQPeoTdtCFvqV8sflyCexWnhJAvQHvzT0X EgXkZ7Gp97GQ7s7cdOgrSKuh311GgAJwMnsRTAdzbcAH9KkLAQHaM4pmUAU9GOOA OtVb3iOZ7tCjeqsFO7NKZGKjcM4FRSsEl+UlRjim7iJBg5J6+1Ky0YczUWi05Vo8 HkjuaYxXZhcDHU0jOTHk7Rn0FQkt5ZC8nHHNJR7MmXdDySr5G36jtTGbcN3XI5pq biDnOT97uKYXVZD82zjFFmE207i7VbDkgD1qFjHuJxtwMVOx3JuyWO7moXVVA2qz HPJ6UcttBT96NyFk2uQMfM2eB0pwzs5zyDyaVQfMwSSw56VNtO3BBzRJroSk0ipJ 5ZGcDI4waadrQdV9Pc1LIozhiozycjFRYxHjILMeAama0E7rcYWyCSM9v0pSv7tR kAd/emHO7IAAx3qIN0wcE+lKMWXLa248oc8FST60xVIQg7WA7jpQTuYjO7PvzUZd lTqc57iod7Dik2tT8hf4quSjNsfaqf8AF+NWckQnIyAea8ma1R7FBpKSY2AMJQQO DxWxHjykCgZA65rKaXZtCYwOTVu3cKzOAWYLWFVOWp2UOWK5U/U0QWKdlBBOMVIC Msct1xzVZGV4gBnaTnB7VOu4ZywXHCrjNcUlYtrRO12X4TuK4z78c1kY/wCK8XAH DjH4L/8AWrVhYsoYHj2FY8PzeOF3YOG7/wC7So7zfkyKqV4rzO/tHAJO7ODnr0rq bNvm3EcEc9jXKWxBOeCvp7101pndGO/evOW6sbV+VJM7OzMZ2YB49+RXRQHcvIwc ciuZssEKcnPcCuhtTvTG45rsptLUmq1bTbU34seUe4xyM1MxUphc7TzUEROMcA85 qfqu7LEg4PpXcrSd7mMeqQwOiuCCTzyDxinKxDAEqSB1NMZMq2QAOuaYhOMEnPvW yV3Yz55xSSNVH3IC208/nU0ZLYJAz7VQSTpjPtz1q3G+4jbt3d8CqktWmF9lct+Y PNGVIBPPHX8qcu7Hy4APHFVdxDkYPXk5qbPGRgDsaNrK44zk5tMvxbQp5VgTyvpW mijB3KTngVkwuGUg4zkkd60I2JbA5NawbtqW3Fpuxqw8KcYUg8VoxyDytm0Bsckt 1rLhbaQCRgj171oRsAdwwOwxXZF6HKmlsaS7Q2ASOfyq3ExzgYz6nv3qnGeQcZ3H kDoatLhWyQv+FQlpqEXa7fUu5UIGAwv5j86kUBj0BGfXpUScHIcZPXjipQ+UO1sk +9aJ32MWknckIGQoYA9/Uin7QHAwD7VBv2qdxAx1J4qnNqVvHcoiyI7H73zj5aHL oS9dkaq/KpGTk8jnin5xK5AyD3xWJLr+lwApLeW6yAjKlgDVe78W6DaRMZ9Ttlx6 yDmtYJycRTUrOx0uQTuAK56L61MHCRjAxkYBPSvKdf8Aix4M8O6VczXOqwyTRRFk t4nBeQ44UDueRUGkfGbwRqHh+K+bWbS3Z48mGVwHX2x1zWtpWukYans6kGEZwTnA xUgALk5x7mvnvUv2hvAWnHzYb2a8kBQeXBGWOG9z6DrVeX9o/wACJpiSpcXkkjDP lLAdw9unv+lNRlezG7OJ9HbsY2r7UvBjJOAQOlfFfiP9qR1vYV8NaP5ibn8+S7ba SONu3H45z7VkJ+1Rriyq0nh6zZD95ROcj6cUnZK66Ba+590q2cZPToc00E7TuAOO lfO3gz49eHvE0aRXSTafeDAeN+R7c17fYaxZX1t5kFwsgbspziqTWyM3Tbkmzd3/ ALwHk46c05S28ggDtwarJIGQYIapVK8E5FUmloLXVsk6YC9Ce3anPlscduD60A8q R95jxTd7ZCg8D9KNdCXo9BHXdIWOQ3pUZT97gAEAdxVg8RocgentSMSG44YDk1V1 1Id+a3YiyeAVOSMetRfLuweCR1HSrW4BPlPB9RUOG2nI/wATSknbQLapMYMouFLZ PNREFSWZVOD1HWp9uc87R3HakC7pMdhxxVK9wttqRqMBQ2QwPPPahzgDBwccegp0 pwuQpJ/KomJ2uenv61O9iZrlbXYMAoAdoxwT6CngJwBzjk5qJU+baT/471p+7azc 4AGMHrRyplU7JojkZSpPAyarlz97uOlTuVCnnGenFVn5BxnHrRzCTvuhjsm4Ngjn HPIqDoRgEipGPy5OOuRmomIwDuAbtxx9aUY29Sk1HUY/DEDaOM9aAwZcZH1qNmYP kggZ6VXLH5trbSPapcVfcTWum5+Sv8X41YxviJzgZqsepqzgmHHQY6140+h69HqQ DhxmtGLazEAfKRyaziv7rd71bh4B5I49etRVV0aYeXK7Mvq2YQzBcjnA45qRXcuf lUnrzVaNs/Ke/XmniVBjczLxgY7VyOJ0LXlkma8ZZoyG+7jqO9ZNpj/hNBzx5jck exrRt3DQAFsAYzisy1/5G4nkfvGP4YNZ0lpNeQqyvKB3FrkS8YxjjJrrbN38tVwv qD/SuPtmxKOuB6c5FdVaNwMgkg8jGOK8tO0kdckkrXOystoY5OH/AM/nXR27kkM2 CnXjtXMWD/IJGyAa6e1YgLtyp/Wuqk/e1OWbTVjegYEAnAz69/8A61Tg4ODyO/aq kPIDFTkd+xq0APLBLLmu7m926MIubJMAk9MdgaGVdvy4UZ4IFRgjYWIHH5mlD9Bk 7MjPFEbrVFKouvUkQEEEctn8KmVisvQA4696iB+cg7lH8ORjmpC21BnO7OSK1Ury syOZKJaB+X73FRyXcVsGaZhGoPUnio3IEJb8/QivlXx3451O+8YX9jZTtb2UE7Ip Xq+OD+taKDevUHJQldn0Zf8AjnQ9NmSOW8gDu2NvmAZ5rqrbxHpjWqyi4iXjOd3S vz6kmlmlMksjyOerMcmrg1XUlTat9dge0prTl01JVdXvY/QZvFujwKu+6iJPTB61 Vf4gaDEG3XsKsGxyw5Nfn/JqF9N/rbu5kH+1KTVd5ZJGzI7yH1ZsmtlKxnzprbU+ 67342eGNPvlt1vIpWHDY5A45HFZz/H7w0hyJCxHXCMc8V8RZozVuafQiMrI+uNU/ aOt105002yllnI+Usu0D65rhG/aB8UyXEZ+zwLGrZYbySa8BoojWs9gcme33/wAe PGV3dmSP7JboFwqfM39R6elcNN8Q/F81/LcHWrlHkbLBcAD6egriaXI29Oaaq3Jb drG7P4l1241CS5m1fUHndgzN5xHI/lWdPf3d2c3V3c3JzkGWQt/OqeRnpTgBitYV JN3Exzys7FnZnJOSSaTccUhOKCcVTk1d3AMk0pZsDk03dxS7uKm6a1YrBj15pCaN 3J96aetZSmuXQaNTSLmS21dGjcoTwcV9LeBvH9xaPFBJMdpGMMa+WYmKTqw6g5rt dMu3SZH39OpBrjlXnSqKS2OmnFShax+hOieLYruOMtKM4GBmvQLPUBKg/eKV75r4 Z8N+JmR1V5SV7ete8eHPEvnBCxbOMjLdf84r2MPio1UedUw7hK6Z9AifcmMrgnoa lDDd8xGT0rirPVPM2jeMY4Oa3YLvf/Fzit5NcupgublubYdVOSWHX/8AXUuQ2Pm7 cHHtVATIylfb8DUwcYOCTjiq3Kg2vQsEDyk24OTxn/CmEfuiOjflTA2fX/GpGxkn PQ4NCWhKqJ6Ij5boAD6Z4pOGZRghc8nvUjDBHTNQ4BX+I+/pVRvfQzaaaCTG08/L xkD0qB0z/d98UO5WYqFYHr7HtigsDFgglm6ZpWfMjSSUm29xFDc7iSR61E5BdWxz 6e9PZySd6tjOOD1qInOPlLKehNNJ9RRdxGOIyWX5c/rUEjfKMEYxzgdKc2Sh+b8O 9Vy2Gx2AoSRUnukOLAAgZxULt7Z44xSGXABJPvgVE0m5N2WB+lZ6lJdOo5mG0kAD I65zVNiA+MjJHNLk7s7sH1NRMVBPzZPbNQ0ty7OUUfk4epq3Gcw/XjFVD1NWkYCM N3zivFnsenhX7xWJPTsKtEgKAB1FVm5kJqwmRACec0pbIKF7tIlVisZO7A7VUL5Y nFStkRt6VX7UQityJtqxq6eQwYHBOe9LANnioAHHznBNVbJsTY5P0qXLf8JCp6N5 gPFYSh70vQ1U37rSuztbeTacYAGeCVrp7DLAMACy9COa5K3ZvNGG3Dk8j6V1dmw3 KBtB7YrwamktDvqq7vfodnZkB8dOK6Wzch2K8Y9q5K0kDcFSSfWuotSSRtIZT04w a6YQMJtytY6KBioP1x0q2AecDAI4qjbMFwMnB6dhVtXJbg9uK7o2fQwhZ6dSXJKf Nn3GKbwoznPakz8oAYAEc5HWkJXpxV0k3uZ1U42LKOdhORjd+Rp5bI3Agc46dKrp uRAc5/xqZNuACRn0xzTunewRbtZoJdzRshI24OWBzXxd4utzbfEzW4SMEXTNz/tc /wBa+0G2jg459K+RviNbyw/FjUpZFKicq6Z9NoX+ldFOUXLzM6jOFooorYzCiiig AooooAKKKKACiiigAooooAKKKKdwCiiilcAooooAVSQ4I9a6KzlZbZcZHpgVzoyC CK2bNsW4ycEE85rnxC91HVhru9jtdOumWVGOQeMAnr71654W1eQ3AXIB6cnpXhkM gRwAevfNdpoN4Y9SjO/BB5bNY4as4T1OnEUVLZan1zpN/i1R92SvBFdfZ3rFQTsG eBgdK8j0O9DaTF+95xnJ7129pfIWGZct717yqX1PGlDlWh6RFMSvzHn1PStSOUlV GV6YBrkLO+jwgDDd0+atyG5DgYDA/wAq6Yt7MxnG6djfQ5Iwy7j6VOXyMEAEfxY6 1krckKu3ke5zxVjznw2M47eo+taWUtUZSuXTjgkgY6YqMyoSfmX/AAqoJW2k/MrY 6GoxuK8j3Bx0ptaWB1E37uxPIwBAYx7uOTUDOpbABfP5UyRdq45yf0qMOwAIzgcV VtCr3bQ4yv7Z/vY5piv+7AOOD2oJ5BBxjpzTCUyDnPrmmlctJrZ2AlWIPJyOMVCx KsRtwR0oLjkqCpBqAyMN244GeDRy3Vwjtf8AEicZPDDAPeqzlgww42+h6VOz5GOD 6c1A/BABGOgx3pOxKpOTvqRszgnJ6dOKrOSXLBgExxxUjOd5OcLjOM9apSMSWbAX nmjk0uaJWj13P//Z --Boundary_(ID_hxYMqP35h8T6vDo0/4isLA)-- From sac-owner Tue Feb 19 13:10:27 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1JLARRI029402 for ; Tue, 19 Feb 2008 13:10:27 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1JLARm4006656 for ; Tue, 19 Feb 2008 13:10:27 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1JLARI0000944 for ; Tue, 19 Feb 2008 21:10:27 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 <0JWI00A016AHL600@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for sac-review@sac.sfbay.sun.com; Tue, 19 Feb 2008 14:10:27 -0700 (MST) Received: from [192.168.1.64] ([189.137.195.67]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWI00CSO853HK90@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Tue, 19 Feb 2008 14:10:18 -0700 (MST) Date: Tue, 19 Feb 2008 15:10:19 -0600 From: Brian Cameron Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47BB1DAB.1060901@Sun.Com> Sender: Brian.Cameron@sun.com To: John Plocher Cc: John.Fischer@sun.com, sac-review@sac.sfbay.sun.com, james hughes , Kathy Jenks Message-id: <47BB45BB.7090001@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47BB173F.4030809@sun.com> <47BB1DAB.1060901@Sun.Com> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 947 John: I think the following would also be useful to ask: - Does the project have appropriate manpages? - Does the project have API documentation installed to the system. If so, is the documentation referenced in the manpage? - Is the project I18N ready? - If the project has a GUI, is it accessible However, if these sorts of questions don't impact whether the project would be automatically accepted, I understand not asking them. It seems useful to ask, just to prompt people to think about such issues, and hopefully do things like a11y testing, though. Brian > A first pass list at the Solaris things that need to be chosen > over "linux versions" each and every time there is a conflict > would seem to be: > > Secure by default, auths, audit (already there) > xVm > zones / Solaris Containers > PRM > RBAC > TX > ZFS > SMF > FMA > IPv6 > IPsec > SCF > > I'm sure there are more. From sac-owner Tue Feb 19 15:27:28 2008 Received: from dm-eng-02.sfbay.sun.com (dm-eng-02 [129.146.11.32]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1JNRS4k006658 for ; Tue, 19 Feb 2008 15:27:28 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1JNRSsT017685; Tue, 19 Feb 2008 15:27:28 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1JNRmqg017373; Tue, 19 Feb 2008 15:27:48 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1JNRmg1017372; Tue, 19 Feb 2008 15:27:48 -0800 (PST) Date: Tue, 19 Feb 2008 15:27:48 -0800 (PST) From: Gary Winiger Message-Id: <200802192327.m1JNRmg1017372@marduk.eng.sun.com> To: John.Fischer@sun.com, John.Plocher@sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Cc: sac-review@sac.sfbay.sun.com, James.Hughes@sun.com, Kathy.Jenks@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 530 > > We believed that the integration points were the most critical for us > > and included security, installation and making a component sharable. > > > I would add the following perspective, driven in part by the > recent discussions around GPM and HAL (e.g., libpolkit and RBAC: Also, if JohnP ever publishes the "FOSS precidences" policies (best practices) I sent him a couple weeks ago, how does this align there? Hint hint JohnP.... I'll take a closer look at JohnF's check list when I'm back in the Office. Gary.. From sac-owner Tue Feb 19 16:27:05 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1K0R5LA009828 for ; Tue, 19 Feb 2008 16:27:05 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1K0R5NX003503 for ; Tue, 19 Feb 2008 16:27:05 -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 m1K0R0So012165 for ; Tue, 19 Feb 2008 16:27:00 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWI00201H46UR00@fe-sfbay-09.sun.com> (original mail from Terrence.Miller@Sun.COM) for sac-review@sac.sfbay.sun.com; Tue, 19 Feb 2008 16:27:00 -0800 (PST) Received: from [129.146.86.55] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWI00K68H8SDYD0@fe-sfbay-09.sun.com> for sac-review@sac.sfbay.sun.com; Tue, 19 Feb 2008 16:26:52 -0800 (PST) Date: Tue, 19 Feb 2008 16:26:52 -0800 From: Terrence Miller Subject: Re: LSARC/2008/061 - FOSS Check List Sender: Terrence.Miller@sun.com To: John.Fischer@sun.com, John.Plocher@sun.com Cc: sac-review@sac.sfbay.sun.com, James.Hughes@sun.com, Kathy.Jenks@sun.com Reply-to: Terrence.Miller@sun.com Message-id: <47BB73CC.1060507@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_gzTRwJFmUufoddL3wZ3ezg)" User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 1164 This is a multi-part message in MIME format. --Boundary_(ID_gzTRwJFmUufoddL3wZ3ezg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT > > We believed that the integration points were the most critical for us > > and included security, installation and making a component sharable. > > > I would add the following perspective, driven in part by the > recent discussions around GPM and HAL (e.g., libpolkit and RBAC: Also, if JohnP ever publishes the "FOSS precidences" policies (best practices) I sent him a couple weeks ago, how does this align there? Hint hint JohnP.... I'll take a closer look at JohnF's check list when I'm back in the Office. Gary.. --Boundary_(ID_gzTRwJFmUufoddL3wZ3ezg) Content-type: text/x-vcard; name=Terrence.Miller.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Terrence.Miller.vcf begin:vcard fn:Terrence Miller n:Miller;Terrence adr:16 Network Circle;;UMPK-303;Menlo Park,;CA;94025;USA email;internet:terrence.miller@sun.com tel;work:650-786-9192 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_gzTRwJFmUufoddL3wZ3ezg)-- From sac-owner Wed Feb 20 00:24:15 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1K8OFUt022474 for ; Wed, 20 Feb 2008 00:24:15 -0800 (PST) Received: from gmp-eb-mail-2.sun.com (gmp-eb-mail-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1K8OFbK039790 for ; Wed, 20 Feb 2008 00:24:15 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1K8O9Zm010590 for ; Wed, 20 Feb 2008 08:24:09 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JWJ00A012ZHUM00@fe-emea-10.sun.com> (original mail from Trevor.Watson@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 08:24:09 +0000 (GMT) Received: from [192.168.254.102] ([81.129.5.158]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ00CAV3C2DM60@fe-emea-10.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 08:24:03 +0000 (GMT) Date: Wed, 20 Feb 2008 08:24:02 +0000 From: Trevor Watson Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47BB173F.4030809@sun.com> Sender: Trevor.Watson@sun.com To: John.Fischer@sun.com Cc: sac-review@sac.sfbay.sun.com Message-id: <47BBE3A2.9040500@Sun.COM> Organization: Sun Microsystems Ltd. MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms050501050203020701010704; micalg=sha1; protocol="application/x-pkcs7-signature" References: <47BB173F.4030809@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20071119) Status: RO Content-Length: 5355 --------------ms050501050203020701010704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My only comment, for what it is worth, would in the section on licensing: When asking "Is the license viral?", I wonder if this is asking too much of the submitter? What I mean is: how many submitters will actually be qualified to make a judgement on whether or not a license is viral - assuming it is not GPL? Is that not a quasi-legal definition, requiring legal review? I guess from my perspective, I would prefer to see the submitter report the license type - either as a tickbox or simply enter the type and URL. Trev --------------ms050501050203020701010704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJEzCC AuQwggJNoAMCAQICEAF3zPJ4un8AzSM2bz1WwGYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMyODA3NTEyM1oX DTA4MDMyNzA3NTEyM1owRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIG CSqGSIb3DQEJARYVdHJldm9yLndhdHNvbkBzdW4uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAr22BHS+BPImaQdnBjJwc+6YCj594i8RKrtxfdAJqoPNVKAsl3ExDuJhX X4sTReUTzRJ/3+lFE4g3TkFjTQsXC6qbEXtCH+C3tzwKM3H6gRIZNn6aS6TfuacmwENJ3xjy ZkEgQDVaocJ1UAsM8PtFqW/4Gtq7hxDskeZj0Bi/fn6XYJP7uCa62rqaOGkX27y7Z8xGaqlQ 9V/bRd0NA0oxxIb14wOHaF3uZFLPmwo7yYlQWOgw2mxe7zGueOMqNCYLvd5b267VRKf61D0b 5vwleNgujrxqV4c6OijHIcN3TYgsMloXMAG/EzGTPrDeGup3hp/8bJ3bPS5ZS9PbS6+UpwID AQABozIwMDAgBgNVHREEGTAXgRV0cmV2b3Iud2F0c29uQHN1bi5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQAWDfDYGoOhAAobnGMScxPz5vl6HOEP4fVrT4mZ9v3NkGEf hC8tytX8yX3LMhEZlASPt8Bw0sNye5doj9VVJVGRutJwNu++dWRiWzv51o3bX9S5nePjOdet 19qR9dQo402vu3jA/QtOyUzbcYJRkOPlm6rE/AnmiVasDxZgAaYYSjCCAuQwggJNoAMCAQIC EAF3zPJ4un8AzSM2bz1WwGYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMyODA3NTEyM1oXDTA4MDMyNzA3NTEy M1owRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIGCSqGSIb3DQEJARYV dHJldm9yLndhdHNvbkBzdW4uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA r22BHS+BPImaQdnBjJwc+6YCj594i8RKrtxfdAJqoPNVKAsl3ExDuJhXX4sTReUTzRJ/3+lF E4g3TkFjTQsXC6qbEXtCH+C3tzwKM3H6gRIZNn6aS6TfuacmwENJ3xjyZkEgQDVaocJ1UAsM 8PtFqW/4Gtq7hxDskeZj0Bi/fn6XYJP7uCa62rqaOGkX27y7Z8xGaqlQ9V/bRd0NA0oxxIb1 4wOHaF3uZFLPmwo7yYlQWOgw2mxe7zGueOMqNCYLvd5b267VRKf61D0b5vwleNgujrxqV4c6 OijHIcN3TYgsMloXMAG/EzGTPrDeGup3hp/8bJ3bPS5ZS9PbS6+UpwIDAQABozIwMDAgBgNV HREEGTAXgRV0cmV2b3Iud2F0c29uQHN1bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQUFAAOBgQAWDfDYGoOhAAobnGMScxPz5vl6HOEP4fVrT4mZ9v3NkGEfhC8tytX8yX3LMhEZ lASPt8Bw0sNye5doj9VVJVGRutJwNu++dWRiWzv51o3bX9S5nePjOdet19qR9dQo402vu3jA /QtOyUzbcYJRkOPlm6rE/AnmiVasDxZgAaYYSjCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggNkMIIDYAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQAXfM8ni6fwDNIzZvPVbAZjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODAyMjAwODI0MDJaMCMGCSqGSIb3DQEJBDEW BBR7rkyXDf2fWI2wWrwo2HAHhqwJ3TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB hQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECEAF3zPJ4un8AzSM2bz1WwGYwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEAF3zPJ4un8AzSM2bz1W wGYwDQYJKoZIhvcNAQEBBQAEggEAcnBIqBHISmm7YJEdxr8FJarV53SwJzoybESVqXtgYk/T FuxuaywbB5vERPfwXTYNSbihZ45U1/XVVPiEKAk4nOjYloa1zZgM0ZNLpIu+ZsBwjKw50VHS 3nRrLwa6Kp77coUS7QE7a8lnJf/SaJ2M8ZD/qYcGdtBFBsH4rFmfdUQs1AE9ATX2X9lvpAK/ r/E+ZrEBfAf6y5uTx9/3TtHS+QPmhIzAzWFRhlNbeW8tYJ5ZnmUjFEPWOm3rWtAC0R43OGgb 7V9nt3ra7bChZP7A6vQHtOQ39RflKgLCc0M1fKA/qP44nx0K+aziPrb4lUiewj0JZKakJOC4 NYput4rE6wAAAAAAAA== --------------ms050501050203020701010704-- From sac-owner Wed Feb 20 10:03:20 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KI3Kd5012508 for ; Wed, 20 Feb 2008 10:03:20 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KI3KLn012499 for ; Wed, 20 Feb 2008 10:03:20 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1KI3KIO027216 for ; Wed, 20 Feb 2008 18:03:20 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 <0JWJ00B01T60NS00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 11:03:20 -0700 (MST) Received: from 129.145.154.84 ([129.145.154.84]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ005ZYU56GV90@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 11:03:07 -0700 (MST) Date: Wed, 20 Feb 2008 10:03:06 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47BBE3A2.9040500@Sun.COM> Sender: John.Fischer@sun.com To: Trevor Watson Cc: John Fischer , sac-review@sac.sfbay.sun.com Reply-to: John.Fischer@sun.com Message-id: <1203530586.63061.29.camel@sr1-umpk-34> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: text/plain Content-transfer-encoding: 7BIT References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> Status: RO Content-Length: 925 Trev, That is funny as this is how I originally had it in the check list during round 0.1. Then I simply had a check box for GPL and Other which lead to what you see now. The original listed the best known license types with check boxes next to them. I can redo that if sac thinks that is better. Thanks, John On Wed, 2008-02-20 at 00:24, Trevor Watson wrote: > My only comment, for what it is worth, would in the section on licensing: > > When asking "Is the license viral?", I wonder if this is asking too much of > the submitter? What I mean is: how many submitters will actually be qualified > to make a judgement on whether or not a license is viral - assuming it is not > GPL? Is that not a quasi-legal definition, requiring legal review? > > I guess from my perspective, I would prefer to see the submitter report the > license type - either as a tickbox or simply enter the type and URL. > > > Trev From sac-owner Wed Feb 20 10:04:53 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KI4r9X012651 for ; Wed, 20 Feb 2008 10:04:53 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KI4qOn026810 for ; Wed, 20 Feb 2008 10:04:52 -0800 (PST) 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 m1KI4qmA010683 for ; Wed, 20 Feb 2008 18:04:52 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 <0JWJ00C01R849U00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 11:04:52 -0700 (MST) Received: from 129.145.154.84 ([129.145.154.84]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ0050JU7IGVB0@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 11:04:31 -0700 (MST) Date: Wed, 20 Feb 2008 10:04:30 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47BB45BB.7090001@sun.com> Sender: John.Fischer@sun.com To: Brian Cameron Cc: John Fischer , John Plocher , sac-review@sac.sfbay.sun.com, james hughes , Kathy Jenks Reply-to: John.Fischer@sun.com Message-id: <1203530669.63061.32.camel@sr1-umpk-34> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: text/plain Content-transfer-encoding: 7BIT References: <47BB173F.4030809@sun.com> <47BB1DAB.1060901@Sun.Com> <47BB45BB.7090001@sun.com> Status: RO Content-Length: 1363 Brian, As you know these types of questions came up during the review in LSARC. What was stated then was that these types of things were part of fit-n-finish and should be part of a C-Team check list. These things would not cause the FOSS project to need further review. Thanks, John On Tue, 2008-02-19 at 13:10, Brian Cameron wrote: > John: > > I think the following would also be useful to ask: > > - Does the project have appropriate manpages? > - Does the project have API documentation installed to the system. > If so, is the documentation referenced in the manpage? > - Is the project I18N ready? > - If the project has a GUI, is it accessible > > However, if these sorts of questions don't impact whether the > project would be automatically accepted, I understand not asking > them. It seems useful to ask, just to prompt people to think > about such issues, and hopefully do things like a11y testing, > though. > > Brian > > > > A first pass list at the Solaris things that need to be chosen > > over "linux versions" each and every time there is a conflict > > would seem to be: > > > > Secure by default, auths, audit (already there) > > xVm > > zones / Solaris Containers > > PRM > > RBAC > > TX > > ZFS > > SMF > > FMA > > IPv6 > > IPsec > > SCF > > > > I'm sure there are more. > From sac-owner Wed Feb 20 10:18:13 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KIIDvB015544 for ; Wed, 20 Feb 2008 10:18:13 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KIIDjG024424 for ; Wed, 20 Feb 2008 10:18:13 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1KIIDRU008081 for ; Wed, 20 Feb 2008 18:18:13 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 <0JWJ00101UFOO300@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 11:18:13 -0700 (MST) Received: from 129.145.154.84 ([129.145.154.84]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ005WJUU9DW20@mail-amer.sun.com>; Wed, 20 Feb 2008 11:18:10 -0700 (MST) Date: Wed, 20 Feb 2008 10:18:09 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <200802192327.m1JNRmg1017372@marduk.eng.sun.com> Sender: John.Fischer@sun.com To: Gary Winiger Cc: John Fischer , John.Plocher@sun.com, sac-review@sac.sfbay.sun.com, James.Hughes@sun.com, Kathy.Jenks@sun.com Reply-to: John.Fischer@sun.com Message-id: <1203531488.63061.50.camel@sr1-umpk-34> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: text/plain Content-transfer-encoding: 7BIT References: <200802192327.m1JNRmg1017372@marduk.eng.sun.com> Status: RO Content-Length: 761 Gary, I haven't seen it. John P needs to get this out soon so that I can look at it. So I can not even begin to answer your question. Sorry, John On Tue, 2008-02-19 at 15:27, Gary Winiger wrote: > > > We believed that the integration points were the most critical for us > > > and included security, installation and making a component sharable. > > > > > > I would add the following perspective, driven in part by the > > recent discussions around GPM and HAL (e.g., libpolkit and RBAC: > > Also, if JohnP ever publishes the "FOSS precidences" policies > (best practices) I sent him a couple weeks ago, how does > this align there? Hint hint JohnP.... > I'll take a closer look at JohnF's check list when I'm back > in the Office. > > Gary.. From sac-owner Wed Feb 20 10:18:38 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KIIcOf015591 for ; Wed, 20 Feb 2008 10:18:38 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1KIIbpI011613; Wed, 20 Feb 2008 13:18:38 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1KIIb3K011610; Wed, 20 Feb 2008 13:18:37 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18364.28413.813526.209800@gargle.gargle.HOWL> Date: Wed, 20 Feb 2008 13:18:37 -0500 From: James Carlson To: John.Fischer@sun.com Cc: Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <1203530586.63061.29.camel@sr1-umpk-34> References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 552 John Fischer writes: > The original listed the best known license types with > check boxes next to them. I can redo that if sac thinks > that is better. I'm still confused about how SAC or the ARC could ever use this information in any reasonable way. We're not trained as lawyers, and it doesn't strike me as architectural. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Wed Feb 20 10:19:43 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KIJhEj015657 for ; Wed, 20 Feb 2008 10:19:43 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KIJhKo038738 for ; Wed, 20 Feb 2008 10:19:43 -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 m1KIJglF018308 for ; Wed, 20 Feb 2008 18:19:42 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 <0JWJ00F01U7AUS00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 11:19:42 -0700 (MST) Received: from 129.145.154.84 ([129.145.154.84]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ00BLOUWMUE40@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 11:19:34 -0700 (MST) Date: Wed, 20 Feb 2008 10:19:34 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47BB1DAB.1060901@Sun.Com> Sender: John.Fischer@sun.com To: John Plocher Cc: sac-review@sac.sfbay.sun.com, james hughes , Kathy Jenks Reply-to: John.Fischer@sun.com Message-id: <1203531573.63061.53.camel@sr1-umpk-34> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: text/plain; charset=ASCII Content-transfer-encoding: 7BIT References: <47BB173F.4030809@sun.com> <47BB1DAB.1060901@Sun.Com> Status: RO Content-Length: 2291 John, How about adding a section about duplication of similar core interfaces within Solaris? I would state that these FOSS components would require further review (i.e., do not fit with the Automatic approval). So something like: 3.3 Core Solaris Components Do the components of this project compete with or duplicate core Solaris components? [ ] Yes [ ] No If yes please check the appropriate core component below: [ ] Secure By Default [ ] Authorizations [ ] Audit [ ] xVm [ ] zones / Solaris Containers [ ] PRM [ ] RBAC [ ] TX / Trusted Extensions [ ] ZFS [ ] SMF [ ] FMA [ ] IPv6 [ ] IPsec [ ] SCF [ ] Other - specify below If any of the above are checked then further ARC review is required. Would that help or only muddy things more? Thanks, John On Tue, 2008-02-19 at 10:19, John Plocher wrote: > > We believed that the integration points were the most critical for us > > and included security, installation and making a component sharable. > > > I would add the following perspective, driven in part by the > recent discussions around GPM and HAL (e.g., libpolkit and RBAC): > > There are things that Sun/Solaris has that differentiate it from > other operating systems out there; things that we do not want > to devalue, obscure or hide when we include FOSS projects that > overlap in those spaces. This implies that, when FOSS things > are introduced that reimplement or override or ignore the work > Sun has done in those areas, that the team that is integrating > or using the FOSS project be required to do [something, probably > significant somethings] to ensure that the strategic Solaris > features be used instead. > > A first pass list at the Solaris things that need to be chosen > over "linux versions" each and every time there is a conflict > would seem to be: > > Secure by default, auths, audit (already there) > xVm > zones / Solaris Containers > PRM > RBAC > TX > ZFS > SMF > FMA > IPv6 > IPsec > SCF > > I'm sure there are more. > > -John > > From sac-owner Wed Feb 20 10:22:15 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KIMFlG015799 for ; Wed, 20 Feb 2008 10:22:15 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KIMEk0040762 for ; Wed, 20 Feb 2008 10:22:14 -0800 (PST) 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 m1KIMEUC004510 for ; Wed, 20 Feb 2008 18:22:14 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 <0JWJ00B01T6EV900@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 11:22:14 -0700 (MST) Received: from 129.145.154.84 ([129.145.154.84]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ005VAV0FDW30@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 11:21:52 -0700 (MST) Date: Wed, 20 Feb 2008 10:21:51 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <18364.28413.813526.209800@gargle.gargle.HOWL> Sender: John.Fischer@sun.com To: James Carlson Cc: John Fischer , Trevor Watson , sac-review@sac.sfbay.sun.com Reply-to: John.Fischer@sun.com Message-id: <1203531711.63061.56.camel@sr1-umpk-34> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: text/plain Content-transfer-encoding: 7BIT References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> Status: RO Content-Length: 862 James, It was simply added to aid in the review process. If a viral component were to be added to a well known location say /usr/lib then wouldn't we want to look closer at it as a licensee and/or committee member? Thanks, John On Wed, 2008-02-20 at 10:18, James Carlson wrote: > John Fischer writes: > > The original listed the best known license types with > > check boxes next to them. I can redo that if sac thinks > > that is better. > > I'm still confused about how SAC or the ARC could ever use this > information in any reasonable way. We're not trained as lawyers, and > it doesn't strike me as architectural. > > -- > James Carlson, Solaris Networking > Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Wed Feb 20 10:28:46 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KISkmC016788 for ; Wed, 20 Feb 2008 10:28:46 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KISk44045527 for ; Wed, 20 Feb 2008 10:28:46 -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 m1KISfcn007221 for ; Wed, 20 Feb 2008 10:28:41 -0800 (PST) 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 <0JWJ00601ULKQ600@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 10:28:41 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ007QPVBLSY70@fe-sfbay-10.sun.com>; Wed, 20 Feb 2008 10:28:33 -0800 (PST) Date: Wed, 20 Feb 2008 10:28:31 -0800 From: John Plocher Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <1203531488.63061.50.camel@sr1-umpk-34> Sender: John.Plocher@sun.com To: John.Fischer@sun.com Cc: Gary Winiger , sac-review@sac.sfbay.sun.com, James.Hughes@sun.com, Kathy.Jenks@sun.com Message-id: <47BC714F.4000808@Sun.Com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_e+rR58nY87KefTZafnNRaw)" References: <200802192327.m1JNRmg1017372@marduk.eng.sun.com> <1203531488.63061.50.camel@sr1-umpk-34> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 10271 This is a multi-part message in MIME format. --Boundary_(ID_e+rR58nY87KefTZafnNRaw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT John Fischer wrote: > Gary, > > I haven't seen it. John P needs to get this > out soon Here is what Gary sent me... -John --Boundary_(ID_e+rR58nY87KefTZafnNRaw) Content-type: message/rfc822; name="Attached Message" Return-path: Received: from fe-sfbay-10.sun.com ([192.18.34.120]) by sfbay2-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JVQ00G1SR8GHF30@sfbay2-mail1.sfbay.sun.com> for plocher@sfbay2-mail1.sfbay.Sun.COM; Mon, 04 Feb 2008 17:09:52 -0800 (PST) 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 <0JVQ00F01R2KSK00@fe-sfbay-10.sun.com> for plocher@sfbay2-mail1.sfbay.Sun.COM (ORCPT plocher@sfbay2-mail1.sfbay.Sun.COM) ; Mon, 04 Feb 2008 17:09:52 -0800 (PST) Received: from phys-sfbay2-2.sfbay.sun.com ([129.145.47.19]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JVQ00C4NR7XI720@fe-sfbay-10.sun.com> for plocher@sfbay2-mail1.sfbay.Sun.COM (ORCPT plocher@sfbay2-mail1.sfbay.Sun.COM) ; Mon, 04 Feb 2008 17:09:33 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by sfbay2-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JVQ00GZ5R7XHF20@sfbay2-mail1.sfbay.sun.com> for plocher@sfbay2-mail1.sfbay.Sun.COM; Mon, 04 Feb 2008 17:09:33 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1519XN4058835 for ; Mon, 04 Feb 2008 17:09:33 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1519Vev015428; Mon, 04 Feb 2008 17:09:31 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1519Ud2015427; Mon, 04 Feb 2008 17:09:30 -0800 (PST) Date: Mon, 04 Feb 2008 17:09:30 -0800 (PST) From: Gary Winiger Subject: Policy and Practices extracted To: John.Plocher@Sun.COM Cc: gww@marduk.eng.sun.com Message-id: <200802050109.m1519Ud2015427@marduk.eng.sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_5DaRbBxSvHXnth1K/1Ms6A)" Original-recipient: rfc822;plocher@sfbay2-mail1.sfbay.Sun.COM --Boundary_(ID_5DaRbBxSvHXnth1K/1Ms6A) Content-type: TEXT/PLAIN; NAME=text Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=text Content-description: text X-Sun-Charset: us-ascii John, This is pretty much the write up I did some time ago for my group. I also sent it to Comay and You on 7 November 2007 at 1328 and asked then: P.S. John you also asked for a copy. If you believe this should go into some case log or all-arcs or something other than flush.... Let me know how to proceed. ABICT, I never got a response or did anything to follow up. I've updated this a little today. Corrected spelling and added the Best Practices section. Gary.. P.S. It took a while to convince some of LSARC that SAC policies applied to their reviews. That was sometime late last year. --Boundary_(ID_5DaRbBxSvHXnth1K/1Ms6A) Content-type: TEXT/PLAIN; NAME=AdminSecReqs Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=AdminSecReqs Content-description: default X-Sun-Charset: us-ascii X-Sun-Data-type: default A list of Precedents and Policies for administrative/security related CLIs/functions has been available in the SAC logs for some time. I've been meaning to pull it out for solsec. These go back sometime. The various case histories that I easily dug up (there may be others) are: PSARC/1999/555 Getting with the Freeware Program * Established an initial set of non-ON/AT&T/UCB CLIs and supporting libraries to be shipped with/supported with Solaris. The risks pointed out included keeping up to date. These all shipped in /usr/{bin,lib}/ and didn't have name conflicts with existing Solaris CLIs/libraries PSARC/2000/488 Solaris/Linux Commands Compatibility * Established the "External" interface taxonomy. * Set aside the ``Sun Application Binary Guarantee'' for these CLIs. * Established a residence (/usr/sfw) outside the default Solaris paths so customers wouldn't treat as under Sun ABI Guarantee/Support. * Added a number of CLIs, some with 'g' prefixes. * Established the following Security concerns/policies guidelines/requirements for suid or otherwise privilege programs: - All authentication is to be performed through PAM (See PAM policy below). - Interaction with the Solaris auditing framework is "highly desirable". N.B. a later SAC policy (see below) establishes that appropriate audit is required using the Solaris Audit framework. PSARC/2005/185 Enabling serendipitous discovery * Notes that "External" taxonomy is largely misapplied. * Breaks the requirement for a separate residence for "External" interface taxonomy interfaces to reside in /usr/sfw. * Reinforces that FOSS still comes under the process review rules. * Suggests a migration out of /usr/sfw into /usr. PSARC/2005/220 New Public Taxonomy * Does away with the misapplied "External" taxonomy. * Establishes interface taxonomies based on how Sun will support the interfaces rather than the perceived tie in with the source of the interface: - Committed -- can be used with confidence that binaries will continue to run without change across patches and minor releases. Encompasses formal (and de facto) standards. - Uncommitted -- can be used with less confidence that binaries will continue to run without change across minor releases. Not a license for gratuitous change, but a more wiggle room. - Volatile -- interface can change at any time for any reason. Use at your own risk. Often appropriate for functionality over which Sun values change over stability. - Not-an-Interface -- just that, don't even think of programming to this. Normally meant for such things as human readable output or icon placement or menu contents. PSARC/2007/048 Include GNU coreutils 6.7 * Established a bunch "GNU" commands considered core in /usr hierarchy. * Establishes a "/usr/gnu" hierarchy for commands the conflict with existing Solaris commands. * Reinforces the use PAM and Solaris Audit requirements from 2000/488 Policies. ======== N.B. Some of these policies may be out of date with respect to the internal versions of them. Sac staff doesn't alawys have the time to sync them up. The internal versions can be found at: http://sac.eng/BestPractices/bp.cgi?NAME=INDEX&OWNER=SAC http://opensolaris.org/os/community/arc/policies/shared-sharable/ Packaging rules for system extensions * Establishes the packaging rules such as components may only be delivered from one package. This is the famous PSARC/1991/061 case. * Gives some implementation guidance. http://opensolaris.org/os/community/arc/policies/libraries/ Library and Shared Object Requirements * Establishes rules for shared library naming and versioning. * Gives some implementation guidance. http://opensolaris.org/os/community/arc/policies/SMF-policy/ Service Management Facility (SMF) usage * Established the use of SMF for all Solaris services. * Gives requirements and details for meeting the "Secure by Default" (SBD) and "Role Based Access Control" (RBAC) project policies. * Gives advice on how to correctly configure services. http://opensolaris.org/os/community/arc/policies/NITS-policy/ Network Install-Time Security * Security SWG policy for security during and as the result of installation. * Defines security requirements for inbound and outbound network communications http://opensolaris.org/os/community/arc/policies/PAM/ PAM (Plugable Authentication Modules) usage requirements * Establishes the use of PAM for all authentication and reauthentication. * Includes details and guides for use. * Associated with auditing and points to the Solaris Audit Policy http://opensolaris.org/os/community/arc/policies/audit-policy/ Solaris Auditing Policy * Pretty much defines what needs to be audited. * Includes details on what makes up an audit record. * Points to the Audit project team for advice * Gives some broad implementation guides. Best Practices. ============== Same N.B. as above. Secrity SWG internal versions can be found at: http://sac.eng/BestPractices/bp.cgi?NAME=INDEX&OWNER=Security-SWG http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ When to use setuid -vs- RBAC roles and profiles * Discusses when to use setuid (forced privileges) and introduces the use or RBAC and its interactions with Solaris. * Historic with historic references. http://opensolaris.org/os/community/arc/bestpractices/rbac-auths/ Adding RBAC Authorizations * How to guide for adding Authorizations to Solaris. http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ Building RBAC Rights Profiles * How to guide for adding Rights Profiles to Solaris. http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ Reusable Passwords In Command Line Arguments and Environment Variables * From the Security SWG * Security concerns and guide lines prohibiting exposure of reusable passwords. http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ Storing Reusable Passwords on a Filesystem * From the Security SWG * Security concerns and requirements for protection if/when reusable passwords are stored in the Filesystem. @(#)AdminSecReqs 1.3 08/02/04 --Boundary_(ID_5DaRbBxSvHXnth1K/1Ms6A)-- --Boundary_(ID_e+rR58nY87KefTZafnNRaw)-- From sac-owner Wed Feb 20 10:32:01 2008 Received: from dm-eng-02.sfbay.sun.com (dm-eng-02 [129.146.11.32]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KIW1Xi017588 for ; Wed, 20 Feb 2008 10:32:01 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KIW0OU034611; Wed, 20 Feb 2008 10:32:00 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1KIWMFq019293; Wed, 20 Feb 2008 10:32:22 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1KIWMqq019292; Wed, 20 Feb 2008 10:32:22 -0800 (PST) Date: Wed, 20 Feb 2008 10:32:22 -0800 (PST) From: Gary Winiger Message-Id: <200802201832.m1KIWMqq019292@marduk.eng.sun.com> To: John.Fischer@sun.com, John.Plocher@sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Cc: gww@eng.sun.com, sac-review@sac.sfbay.sun.com, James.Hughes@sun.com, Kathy.Jenks@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 145 > Here is what Gary sent me... Just sent to JohnF privately for his processing. I'm about to start looking at the original proposal. Gary.. From sac-owner Wed Feb 20 10:35:46 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KIZjAo017842 for ; Wed, 20 Feb 2008 10:35:46 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1KIZjK6011700; Wed, 20 Feb 2008 13:35:45 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1KIZjJa011697; Wed, 20 Feb 2008 13:35:45 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18364.29441.424474.30500@gargle.gargle.HOWL> Date: Wed, 20 Feb 2008 13:35:45 -0500 From: James Carlson To: John.Fischer@sun.com Cc: Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <1203531711.63061.56.camel@sr1-umpk-34> References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1023 John Fischer writes: > It was simply added to aid in the review process. If a viral > component were to be added to a well known location say /usr/lib > then wouldn't we want to look closer at it as a licensee and/or > committee member? As I said, I don't see how it "aids" in any particular way. We're not lawyers. Why should we be trying to apply our lack of expertise to this touchy domain? Or inventing our own novel legal/marketing concepts such as "viral licensing?" Especially when we'd end up being liable when (not if) we amateur lawyers get it wrong? For what it's worth, the system is just littered with software with odd licensing arrangements, and little way to manage those. I'm not sure it's something we can rightly do much about. It has to be Somebody Else's problem. ;-} -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Wed Feb 20 10:55:36 2008 Received: from dm-holland-02.uk.sun.com (dm-holland-02.UK.Sun.COM [129.156.101.225]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KItZaZ019190 for ; Wed, 20 Feb 2008 10:55:36 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m1KItXIM006432; Wed, 20 Feb 2008 18:55:33 GMT Message-Id: <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> From: Casper.Dik@sun.com To: James Carlson cc: John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <18364.29441.424474.30500@gargle.gargle.HOWL> References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Feb 2008 19:55:33 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1036 >John Fischer writes: >> It was simply added to aid in the review process. If a viral >> component were to be added to a well known location say /usr/lib >> then wouldn't we want to look closer at it as a licensee and/or >> committee member? > >As I said, I don't see how it "aids" in any particular way. We're not >lawyers. Why should we be trying to apply our lack of expertise to >this touchy domain? Or inventing our own novel legal/marketing >concepts such as "viral licensing?" Especially when we'd end up being >liable when (not if) we amateur lawyers get it wrong? > >For what it's worth, the system is just littered with software with >odd licensing arrangements, and little way to manage those. I'm not >sure it's something we can rightly do much about. It has to be >Somebody Else's problem. ;-} If this is going to replace the "in bound OpenSource Review" process, then there is a big risk; if it is NOT going to replace the lawyer's review, why can't why just put the OSR case # in the FOSS checklist? Casper From sac-owner Wed Feb 20 11:10:11 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJABJW021009 for ; Wed, 20 Feb 2008 11:10:11 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m1KJA7Bv015344; Wed, 20 Feb 2008 13:10:07 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1KJA792015343; Wed, 20 Feb 2008 13:10:07 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 20 Feb 2008 13:10:07 -0600 From: Nicolas Williams To: Casper.Dik@sun.com Cc: James Carlson , John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Message-ID: <20080220191006.GD14350@Sun.COM> References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1955 On Wed, Feb 20, 2008 at 07:55:33PM +0100, Casper.Dik@Sun.COM wrote: > > >John Fischer writes: > >> It was simply added to aid in the review process. If a viral > >> component were to be added to a well known location say /usr/lib > >> then wouldn't we want to look closer at it as a licensee and/or > >> committee member? > > > >As I said, I don't see how it "aids" in any particular way. We're not > >lawyers. Why should we be trying to apply our lack of expertise to > >this touchy domain? Or inventing our own novel legal/marketing > >concepts such as "viral licensing?" Especially when we'd end up being > >liable when (not if) we amateur lawyers get it wrong? > > > >For what it's worth, the system is just littered with software with > >odd licensing arrangements, and little way to manage those. I'm not > >sure it's something we can rightly do much about. It has to be > >Somebody Else's problem. ;-} > > > If this is going to replace the "in bound OpenSource Review" process, > then there is a big risk; if it is NOT going to replace the lawyer's > review, why can't why just put the OSR case # in the FOSS checklist? There are two problems that I see: 1) OSRs don't help us evaluate whether importing a given interface into another is allowed or what its consequences are (this being the viral part) -- OSRs are not machine-readable, requiring a human to read the opinion and then make this evaluation. The OSR opinion may lack sufficient information! 2) The decision of what to do about the consequences of importing, say, a GPLed interface in a non-GPLed project is a *business* decision, not a legal nor architectural decision. But in order to make this decision those consequences need to be clear. See (1). So, perhaps the OSR process needs some updates, and the SDF process needs some updates to deal with (2), and the ARC and c-teams need to enforce business decisions relating to (2). Nico -- From sac-owner Wed Feb 20 11:13:21 2008 Received: from dm-holland-02.uk.sun.com (dm-holland-02.UK.Sun.COM [129.156.101.225]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJDKD0021137 for ; Wed, 20 Feb 2008 11:13:20 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m1KJDHDg009721; Wed, 20 Feb 2008 19:13:17 GMT Message-Id: <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> From: Casper.Dik@sun.com To: Nicolas Williams cc: James Carlson , John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <20080220191006.GD14350@Sun.COM> References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Feb 2008 20:13:16 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 264 >So, perhaps the OSR process needs some updates, and the SDF process >needs some updates to deal with (2), and the ARC and c-teams need to >enforce business decisions relating to (2). So the output of the OSR process should include the "Viral" Boolean? Casper From sac-owner Wed Feb 20 11:15:17 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJFHRi021250 for ; Wed, 20 Feb 2008 11:15:17 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KJFHPj000695 for ; Wed, 20 Feb 2008 11:15:17 -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 m1KJFCJF013656 for ; Wed, 20 Feb 2008 11:15:12 -0800 (PST) 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 <0JWJ00L01WGKJ000@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 11:15:12 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ0073FXH6UNH0@fe-sfbay-10.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 11:15:06 -0800 (PST) Date: Wed, 20 Feb 2008 11:15:04 -0800 From: John Plocher Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <18364.29441.424474.30500@gargle.gargle.HOWL> Sender: John.Plocher@sun.com To: James Carlson Cc: John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Message-id: <47BC7C38.9050207@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 735 James.D.Carlson wrote: > As I said, I don't see how it "aids" in any particular way. "it" == "the question about license type". I think (TM) that the only reason the license question is there is so that other consumers (i.e., not ARC) can see it and take action. Like it or not, the ARC process is probably the only place where a project that is going the automatic approval route is going to get *any* scrutiny... That said, I agree with you - the license question isn't really architectural, and should not be on a "potential architectural issues?" checklist. I'd rather use the few brain cells we have available to capture real architectural disconnects and not implementation or other people's process checkpoints. -John From sac-owner Wed Feb 20 11:19:42 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJJgIe021624 for ; Wed, 20 Feb 2008 11:19:42 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m1KJJgGN015366; Wed, 20 Feb 2008 13:19:42 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1KJJgpD015365; Wed, 20 Feb 2008 13:19:42 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 20 Feb 2008 13:19:42 -0600 From: Nicolas Williams To: Casper.Dik@sun.com Cc: James Carlson , John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Message-ID: <20080220191941.GE14350@Sun.COM> References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 523 On Wed, Feb 20, 2008 at 08:13:16PM +0100, Casper.Dik@Sun.COM wrote: > > >So, perhaps the OSR process needs some updates, and the SDF process > >needs some updates to deal with (2), and the ARC and c-teams need to > >enforce business decisions relating to (2). > > So the output of the OSR process should include the "Viral" Boolean? One output is: allowed/denied for requested use. Another is (particularly for blanket use requests): viral boolean, and if true, license(s) that importing projects must adopt. Nico -- From sac-owner Wed Feb 20 11:23:32 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.59] (may be forged)) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJNWQ4021788 for ; Wed, 20 Feb 2008 11:23:32 -0800 (PST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1KJNWnQ164333; Wed, 20 Feb 2008 11:23:32 -0800 (PST) Message-ID: <47BC7E34.30002@sun.com> Date: Wed, 20 Feb 2008 11:23:32 -0800 From: Scott Rotondo User-Agent: Thunderbird 2.0.0.6 (X11/20071119) MIME-Version: 1.0 To: John.Fischer@sun.com CC: John Plocher , sac-review@sac.sfbay.sun.com, james hughes , Kathy Jenks Subject: Re: LSARC/2008/061 - FOSS Check List References: <47BB173F.4030809@sun.com> <47BB1DAB.1060901@Sun.Com> <1203531573.63061.53.camel@sr1-umpk-34> In-Reply-To: <1203531573.63061.53.camel@sr1-umpk-34> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1578 John Fischer wrote: > John, > > How about adding a section about duplication of similar > core interfaces within Solaris? I would state that these > FOSS components would require further review (i.e., do > not fit with the Automatic approval). So something like: > > 3.3 Core Solaris Components > Do the components of this project compete with > or duplicate core Solaris components? > [ ] Yes > [ ] No I think this is a very valuable question to ask. As the recent libpolkit example showed, we need to think carefully about introducing parallel technologies that duplicate existing components, particularly when the result is doubling the amount of system administration required. > > If yes please check the appropriate core component > below: > [ ] Secure By Default > [ ] Authorizations > [ ] Audit > [ ] xVm > [ ] zones / Solaris Containers > [ ] PRM > [ ] RBAC > [ ] TX / Trusted Extensions > [ ] ZFS > [ ] SMF > [ ] FMA > [ ] IPv6 > [ ] IPsec > [ ] SCF > [ ] Other - specify below > > If any of the above are checked then further > ARC review is required. > However, I don't think this list is particularly helpful. Not everything listed here is a Solaris component, and the list is sure to change over time. Instead, I'd suggest a simple "If yes, please explain." Scott From sac-owner Wed Feb 20 11:25:00 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJOxTO021977 for ; Wed, 20 Feb 2008 11:24:59 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1KJOxLI011993; Wed, 20 Feb 2008 14:24:59 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1KJOxJM011990; Wed, 20 Feb 2008 14:24:59 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18364.32395.234264.302841@gargle.gargle.HOWL> Date: Wed, 20 Feb 2008 14:24:59 -0500 From: James Carlson To: Nicolas Williams Cc: Casper.Dik@sun.com, John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <20080220191006.GD14350@Sun.COM> References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1817 Nicolas Williams writes: > So, perhaps the OSR process needs some updates, and the SDF process > needs some updates to deal with (2), and the ARC and c-teams need to > enforce business decisions relating to (2). The ARC doesn't really have the ability to "enforce" anything. We review documentation. If it's enforcement we're after here, then that needs to rest with the C-team. If there's some defined way for us to perform some useful (and legally safe) service by our evaluation of licenses as one aspect of architectural dependency inspection, then, great, let's do that. I just don't see how that service exists or what that non-expert evaluation could possibly be. Requesting that project teams tell us that they've been through the required legal review process and (if they can't) telling them that they need to do this seems like a good checklist item, in as much as we do the same thing for UI and other reviews. I like Casper's suggestion to ask for the OSR number. (In fact, I'm not sure we're properly equipped to review *any* sort of legal issue. The fact that we're debating a checkbox item that appears to be based on a misunderstanding -- I don't think there's any legal precedent that establishes the concept of a "viral license" or provides any way to identify it correctly -- just underscores that point.) I understand that there's a generalized fear of a GPL bogeyman out there, and substantial misunderstanding of how those license terms may affect a project, but I fail to see how the ARC is helping out by providing amateur legal analysis as part of the mix. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Wed Feb 20 11:25:35 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJPZUM022054 for ; Wed, 20 Feb 2008 11:25:35 -0800 (PST) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1KJPYaX164588; Wed, 20 Feb 2008 11:25:35 -0800 (PST) Message-ID: <47BC7EAE.20607@sun.com> Date: Wed, 20 Feb 2008 11:25:34 -0800 From: Scott Rotondo User-Agent: Thunderbird 2.0.0.6 (X11/20071119) MIME-Version: 1.0 To: Casper.Dik@sun.com CC: Nicolas Williams , James Carlson , John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> In-Reply-To: <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 453 Casper.Dik@sun.com wrote: >> So, perhaps the OSR process needs some updates, and the SDF process >> needs some updates to deal with (2), and the ARC and c-teams need to >> enforce business decisions relating to (2). > > So the output of the OSR process should include the "Viral" Boolean? > > Casper > That seems like a practical solution. The only thing worse than ARC members acting as amateur lawyers is asking the submitter to do so. Scott From sac-owner Wed Feb 20 11:30:42 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJUgiN022403 for ; Wed, 20 Feb 2008 11:30:42 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KJUfwS013540 for ; Wed, 20 Feb 2008 11:30:41 -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 m1KJUf5s006151 for ; Wed, 20 Feb 2008 19:30:41 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 <0JWJ00G01XS1N400@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 12:30:41 -0700 (MST) Received: from 129.145.154.84 ([129.145.154.84]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ008OUY70D110@mail-amer.sun.com>; Wed, 20 Feb 2008 12:30:37 -0700 (MST) Date: Wed, 20 Feb 2008 11:30:36 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47BC7EAE.20607@sun.com> Sender: John.Fischer@sun.com To: Scott Rotondo Cc: John Fischer , Casper Dik , Nicolas Williams , James Carlson , Trevor Watson , sac-review@sac.sfbay.sun.com Reply-to: John.Fischer@sun.com Message-id: <1203535836.63061.67.camel@sr1-umpk-34> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: text/plain; charset=ASCII Content-transfer-encoding: 7BIT References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <47BC7EAE.20607@sun.com> Status: RO Content-Length: 747 Casper, James, Nico, Ok. Great. I'll modify the check list to ask for the OSR number. Although that is already in the integration criteria. So perhaps it is not needed at all. Thoughts? Thanks, John On Wed, 2008-02-20 at 11:25, Scott Rotondo wrote: > Casper.Dik@sun.com wrote: > >> So, perhaps the OSR process needs some updates, and the SDF process > >> needs some updates to deal with (2), and the ARC and c-teams need to > >> enforce business decisions relating to (2). > > > > So the output of the OSR process should include the "Viral" Boolean? > > > > Casper > > > > That seems like a practical solution. > > The only thing worse than ARC members acting as amateur lawyers is > asking the submitter to do so. > > Scott > From sac-owner Wed Feb 20 11:31:28 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJVSaN022588 for ; Wed, 20 Feb 2008 11:31:28 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m1KJVS3s015385; Wed, 20 Feb 2008 13:31:28 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1KJVSqO015384; Wed, 20 Feb 2008 13:31:28 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 20 Feb 2008 13:31:28 -0600 From: Nicolas Williams To: James Carlson Cc: Casper.Dik@sun.com, John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Message-ID: <20080220193127.GG14350@Sun.COM> References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <18364.32395.234264.302841@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18364.32395.234264.302841@gargle.gargle.HOWL> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2288 On Wed, Feb 20, 2008 at 02:24:59PM -0500, James Carlson wrote: > Nicolas Williams writes: > > So, perhaps the OSR process needs some updates, and the SDF process > > needs some updates to deal with (2), and the ARC and c-teams need to > > enforce business decisions relating to (2). > > The ARC doesn't really have the ability to "enforce" anything. We > review documentation. If it's enforcement we're after here, then that > needs to rest with the C-team. Fine, c-team then (I listed both, and expected your answer). > If there's some defined way for us to perform some useful (and legally > safe) service by our evaluation of licenses as one aspect of > architectural dependency inspection, then, great, let's do that. I > just don't see how that service exists or what that non-expert > evaluation could possibly be. The evaluation needs to be done by Legal, but a decision of whether to accept the consequences of using some library or other in some project is a business decision. ARC/c-team/whoever need to be a firewall that checks that this process has been followed. > Requesting that project teams tell us that they've been through the > required legal review process and (if they can't) telling them that > they need to do this seems like a good checklist item, in as much as > we do the same thing for UI and other reviews. I like Casper's > suggestion to ask for the OSR number. Sure, but you still need to look at the OSR and check that it was approved. My comment (1) was about the OSR process, and (2) was about the SDF process, where someone makes a business decision and someone else checks that the OSR process has been followed and the business decision made and effected. > I understand that there's a generalized fear of a GPL bogeyman out > there, and substantial misunderstanding of how those license terms may > affect a project, but I fail to see how the ARC is helping out by > providing amateur legal analysis as part of the mix. I'm not arguing that the ARC has any role here other than to ensure that other parts of the process have been followed, and if the c-team is more appropriate for that, then that's fine with me. I think the role of the ARC here is a rathole. The business aspects of dealing with legal issues is the key. Nico -- From sac-owner Wed Feb 20 11:34:37 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJYaxD022969 for ; Wed, 20 Feb 2008 11:34:37 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1KJYa85012076; Wed, 20 Feb 2008 14:34:36 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1KJYapR012073; Wed, 20 Feb 2008 14:34:36 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18364.32972.619727.387739@gargle.gargle.HOWL> Date: Wed, 20 Feb 2008 14:34:36 -0500 From: James Carlson To: Nicolas Williams Cc: Casper.Dik@sun.com, John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <20080220191941.GE14350@Sun.COM> References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1894 Nicolas Williams writes: > On Wed, Feb 20, 2008 at 08:13:16PM +0100, Casper.Dik@Sun.COM wrote: > > > > >So, perhaps the OSR process needs some updates, and the SDF process > > >needs some updates to deal with (2), and the ARC and c-teams need to > > >enforce business decisions relating to (2). > > > > So the output of the OSR process should include the "Viral" Boolean? > > One output is: allowed/denied for requested use. > > Another is (particularly for blanket use requests): viral boolean, and > if true, license(s) that importing projects must adopt. You're assuming (a) that there's some legal definition of a "viral" license, as opposed to one that merely has specific and perhaps onerous usage restrictions, (b) that there's either only one "kind" of virality or that there's some useful superset that can encompass such terms, (c) that project teams understand what usages fall under which terms of a given license, and (d) that at least some notable subset of us have the legal training and authority to make a proper evaluation of these things that would be valid for SMI, because ruling things both in and out of scope is hazardous. I'm pretty sure we fail on each of those tests. And you're assuming that these simple library licensing issues are the only legal issues or are somehow the most important ones that might dog a team. Not IPR assertions or patent claims. Not restrictions on documentation. Not trademarks or L&F. In short, if you need a lawyer, then get one. Relying on amateurs to do the job for you means you get what you pay for, and encoding this one strange belief about GPL into the checklist just doesn't make sense to me. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Wed Feb 20 11:35:32 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJZVbn023056 for ; Wed, 20 Feb 2008 11:35:31 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m1KJZVtu015401; Wed, 20 Feb 2008 13:35:31 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1KJZVO1015400; Wed, 20 Feb 2008 13:35:31 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 20 Feb 2008 13:35:31 -0600 From: Nicolas Williams To: John Fischer Cc: Scott Rotondo , Casper Dik , James Carlson , Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Message-ID: <20080220193531.GI14350@Sun.COM> References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <47BC7EAE.20607@sun.com> <1203535836.63061.67.camel@sr1-umpk-34> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1203535836.63061.67.camel@sr1-umpk-34> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 378 On Wed, Feb 20, 2008 at 11:30:36AM -0800, John Fischer wrote: > Ok. Great. I'll modify the check list to ask > for the OSR number. Although that is already > in the integration criteria. So perhaps it is > not needed at all. Thoughts? There's no need to do that though -- legal review is already covered in the c-team and RTI checklists (though this needs to be opened). From sac-owner Wed Feb 20 11:35:42 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJZgIP023058 for ; Wed, 20 Feb 2008 11:35:42 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1KJZfTf012084; Wed, 20 Feb 2008 14:35:41 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1KJZfRW012081; Wed, 20 Feb 2008 14:35:41 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18364.33037.914327.568279@gargle.gargle.HOWL> Date: Wed, 20 Feb 2008 14:35:41 -0500 From: James Carlson To: John.Fischer@sun.com Cc: Scott Rotondo , Casper Dik , Nicolas Williams , Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <1203535836.63061.67.camel@sr1-umpk-34> References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <47BC7EAE.20607@sun.com> <1203535836.63061.67.camel@sr1-umpk-34> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 663 John Fischer writes: > Casper, James, Nico, > > Ok. Great. I'll modify the check list to ask > for the OSR number. Although that is already > in the integration criteria. So perhaps it is > not needed at all. Thoughts? I don't think it's needed at all, but if the point of the checklist is to function as a "heads up" for project teams that may be less than fully clued into the development process, _perhaps_ it might be helpful. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Wed Feb 20 11:36:59 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJawpZ023081 for ; Wed, 20 Feb 2008 11:36:59 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m1KJawTG015408; Wed, 20 Feb 2008 13:36:58 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1KJawBE015407; Wed, 20 Feb 2008 13:36:58 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 20 Feb 2008 13:36:58 -0600 From: Nicolas Williams To: James Carlson Cc: Casper.Dik@sun.com, John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Message-ID: <20080220193658.GJ14350@Sun.COM> References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18364.32972.619727.387739@gargle.gargle.HOWL> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 925 On Wed, Feb 20, 2008 at 02:34:36PM -0500, James Carlson wrote: > Nicolas Williams writes: > > On Wed, Feb 20, 2008 at 08:13:16PM +0100, Casper.Dik@Sun.COM wrote: > > > > > > >So, perhaps the OSR process needs some updates, and the SDF process > > > >needs some updates to deal with (2), and the ARC and c-teams need to > > > >enforce business decisions relating to (2). > > > > > > So the output of the OSR process should include the "Viral" Boolean? > > > > One output is: allowed/denied for requested use. > > > > Another is (particularly for blanket use requests): viral boolean, and > > if true, license(s) that importing projects must adopt. > > You're assuming (a) that there's some legal definition of a "viral" What part of "if true, license(s) that importing projects must adopt" doesn't provide a definition suitable for *this* discussion? (As opposed to suitable material for an actual document.) Nico -- From sac-owner Wed Feb 20 11:48:05 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJm5Co024705 for ; Wed, 20 Feb 2008 11:48:05 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m1KJm599015435; Wed, 20 Feb 2008 13:48:05 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m1KJm5ug015434; Wed, 20 Feb 2008 13:48:05 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 20 Feb 2008 13:48:05 -0600 From: Nicolas Williams To: James Carlson Cc: Casper.Dik@sun.com, John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Message-ID: <20080220194804.GM14350@Sun.COM> References: <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080220193658.GJ14350@Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1374 On Wed, Feb 20, 2008 at 01:36:58PM -0600, Nicolas Williams wrote: > On Wed, Feb 20, 2008 at 02:34:36PM -0500, James Carlson wrote: > > Nicolas Williams writes: > > > On Wed, Feb 20, 2008 at 08:13:16PM +0100, Casper.Dik@Sun.COM wrote: > > > > > > > > >So, perhaps the OSR process needs some updates, and the SDF process > > > > >needs some updates to deal with (2), and the ARC and c-teams need to > > > > >enforce business decisions relating to (2). > > > > > > > > So the output of the OSR process should include the "Viral" Boolean? > > > > > > One output is: allowed/denied for requested use. > > > > > > Another is (particularly for blanket use requests): viral boolean, and > > > if true, license(s) that importing projects must adopt. > > > > You're assuming (a) that there's some legal definition of a "viral" > > What part of "if true, license(s) that importing projects must adopt" > doesn't provide a definition suitable for *this* discussion? (As > opposed to suitable material for an actual document.) Actually, that can be made better: "if true, these are the business-impacting consequences of importing these interfaces into this project". Still, this isn't architecture. The legal and business processes need to be documented, and the c-team (which already enforces this) needs to continue to enforce this. So I'm in violent agreement with James. From sac-owner Wed Feb 20 11:49:01 2008 Received: from dm-eng-02.sfbay.sun.com (dm-eng-02 [129.146.11.32]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJn16K024833 for ; Wed, 20 Feb 2008 11:49:01 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KJn1n2029572; Wed, 20 Feb 2008 11:49:01 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1KJnNYR019518; Wed, 20 Feb 2008 11:49:23 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1KJnN0R019517; Wed, 20 Feb 2008 11:49:23 -0800 (PST) Date: Wed, 20 Feb 2008 11:49:23 -0800 (PST) From: Gary Winiger Message-Id: <200802201949.m1KJnN0R019517@marduk.eng.sun.com> To: John.Fischer@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Status: RO Content-Length: 3937 > It was our belief that though other things are desirable from a product > perspective they would not cause us as a committee to derail a fast > track and have a full review. The check list reflects these beliefs. Agreed. What would the opinion say other than here's the beef. > 2.0 Project Summary > 2.2.3 Licensing > Is the license viral? GPL is an example of a viral license. > [ ] Yes (briefly explain below) > [ ] No Would it be better to ask: "Is the license one of the approved licenses -- see http:// ....." [ ] Yes [ ] No -- legal review needed. Missing seems to be * Release binding What is is the release binding? (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/) [ ] Major [ ] Minor [ ] Patch [ ] Unknown -- ARC review required > 3.0 Technical Description Missing seems to be * Services (see http://opensolaris.org/os/community/arc/policies/SMF-policy/) > 3.2 Security > 3.2.2 Authorization > (see http://opensolaris.org/os/community/arc/bestpractices/rbac-auths for details) This really isn't a good reference. This is a how to guide to add authorizations to Solaris consolidations. Perhaps an updated http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ is needed. Also if this is reference is felt to be what's indeed appropriate, http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ must also be included. > Are there any setuid/setgid privileged binaries in the project? > [ ] Yes IMO, yes requires review. I believe that's what PSARC/2000/488 Solaris/Linux Commands Compatibility intended to establish. > [ ] No - continue with next section > > 3.2.3 Auditing > (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details) > Does this component contain administrative or security enforcing software? > [ ] Yes Again, IMO requires review. Same precedent. > [ ] No - continue to next section > > Do the components create audit logs detailing what took place including what event > took place, who was involved, when the event took place? > [ ] Yes See PSARC/2003/397 in the audit policy, in place contract required before integration. Should be part of a review. > [ ] No - ARC review required Missing seem to be * Authentication (see http://opensolaris.org/os/community/arc/policies/PAM/) * Passwords (see http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ and http://opensolaris.org/os/community/arc/bestpractices/passwords-files/) > Appendix A - References And probably some additional ones as added to the main body. > Appendix B - Suggested case materials > 1. man pages > 2. SMF manifests > 3. links to contracts 4. Authorizations 5. Rights Profiles 6. Privileges > Appendix C - Definitions > 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 For these a cross reference to http://opensolaris.org/os/community/arc/policies/interface-taxonomy/ would seem useful. I presume this "check list" will end up as an OS.O ARC policy some where. Gary.. From sac-owner Wed Feb 20 11:51:14 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJpEt6025059 for ; Wed, 20 Feb 2008 11:51:14 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1KJpEan012191; Wed, 20 Feb 2008 14:51:14 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1KJpDu1012188; Wed, 20 Feb 2008 14:51:13 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18364.33969.799418.17604@gargle.gargle.HOWL> Date: Wed, 20 Feb 2008 14:51:13 -0500 From: James Carlson To: Nicolas Williams Cc: Casper.Dik@sun.com, John.Fischer@sun.com, Trevor Watson , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <20080220193658.GJ14350@Sun.COM> References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1403 Nicolas Williams writes: > On Wed, Feb 20, 2008 at 02:34:36PM -0500, James Carlson wrote: > > You're assuming (a) that there's some legal definition of a "viral" > > What part of "if true, license(s) that importing projects must adopt" > doesn't provide a definition suitable for *this* discussion? (As > opposed to suitable material for an actual document.) A classic example is a license that provides automatic and implicit patent grants when an implementation conforms to some standard, but requires explicit license negotiation with the patent holder for any other use. Or one that has one set of terms for software released under an OSI-approved license and another for all others. Or for software under particular terms. In other words, the terms of the license that are important to a given project may well depend on the nature of the project itself, or even the end user. I think we're deep-ending on this, but the point is that the orginal checklist question seems to have been formulated around GPLv2 as though that were "the special license" for which we need to provide specific safeguards, but I'm not so sure that apparent assumption is true in any sense. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Wed Feb 20 11:52:13 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJqDHX025099 for ; Wed, 20 Feb 2008 11:52:13 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KJqCJh044939 for ; Wed, 20 Feb 2008 11:52:12 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1KJqC9g006972 for ; Wed, 20 Feb 2008 19:52:12 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 <0JWJ00K01YV9X600@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 12:52:12 -0700 (MST) Received: from 129.145.154.84 ([129.145.154.84]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ00729Z6I0190@mail-amer.sun.com>; Wed, 20 Feb 2008 12:51:55 -0700 (MST) Date: Wed, 20 Feb 2008 11:51:54 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47BC714F.4000808@Sun.Com> Sender: John.Fischer@sun.com To: John Plocher Cc: John Fischer , Gary Winiger , sac-review@sac.sfbay.sun.com, James.Hughes@sun.com, Kathy.Jenks@sun.com Reply-to: John.Fischer@sun.com Message-id: <1203537114.63061.76.camel@sr1-umpk-34> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: text/plain Content-transfer-encoding: 7BIT References: <200802192327.m1JNRmg1017372@marduk.eng.sun.com> <1203531488.63061.50.camel@sr1-umpk-34> <47BC714F.4000808@Sun.Com> Status: RO Content-Length: 1314 John and Gary, Thanks for the information. Seeing Gary's email and question perhaps I need to define how I got to this list. First I went to the best practices and concentrated on the 3 areas of security, installation and share/sharable. I took the various policies and questionnaires and converted them into a check-list. Then I looked at various case history like the gnu install case and did the same. I think that Gary's list simply points people to relevant sac documentation where as this check list asks are you following the documentation in the area of security, installation and share/sharable. His list would be the Appendix A - References section of the check list. This check list helps project determine if they are following the policy and if not tells them that they need further review by a committee. Hopefully this helps, John On Wed, 2008-02-20 at 10:28, John Plocher wrote: > John Fischer wrote: > > Gary, > > > > I haven't seen it. John P needs to get this > > out soon > > Here is what Gary sent me... > > -John > > ______________________________________________________________________ > From: Gary Winiger > To: John.Plocher@Sun.COM > Cc: gww@marduk.eng.sun.com > Subject: Policy and Practices extracted > Date: Mon, 04 Feb 2008 17:09:30 -0800 > From sac-owner Wed Feb 20 11:59:01 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KJx1U7025858 for ; Wed, 20 Feb 2008 11:59:01 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KJx1GQ049615 for ; Wed, 20 Feb 2008 11:59:01 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1KJx1rC022283 for ; Wed, 20 Feb 2008 19:59:01 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 <0JWJ00K01YV9X600@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 12:59:01 -0700 (MST) Received: from 129.145.154.84 ([129.145.154.84]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ007NVZHY01D0@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 12:58:47 -0700 (MST) Date: Wed, 20 Feb 2008 11:58:46 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <20080220193658.GJ14350@Sun.COM> Sender: John.Fischer@sun.com To: Nicolas Williams Cc: John Fischer , James Carlson , Casper Dik , Trevor Watson , sac-review@sac.sfbay.sun.com Reply-to: John.Fischer@sun.com Message-id: <1203537526.63061.83.camel@sr1-umpk-34> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: text/plain; charset=ASCII Content-transfer-encoding: 7BIT References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> Status: RO Content-Length: 1827 All, I agree that we are not qualified to evaluate the license. I will be pulling it from the check-list unless someone speaks up in strong favor to keeping it in. My intent in adding it was to help raise the "hebe gebes" factor when including this type of license. Notice that the check list does not say ARC review required. Thus it was just to aid in the evaluation of what the project team was doing. The original questionnaire read: 2.2.3 Licensing Indicate the license for the component(s) [ ] GPL [ ] LGPL [ ] BSD [ ] MPL [ ] MIT [ ] CDDL [ ] Other - specify with link to license No mention of viral. It simply gave the indication of what was being included. Again, I will be removing it unless someone speaks up. Thanks, John On Wed, 2008-02-20 at 11:36, Nicolas Williams wrote: > On Wed, Feb 20, 2008 at 02:34:36PM -0500, James Carlson wrote: > > Nicolas Williams writes: > > > On Wed, Feb 20, 2008 at 08:13:16PM +0100, Casper.Dik@Sun.COM wrote: > > > > > > > > >So, perhaps the OSR process needs some updates, and the SDF process > > > > >needs some updates to deal with (2), and the ARC and c-teams need to > > > > >enforce business decisions relating to (2). > > > > > > > > So the output of the OSR process should include the "Viral" Boolean? > > > > > > One output is: allowed/denied for requested use. > > > > > > Another is (particularly for blanket use requests): viral boolean, and > > > if true, license(s) that importing projects must adopt. > > > > You're assuming (a) that there's some legal definition of a "viral" > > What part of "if true, license(s) that importing projects must adopt" > doesn't provide a definition suitable for *this* discussion? (As > opposed to suitable material for an actual document.) > > Nico > -- From sac-owner Wed Feb 20 12:01:15 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KK1FCo026022 for ; Wed, 20 Feb 2008 12:01:15 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KK1Fqh051627 for ; Wed, 20 Feb 2008 12:01:15 -0800 (PST) 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 m1KK1FXL002639 for ; Wed, 20 Feb 2008 20:01:15 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 <0JWJ00G01YRYGO00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 13:01:15 -0700 (MST) Received: from [192.168.1.64] ([189.137.195.67]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ00D62ZLP4860@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 13:01:02 -0700 (MST) Date: Wed, 20 Feb 2008 14:01:05 -0600 From: Brian Cameron Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47BBE3A2.9040500@Sun.COM> Sender: Brian.Cameron@sun.com To: Trevor Watson Cc: John.Fischer@sun.com, sac-review@sac.sfbay.sun.com Message-id: <47BC8701.4070109@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47BB173F.4030809@sun.com> <47BBE3A2.9040500@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 802 Trevor: One problem is that there are a *lot* of free and opensource licenses. It's hard to predict and list them all in checkbox form. I agree, it might be better to do away with a checkbox and have the user fill in a blank here. Brian > My only comment, for what it is worth, would in the section on licensing: > > When asking "Is the license viral?", I wonder if this is asking too much > of the submitter? What I mean is: how many submitters will actually be > qualified to make a judgement on whether or not a license is viral - > assuming it is not GPL? Is that not a quasi-legal definition, requiring > legal review? > > I guess from my perspective, I would prefer to see the submitter report > the license type - either as a tickbox or simply enter the type and URL. > > > Trev From sac-owner Wed Feb 20 12:02:27 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KK2QHC026168 for ; Wed, 20 Feb 2008 12:02:26 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KK2OJG052952 for ; Wed, 20 Feb 2008 12:02:24 -0800 (PST) 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 m1KK2OP5024104 for ; Wed, 20 Feb 2008 20:02:24 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 <0JWJ00H01ZAF3M00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 13:02:24 -0700 (MST) Received: from [192.168.1.64] ([189.137.195.67]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWJ00D3GZNQ4870@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 13:02:16 -0700 (MST) Date: Wed, 20 Feb 2008 14:02:18 -0600 From: Brian Cameron Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <1203530669.63061.32.camel@sr1-umpk-34> Sender: Brian.Cameron@sun.com To: John.Fischer@sun.com Cc: John Plocher , sac-review@sac.sfbay.sun.com, james hughes , Kathy Jenks Message-id: <47BC874A.2050208@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47BB173F.4030809@sun.com> <47BB1DAB.1060901@Sun.Com> <47BB45BB.7090001@sun.com> <1203530669.63061.32.camel@sr1-umpk-34> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 1726 J John: > As you know these types of questions came up during the > review in LSARC. What was stated then was that these types > of things were part of fit-n-finish and should be part of > a C-Team check list. These things would not cause the > FOSS project to need further review. I know, and sorry if I am being a nag, I just wanted to toss the idea out there again. While the answers to such questions might not trigger further review, it still seems it might be useful to include such questions just to make sure that people are thinking about these things. However, it others don't see the value, I won't press further. Brian > On Tue, 2008-02-19 at 13:10, Brian Cameron wrote: >> John: >> >> I think the following would also be useful to ask: >> >> - Does the project have appropriate manpages? >> - Does the project have API documentation installed to the system. >> If so, is the documentation referenced in the manpage? >> - Is the project I18N ready? >> - If the project has a GUI, is it accessible >> >> However, if these sorts of questions don't impact whether the >> project would be automatically accepted, I understand not asking >> them. It seems useful to ask, just to prompt people to think >> about such issues, and hopefully do things like a11y testing, >> though. >> >> Brian >> >> >>> A first pass list at the Solaris things that need to be chosen >>> over "linux versions" each and every time there is a conflict >>> would seem to be: >>> >>> Secure by default, auths, audit (already there) >>> xVm >>> zones / Solaris Containers >>> PRM >>> RBAC >>> TX >>> ZFS >>> SMF >>> FMA >>> IPv6 >>> IPsec >>> SCF >>> >>> I'm sure there are more. > From sac-owner Wed Feb 20 12:12:19 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KKCJex027843 for ; Wed, 20 Feb 2008 12:12:19 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KKCItH048311 for ; Wed, 20 Feb 2008 12:12:18 -0800 (PST) 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 m1KKCII6008159 for ; Wed, 20 Feb 2008 20:12:18 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 <0JWJ00H01ZAF3M00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 13:12:18 -0700 (MST) Received: from [192.168.1.64] ([189.137.195.67]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWK00DJU03P48D0@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 13:11:51 -0700 (MST) Date: Wed, 20 Feb 2008 14:11:53 -0600 From: Brian Cameron Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <1203537526.63061.83.camel@sr1-umpk-34> Sender: Brian.Cameron@sun.com To: John.Fischer@sun.com Cc: Nicolas Williams , James Carlson , Casper Dik , Trevor Watson , sac-review@sac.sfbay.sun.com Message-id: <47BC8989.4030504@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 428 John: > The original questionnaire read: > > 2.2.3 Licensing > Indicate the license for the component(s) > [ ] GPL > [ ] LGPL > [ ] BSD > [ ] MPL > [ ] MIT > [ ] CDDL > [ ] Other - specify with link to license Note, the original (version 1) MIT license is viral, while later revisions are not. Should probably list the viral vs. non-viral MIT licenses separately. Brian From sac-owner Wed Feb 20 13:00:45 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KL0jSh002443 for ; Wed, 20 Feb 2008 13:00:45 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KL0jXJ015176 for ; Wed, 20 Feb 2008 13:00:45 -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 m1KL0efd026960 for ; Wed, 20 Feb 2008 13:00:40 -0800 (PST) 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 <0JWK000012B80Z00@fe-sfbay-10.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 13:00:40 -0800 (PST) Received: from [129.146.108.211] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWK008BQ2CYWR60@fe-sfbay-10.sun.com> for sac-review@sac.sfbay.sun.com; Wed, 20 Feb 2008 13:00:35 -0800 (PST) Date: Wed, 20 Feb 2008 13:00:34 -0800 From: Alan Coopersmith Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <1203531573.63061.53.camel@sr1-umpk-34> Sender: Alan.Coopersmith@sun.com To: John.Fischer@sun.com Cc: John Plocher , sac-review@sac.sfbay.sun.com, james hughes , Kathy Jenks Message-id: <47BC94F2.4070709@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Enigmail-Version: 0.95.1 References: <47BB173F.4030809@sun.com> <47BB1DAB.1060901@Sun.Com> <1203531573.63061.53.camel@sr1-umpk-34> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 757 John Fischer wrote: > 3.3 Core Solaris Components > Do the components of this project compete with > or duplicate core Solaris components? > [ ] PRM You'd actually have to expand this acronym, since despite 5 years on the ARC, I had no idea what it was in John's list - it's not a well known Solaris technology. > [ ] SMF This isn't a complete/duplicate issue, but a use SMF vs. /etc/rc*.d scripts. > [ ] IPv6 > [ ] IPsec These are IETF standards, and in some areas we lag behind the open source there, so I'm not sure they make sense in a "compete or duplicate" list. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sac-owner Wed Feb 20 13:27:27 2008 Received: from zruty.sfbay.sun.com (zruty [129.146.168.40]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KLRRjt003242 for ; Wed, 20 Feb 2008 13:27:27 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1KLRQOv023365; Wed, 20 Feb 2008 13:27:26 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1KLRQg3023364; Wed, 20 Feb 2008 13:27:26 -0800 (PST) Date: Wed, 20 Feb 2008 13:27:26 -0800 From: Danek Duvall To: Gary Winiger Cc: John.Fischer@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Message-ID: <20080220212726.GN1369@zruty.sfbay.sun.com> References: <200802201949.m1KJnN0R019517@marduk.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200802201949.m1KJnN0R019517@marduk.eng.sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 350 On Wed, Feb 20, 2008 at 11:49:23AM -0800, Gary Winiger wrote: > > Appendix B - Suggested case materials > > 1. man pages > > 2. SMF manifests > > 3. links to contracts > > 4. Authorizations > 5. Rights Profiles > 6. Privileges I think these three are simply interfaces, rather than case materials / documentation, no? Danek From sac-owner Wed Feb 20 13:36:44 2008 Received: from dm-eng-02.sfbay.sun.com (dm-eng-02 [129.146.11.32]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1KLaiBo003765 for ; Wed, 20 Feb 2008 13:36:44 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1KLaiU9040051; Wed, 20 Feb 2008 13:36:44 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1KLb6k6019791; Wed, 20 Feb 2008 13:37:06 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1KLb6O2019790; Wed, 20 Feb 2008 13:37:06 -0800 (PST) Date: Wed, 20 Feb 2008 13:37:06 -0800 (PST) From: Gary Winiger Message-Id: <200802202137.m1KLb6O2019790@marduk.eng.sun.com> To: gww@eng.sun.com, danek.duvall@sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Cc: John.Fischer@sun.com, sac-review@sac.sfbay.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 228 > > 4. Authorizations > > 5. Rights Profiles > > 6. Privileges > > I think these three are simply interfaces, rather than case materials / > documentation, no? Ya. They just popped up in my mind here.... Gary.. From sac-owner Thu Feb 21 00:52:40 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1L8qeGw002209 for ; Thu, 21 Feb 2008 00:52:40 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1L8qeIM018966 for ; Thu, 21 Feb 2008 00:52:40 -0800 (PST) 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 m1L8qeOC013478 for ; Thu, 21 Feb 2008 08:52:40 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 <0JWK00J01ZAWBL00@mail-amer.sun.com> (original mail from James.Hughes@Sun.COM) for sac-review@sac.sfbay.sun.com; Thu, 21 Feb 2008 01:52:39 -0700 (MST) Received: from [10.0.111.4] (84-233-132-75.client.stsn.net [84.233.132.75]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWK00GJHZBN8SB0@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Thu, 21 Feb 2008 01:52:39 -0700 (MST) Date: Thu, 21 Feb 2008 08:52:34 +0000 From: james hughes Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47BC94F2.4070709@sun.com> Sender: James.Hughes@sun.com To: Alan Coopersmith Cc: james hughes , John.Fischer@sun.com, John Plocher , sac-review@sac.sfbay.sun.com, Kathy Jenks Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.919.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <47BB173F.4030809@sun.com> <47BB1DAB.1060901@Sun.Com> <1203531573.63061.53.camel@sr1-umpk-34> <47BC94F2.4070709@sun.com> Status: RO Content-Length: 2178 On Feb 20, 2008, at 9:00 PM, Alan Coopersmith wrote: > John Fischer wrote: >> 3.3 Core Solaris Components >> Do the components of this project compete with >> or duplicate core Solaris components? > >> [ ] PRM > > You'd actually have to expand this acronym, since despite 5 years > on the ARC, I had no idea what it was in John's list - it's not a > well known Solaris technology. Process Rights Management. And the other one SCF, is Solaris Crypto Framework. >> [ ] SMF > > This isn't a complete/duplicate issue, but a use SMF vs. /etc/rc*.d > scripts. There are two issues... First, as you said, use SMF. If you can not and you have to go back to using /etc/rc scripts, the project needs more scrutiny because doing it eliminates the value of SMF to customers since these packages are outside the normal way of doing things. I am not saying don't do it, I am saying we have to think first before going back to the old way of /etc/rc scripts for all open source packages. Second, think twice about adding software that manages the services that are still using /etc/rc. That would be bad. two separate frameworks for managing daemons that don't know about each other. >> [ ] IPv6 Adding software that does explicitly not support IPv6 can mean that Solaris may be deemed not to support IPv6, and this has implications for government sales. Projects like CIFS needed to get waivers since it did not support IPv6. The vast majority of packages that use networking will not have this issue. Again, this not a stopper, but a reason for scrutiny. >> [ ] IPsec > > These are IETF standards, and in some areas we lag behind the open > source there, so I'm not sure they make sense in a "compete or > duplicate" list. Do not add IPsec tools from the opensource because they will break our implementation. Specifically, our implementation (not the standards) are not typical and porting those tools needs additional scrutiny. Maybe this is not well named. > > -- > -Alan Coopersmith- alan.coopersmith@sun.com > Sun Microsystems, Inc. - X Window System Engineering > From Mark.Carlson@sun.com Wed Feb 27 16:00:11 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 m1S00AEh010427 for ; Wed, 27 Feb 2008 16:00:10 -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 m1S006Xr009362 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 28 Feb 2008 00:00:08 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 <0JWX00N219C61K00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 16:00:06 -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 <0JWX00JKX9C54TE0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 16:00:05 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1S0043M004189 for ; Thu, 28 Feb 2008 00:00:04 +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 <0JWX00E019314E00@mail-amer.sun.com> (original mail from Mark.Carlson@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 17:00:04 -0700 (MST) Received: from Macintosh-39.local ([71.237.94.98]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWX00G1Q9BT1DG0@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 16:59:54 -0700 (MST) Date: Wed, 27 Feb 2008 16:59:52 -0700 From: "Mark A. Carlson" Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <47B1C13B.2040705@sun.com> Sender: Mark.Carlson@sun.com To: John Fischer Cc: lsarc-ext@sun.com Message-id: <47C5F978.3010005@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47B1C13B.2040705@sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 301 Can we bless this at the next LSARC meeting? I have projects wanting me to be their fast track submitters... -- mark John Fischer wrote: > All, > > Based on feedback from Llyod and Brian I have updated the > check list. I have attached the modified version and a > diff file. > > Thanks, > > John From John.Fischer@sun.com Wed Feb 27 16:05:44 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 m1S05hGt010608 for ; Wed, 27 Feb 2008 16:05:44 -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 m1S05eeC011972 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 28 Feb 2008 00:05:43 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 <0JWX00A079LH8600@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 17:05:41 -0700 (MST) 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 <0JWX00CJM9LGWYE0@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 17:05:41 -0700 (MST) 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 m1S05ean007792 for ; Wed, 27 Feb 2008 16:05:40 -0800 (PST) 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 <0JWX00F019G1AZ00@fe-sfbay-10.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 16:05:40 -0800 (PST) Received: from [192.168.10.6] ([24.10.86.139]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JWX006EA9LGAD50@fe-sfbay-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 27 Feb 2008 16:05:40 -0800 (PST) Date: Wed, 27 Feb 2008 16:05:24 -0800 From: John Fischer Subject: Re: LSARC/2008/061 - Indiana check list In-reply-to: <47C5F978.3010005@sun.com> Sender: John.Fischer@sun.com To: "Mark A. Carlson" Cc: lsarc-ext@sun.com Reply-to: John.Fischer@sun.com Message-id: <47C5FAC4.9080905@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47B1C13B.2040705@sun.com> <47C5F978.3010005@sun.com> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) Status: RO Content-Length: 450 No. I need to modify it to include the feedback from sac-review. Then we can start using it. John Mark A. Carlson wrote: > Can we bless this at the next LSARC meeting? > > I have projects wanting me to be their fast track > submitters... > > -- mark > > John Fischer wrote: >> All, >> >> Based on feedback from Llyod and Brian I have updated the >> check list. I have attached the modified version and a >> diff file. >> >> Thanks, >> >> John From sac-owner Tue Apr 1 15:22:29 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m31MMTPb001909 for ; Tue, 1 Apr 2008 15:22:29 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m31MMT9b007193 for ; Tue, 1 Apr 2008 15:22:29 -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 m31MMTtg008622 for ; Tue, 1 Apr 2008 22:22:29 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 <0JYO006012GJYH00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Tue, 01 Apr 2008 16:22:29 -0600 (MDT) Received: from 129.145.154.70 ([129.145.154.70]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYO000T33HATB60@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Tue, 01 Apr 2008 16:22:23 -0600 (MDT) Date: Tue, 01 Apr 2008 15:22:22 -0700 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <1203537526.63061.83.camel@sr1-umpk-34> Sender: John.Fischer@Sun.COM To: sac-review@sac.sfbay.sun.com Reply-to: John.Fischer@Sun.COM Message-id: <1207088541.43474.22.camel@sr1-umpk-19> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: multipart/mixed; boundary="Boundary_(ID_gYosY5ne9SnKTgkFc+P+TA)" References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> Status: RO Content-Length: 32748 --Boundary_(ID_gYosY5ne9SnKTgkFc+P+TA) Content-type: text/plain; charset=ASCII Content-transfer-encoding: 7BIT All, I have folded in all feedback from the sac-review process and from Gary Winiger (thanks Gary). The main changes are: added Release Binding section removal of Licensing section added Services section added Authentication section added Passwords section added Core Solaris Components section The diff file is attached as is the updated check list. Please provide feedback by Tuesday April 8th, 2008. Thanks, John --Boundary_(ID_gYosY5ne9SnKTgkFc+P+TA) Content-type: text/plain; charset=ASCII; name=foss-check-list.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=foss-check-list.txt FCL--FOSS Check List 0. Introduction 0.1 Document History Version Author Changes 0.1 John Fischer Initial Draft 0.2 John Fischer Modified based upon feedback from ARC members 0.3 John Fischer Modified based upon feedback during committee review 0.4 John Fischer Modified based upon SAC review feedback 0.2 Purpose Architecture review at Sun has allowed the company to evolve our projects within multiple disjoint groups while still maintaining a cohesive product line. Each architecture review was conducted within Sun's control. With the advent of Free Open Source Software processes the control that Sun as a company can wield has been diminished. Now that Sun is moving to a more fluid delivery mechanism with project Indiana we need to evolve the architecture review process. This document is meant to aid in the architecture review process. Each new project must complete this check list to help ensure that the overall resulting product conforms to Sun product standards. If the project deviates from these standards further review would be necessary by an architecture review committee. 1.0 Project Information 1.1 Name of project/component 1.2 Author of document 2.0 Project Summary 2.1 Project Description 2.2 Release binding What is is the release binding? (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/) [ ] Major [ ] Minor [ ] Patch or Micro [ ] Unknown -- ARC review required 2.3 Originating Community 2.3.1 Community Name 2.3.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [ ] Contributor [ ] Monitoring Will the project team work with the upstream community to resolve architectural issues of interest to Sun? [ ] Yes [ ] No - briefly explain Will we or are we forking from the community? [ ] Yes - ARC review required prior to forking [ ] 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? [ ] Yes [ ] No - ARC review required Does this project install into /usr under [sbin|bin|lib|include|man|share]? [ ] Yes [ ] No or N/A Does this project install into /opt? [ ] Yes - explain below [ ] No or N/A Does this project install into a different directory structure? [ ] Yes - ARC review required [ ] 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 [ ] No If conflicts exist then will this project install under /usr/gnu? [ ] Yes [ ] No - ARC review required [ ] N/A Is this project installing into /usr/sfw? [ ] Yes - ARC review required [ ] No 3.1.1W Windows Installation - section only required for Windows Software (see http://sac.sfbay/WSARC/2002/494 for details) Does this project install software into a :\Program Files\Sun\ or :\Sun\ directory? [ ] Yes [ ] No - ARC review required Does the project use the Windows registry? [ ] Yes [ ] No - ARC review required Does the project use HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\ for the registry key? [ ] Yes [ ] No - ARC review required Is the project's stored location HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\\Path? [ ] Yes [ ] No - ARC review required 3.1.2 Share and Sharable Does the module include any components that are used or shared by other projects? [ ] Yes [ ] 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 Are 64-bit libraries being delivered? [ ] Yes [ ] No - ARC review required Are static versions of the library being delivered? [ ] Yes - ARC review required [ ] No 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 [ ] No Does the project integrate any new entries into /etc/inittab or /etc/inetd.conf? [ ] Yes - ARC review required [ ] No Does the project integrate any private non-public files into /etc/default or /etc/ configuration files? [ ] Yes - ARC review required [ ] No Does the service manifests method context grant rights above that of the noaccess user and basic privilege set? [ ] Yes - ARC review required [ ] No 3.4 Security 3.4.1 Secure By Default (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 [ ] N/A Are network services automatically enabled by the project during installation? [ ] Yes - ARC review required [ ] No [ ] N/A Are inbound network communications denied by default? [ ] Yes [ ] No - ARC review required [ ] N/A Is inbound data checked to prevent content-based attacks? [ ] Yes [ ] No - ARC review required [ ] N/A Is the outbound receiver authenticated? [ ] Yes [ ] No - ARC review required [ ] N/A Is the receiver authenticated prior to receiving any sensitive outbound communication? [ ] Yes [ ] No - ARC review required [ ] 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 [ ] 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 [ ] 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 [ ] 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 [ ] 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? [ ] Yes [ ] No - ARC review required Do network services for the project make decisions based upon user, host or service identities? [ ] Yes - explain below [ ] No [ ] N/A Do the components make use of secret information during authentication and/or authorization? [ ] Yes - explain below [ ] No [ ] N/A 3.5 Networking Do the components access the network? [ ] Yes [ ] No - continue to next section If yes do the components support IPv6? [ ] Yes [ ] 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 [ ] 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 --------------------------- ------------------- --------------------------- Wizzy Volatile version 0.65 Bang Project Private internally used by Wizzy for extra punch SUNWwizzy Uncommitted Wizzy's packaging 4.2 Imported Interfaces Interface Name Classification Comments --------------------------- -------------------- -------------------------- Slushy Volatile Cherry Flavor Committed Stingy Contracted Volatile see contract-4 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 --Boundary_(ID_gYosY5ne9SnKTgkFc+P+TA) Content-type: text/x-patch; charset=ASCII; name=foss-check-list.diff Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=foss-check-list.diff *** foss-check-list.txt Tue Apr 1 15:15:39 2008 --- /home/johnf/ARC/foss-check-list.txt Tue Apr 1 15:12:14 2008 *************** *** 6,11 **** --- 6,13 ---- 0.2 John Fischer Modified based upon feedback from ARC members 0.3 John Fischer Modified based upon feedback during committee review + 0.4 John Fischer Modified based upon SAC review feedback + 0.2 Purpose Architecture review at Sun has allowed the company to evolve our projects within multiple disjoint groups while still maintaining a cohesive product *************** *** 27,36 **** 2.0 Project Summary 2.1 Project Description ! 2.2 Originating Community ! 2.2.1 Community Name ! 2.2.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [ ] Contributor --- 29,46 ---- 2.0 Project Summary 2.1 Project Description ! 2.2 Release binding ! What is is the release binding? ! (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/) ! [ ] Major ! [ ] Minor ! [ ] Patch or Micro ! [ ] Unknown -- ARC review required ! ! 2.3 Originating Community ! 2.3.1 Community Name ! 2.3.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [ ] Contributor *************** *** 45,55 **** [ ] Yes - ARC review required prior to forking [ ] No - 2.2.3 Licensing - Is the license viral? GPL is an example of a viral license. - [ ] Yes (briefly explain below) - [ ] No - 3.0 Technical Description 3.1 Installation & Sharable 3.1.1S Solaris Installation - section only required for Solaris Software --- 55,60 ---- *************** *** 128,138 **** If yes are the newer versions replacing the existing versions? [ ] Yes [ ] No - ARC review required ! 3.2 Security ! 3.2.1 Secure By Default (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) Are network services enabled by default? [ ] Yes - ARC review required [ ] No --- 133,175 ---- If yes are the newer versions replacing the existing versions? [ ] Yes [ ] No - ARC review required + + 3.2 Libraries + Are 64-bit libraries being delivered? + [ ] Yes + [ ] No - ARC review required + + Are static versions of the library being delivered? + [ ] Yes - ARC review required + [ ] No ! 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 ! [ ] No ! ! Does the project integrate any new entries into /etc/inittab or ! /etc/inetd.conf? ! [ ] Yes - ARC review required ! [ ] No ! ! Does the project integrate any private non-public files into /etc/default ! or /etc/ configuration files? ! [ ] Yes - ARC review required ! [ ] No ! ! Does the service manifests method context grant rights above that ! of the noaccess user and basic privilege set? ! [ ] Yes - ARC review required ! [ ] No ! ! 3.4 Security ! 3.4.1 Secure By Default (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 *************** *** 163,190 **** [ ] No - ARC review required [ ] N/A ! 3.2.2 Authorization ! (see http://opensolaris.org/os/community/arc/bestpractices/rbac-auths for details) Are there any setuid/setgid privileged binaries in the project? ! [ ] Yes [ ] 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.2.3 Auditing (see http://opensolaris.org/os/community/arc/policies/audit-policy/ for details) Does this component contain administrative or security enforcing software? ! [ ] Yes [ ] No - continue to next section Do the components create audit logs detailing what took place including what event took place, who was involved, when the event took place? [ ] Yes [ ] No - ARC review required ! 3.2.4 General Security Questions (see http://opensolaris.org/os/community/arc/bestpractices/security-questions/ for details) Do the components use standard network protocols? [ ] Yes --- 200,272 ---- [ ] No - ARC review required [ ] 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 [ ] 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 [ ] 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 + [ ] 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 ! [ ] 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? [ ] Yes *************** *** 201,217 **** [ ] Yes - explain below [ ] No [ ] N/A ! ! 3.5 Libraries ! Are 64-bit libraries being delivered? ! [ ] Yes ! [ ] No - ARC review required ! ! Are static versions of the library being delivered? ! [ ] Yes - ARC review required ! [ ] No ! 4.0 Interfaces (see http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ for details) 4.1 Exported Interfaces --- 283,323 ---- [ ] Yes - explain below [ ] No [ ] N/A ! ! 3.5 Networking ! Do the components access the network? ! [ ] Yes ! [ ] No - continue to next section ! If yes do the components support IPv6? ! [ ] Yes ! [ ] 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 ! [ ] 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 *************** *** 243,265 **** 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. Security Audit Policy ! http://opensolaris.org/os/community/arc/policies/audit-policy/ ! 7. Security questionaire ! http://opensolaris.org/os/community/arc/bestpractices/security-questions/ ! 8. Interface Taxonomy ! http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ Appendix B - Suggested case materials 1. man pages 2. SMF manifests --- 349,386 ---- 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 *************** *** 266,271 **** --- 387,398 ---- 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 *************** *** 276,297 **** 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 --- 403,425 ---- 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 --Boundary_(ID_gYosY5ne9SnKTgkFc+P+TA)-- From sac-owner Tue Apr 1 16:43:56 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m31NhuYj005566 for ; Tue, 1 Apr 2008 16:43:56 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m31NhueO054855 for ; Tue, 1 Apr 2008 16:43:56 -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 m31NhpZE029517 for ; Tue, 1 Apr 2008 16:43:51 -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 <0JYO00A0174IKI00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for sac-review@sac.sfbay.sun.com; Tue, 01 Apr 2008 16:43:51 -0700 (PDT) Received: from wp668.local ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYO00BQW791O280@fe-sfbay-10.sun.com> for sac-review@sac.sfbay.sun.com; Tue, 01 Apr 2008 16:43:49 -0700 (PDT) Date: Tue, 01 Apr 2008 16:43:48 -0700 From: John Plocher Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <1207088541.43474.22.camel@sr1-umpk-19> Sender: John.Plocher@Sun.COM To: John.Fischer@Sun.COM Cc: sac-review@sac.sfbay.sun.com Message-id: <47F2C8B4.1060807@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 2198 John Fischer wrote: > ... On the whole, this looks good, but I have some Q's: general: Still sounds Sun/Solaris specific (and not Community/OpenSolaris...) section 2.4-ish - should we add something like the following to help determine "what repository" and "what consolidation" this project should be aimed at? The choices (in broad brush strokes) are An "experimental/wild-west" repo where anyone can upload packages, An "aggregated" repo that contains optional stuff that is not part of the WOS, and An "integrated" repo that values tight integration with the "Solaris way of life" over "just like Linux". All three of these repos will contain software that runs on OpenSolaris; the difference is the amount of integration and the specifics around Sun provided warranty support - none, some, lots. I expect an 80/20 or even 90/10 split for ARC reviewed FOSS stuff between aggregation and integration; I don't see any value in forcing ARC review for experimental stuff. We simply can't afford to spend the $lots$ it would take to tightly integrate *everything* from the FOSS world into Solaris. -John Suggestions: 2.4.1 In addition to a vast array of mostly-compatible things, Solaris provides a rich feature set that either does not exist on Linux or is implemented there in different (and potentially incompatible) ways. (examples: zfs, dtrace, rbac, security, ...[longer list?]...) What level of use/integration with these Solaris features does this project provide? A [ ] It provides an implementation of non-Solaris alternatives B [ ] It uses non-Solaris alternatives C [ ] When built for Solaris, it uses the Solaris style features 2.4.2 In a conceptual cross-project dependency graph that shows the interconnections and relationships between OpenSolaris WOS (i.e, the Core OS features), this project, and the set other projects and features provided with the OS, would you say this project: A [ ] is, or \_ intended to be a part of the core operating system such B [ ] is NOT / that other parts of the WOS may depend on this project? If you checked A or B in 2.4.1, or you checked B in 2.4.2, your project may not go into the "integrated repository". From sac-owner Tue Apr 1 19:28:36 2008 Received: from buye.red.iplanet.com (buye.red.iplanet.com [192.18.65.224]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m322SaWi009814 for ; Tue, 1 Apr 2008 19:28:36 -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 m322SaVl019999; Tue, 1 Apr 2008 19:28:36 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m322Sajl019998; Tue, 1 Apr 2008 19:28:36 -0700 (PDT) Date: Tue, 1 Apr 2008 19:28:36 -0700 From: Jyri Virkki To: John Fischer Cc: sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Message-ID: <20080402022836.GE13187@sun.com> References: <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1207088541.43474.22.camel@sr1-umpk-19> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 2579 John Fischer wrote: > > FCL--FOSS Check List I don't remember seeing (and I just skimmed the mail log and didn't find) a precise statement of when this is meant to be used. So I suggest adding such info to section 0.2 or elsewhere. (My guess is the intent is to have the project team only fill this in lieu of any case materials when filing these "quick approval" cases??? Are they going to file them as approved automatic? I'd really like to see some precise guidelines.) On a high level note, I see so many common "ARC review required" triggers than I'm wondering how many projects will really be able to take advantage of this checklist-based approval? (Personally I don't see a problem with components doing regular Fast Tracks since it has worked just fine so far, so I'm ok with that). But I wonder if we're spending much effort on something that won't get used much... oh well. > 2.3.2 Community Involvement > Indicate Sun's involvement in the community > [ ] Maintainer > [ ] Contributor > [ ] Monitoring This list is missing what's probably the most common role, which is "we contribute occasional patches but have no formal voice in the component's architecture". (The appendix definition here of "Contributor" seems more like what's usually called "Committer".) Why isn't there a "ARC review required" on the "Maintainer" line? If Sun is the "Maintainer" (basically primary owner from the appendix definition) then it is a Sun project, the kind which goes through regular ARC reviews. Or does this checklist open a loophole where any Sun project which is open source (such as all of OpenSolaris) can fill this checklist and skip ARC? Is this the conscious intent here? > 3.2 Libraries Looks like this section is about libraries which are public exported interfaces by this project. Calling that out will probably avoid some confusion. > 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 Since most project teams will look at this checklist as The Way To Avoid The Arc Overhead, the above text very strongly guides them towards marking everything Volatile. Is this truly what we want? (#insert usual note about how most of these FOSS interfaces are really more stable than Volatile but less than Uncommitted.) -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From sac-owner Tue Apr 1 19:35:51 2008 Received: from buye.red.iplanet.com (buye.red.iplanet.com [192.18.65.224]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m322ZppR009851 for ; Tue, 1 Apr 2008 19:35: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 m322ZpSN020010; Tue, 1 Apr 2008 19:35:51 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m322ZpKJ020009; Tue, 1 Apr 2008 19:35:51 -0700 (PDT) Date: Tue, 1 Apr 2008 19:35:51 -0700 From: Jyri Virkki To: John Plocher Cc: sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List Message-ID: <20080402023551.GF13187@sun.com> References: <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <47F2C8B4.1060807@Sun.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47F2C8B4.1060807@Sun.Com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 588 John Plocher wrote: > > section 2.4-ish - should we add something like the following to help > determine > "what repository" and "what consolidation" this project should be aimed at? > The choices (in broad brush strokes) are > > An "experimental/wild-west" ... > An "aggregated" ... > An "integrated" ... Since these repositories don't exist and haven't been defined yet, I'd -1 against baking in any such references to wishful things ;-) Once they exist (at least a committed plan), sure, add them to the checklist... -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From sac-owner Tue Apr 1 20:35:30 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m323ZU63011543 for ; Tue, 1 Apr 2008 20:35:30 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m323ZUWX011924 for ; Tue, 1 Apr 2008 20:35:30 -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 m323ZPVA000262 for ; Tue, 1 Apr 2008 20:35:25 -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 <0JYO00C01HYVPB00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for sac-review@sac.sfbay.sun.com; Tue, 01 Apr 2008 20:35:25 -0700 (PDT) Received: from wp668.local ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYO0081SHZ01G20@fe-sfbay-10.sun.com> for sac-review@sac.sfbay.sun.com; Tue, 01 Apr 2008 20:35:25 -0700 (PDT) Date: Tue, 01 Apr 2008 20:35:24 -0700 From: John Plocher Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <20080402023551.GF13187@sun.com> Sender: John.Plocher@Sun.COM To: Jyri Virkki Cc: sac-review@sac.sfbay.sun.com Message-id: <47F2FEFC.3060207@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <47F2C8B4.1060807@Sun.Com> <20080402023551.GF13187@sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 285 Jyri Virkki wrote: > Since these repositories don't exist and haven't been defined yet, Part of this exercise may very well be their definition and creation. "If you want to be able to behave like [proposal], then you must also provide [architecture to support proposal]" -John From sac-owner Wed Apr 2 16:19:29 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m32NJTxl024514 for ; Wed, 2 Apr 2008 16:19:29 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m32NJTUn362105; Wed, 2 Apr 2008 16:19:29 -0700 (PDT) Message-ID: <47F41481.9030509@sun.com> Date: Wed, 02 Apr 2008 16:19:29 -0700 From: Scott Rotondo User-Agent: Thunderbird 2.0.0.6 (X11/20071119) MIME-Version: 1.0 To: Jyri Virkki CC: John Fischer , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List References: <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <20080402022836.GE13187@sun.com> In-Reply-To: <20080402022836.GE13187@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1159 Jyri Virkki wrote: > If Sun is the "Maintainer" (basically primary owner from the appendix > definition) then it is a Sun project, the kind which goes through > regular ARC reviews. Or does this checklist open a loophole where any > Sun project which is open source (such as all of OpenSolaris) can fill > this checklist and skip ARC? Is this the conscious intent here? I strongly suggest that the process should be the same regardless of where the project team comes from. Usually that notion is interpreted to mean that we should avoid placing undue burdens on non-Sun contributors, but it is important not to overcorrect by creating extra work that only applies to Sun engineers. You really don't want Sun project teams to create external projects and bring their code in from outside just so they can avoid ARC review... We had this situation when ON was first open-sourced. We knew that most of the ONSC review process was irrelevant for non-Sun contributors. Instead of having different requirements for Sun project teams, we got rid of ONSC (for everyone) and incorporated the bits that were still relevant into the C-team review. Scott From sac-owner Thu Apr 3 11:33:51 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33IXpTe028096 for ; Thu, 3 Apr 2008 11:33:51 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m33IXo5g059602 for ; Thu, 3 Apr 2008 11:33:51 -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 m33IXo7u017198 for ; Thu, 3 Apr 2008 18:33:50 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 <0JYR00L01HX73X00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Thu, 03 Apr 2008 12:33:50 -0600 (MDT) Received: from 129.145.154.70 ([129.145.154.70]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYR00IJ4I8CON30@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Thu, 03 Apr 2008 12:33:49 -0600 (MDT) Date: Thu, 03 Apr 2008 11:33:48 -0700 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <20080402023551.GF13187@sun.com> Sender: John.Fischer@Sun.COM To: Jyri Virkki Cc: John Fischer , John Plocher , sac-review@sac.sfbay.sun.com Reply-to: John.Fischer@Sun.COM Message-id: <1207247627.43474.61.camel@sr1-umpk-19> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: text/plain; charset=ASCII Content-transfer-encoding: 7BIT References: <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <47F2C8B4.1060807@Sun.Com> <20080402023551.GF13187@sun.com> Status: RO Content-Length: 702 Jyri, I agree. +1. John On Tue, 2008-04-01 at 19:35, Jyri Virkki wrote: > John Plocher wrote: > > > > section 2.4-ish - should we add something like the following to help > > determine > > "what repository" and "what consolidation" this project should be aimed at? > > The choices (in broad brush strokes) are > > > > An "experimental/wild-west" ... > > An "aggregated" ... > > An "integrated" ... > > Since these repositories don't exist and haven't been defined yet, I'd -1 > against baking in any such references to wishful things ;-) > > Once they exist (at least a committed plan), sure, add them to the > checklist... > > -- > Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From sac-owner Thu Apr 3 11:45:47 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33Ijlom028272 for ; Thu, 3 Apr 2008 11:45:47 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m33IjknO048680 for ; Thu, 3 Apr 2008 11:45:46 -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 m33Ijk8C022376 for ; Thu, 3 Apr 2008 18:45:46 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 <0JYR00001I222N00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Thu, 03 Apr 2008 12:45:46 -0600 (MDT) Received: from 129.145.154.70 ([129.145.154.70]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYR008FUIS4LM00@mail-amer.sun.com> for sac-review@sac.sfbay.sun.com; Thu, 03 Apr 2008 12:45:41 -0600 (MDT) Date: Thu, 03 Apr 2008 11:45:40 -0700 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <20080402022836.GE13187@sun.com> Sender: John.Fischer@Sun.COM To: Jyri Virkki Cc: John Fischer , sac-review@sac.sfbay.sun.com Reply-to: John.Fischer@Sun.COM Message-id: <1207248339.43474.74.camel@sr1-umpk-19> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <20080402022836.GE13187@sun.com> Status: RO Content-Length: 3644 Jyri, See below. Thanks, John On Tue, 2008-04-01 at 19:28, Jyri Virkki wrote: > John Fischer wrote: > > > > FCL--FOSS Check List > > I don't remember seeing (and I just skimmed the mail log and didn't > find) a precise statement of when this is meant to be used. So I > suggest adding such info to section 0.2 or elsewhere. > > (My guess is the intent is to have the project team only fill this in > lieu of any case materials when filing these "quick approval" cases??? > Are they going to file them as approved automatic? I'd really like to > see some precise guidelines.) The intent is to fill this out and submit it as materials for an automatically approved case. If they fall out for any reason then it is at minimum a fast track. > > On a high level note, I see so many common "ARC review required" > triggers than I'm wondering how many projects will really be able to > take advantage of this checklist-based approval? (Personally I don't > see a problem with components doing regular Fast Tracks since it has > worked just fine so far, so I'm ok with that). But I wonder if we're > spending much effort on something that won't get used much... oh well. Originally this was much shorter. Since the inception of the check list it has evolved by committee design. > > 2.3.2 Community Involvement > > Indicate Sun's involvement in the community > > [ ] Maintainer > > [ ] Contributor > > [ ] Monitoring > > This list is missing what's probably the most common role, which is > "we contribute occasional patches but have no formal voice in the > component's architecture". > > (The appendix definition here of "Contributor" seems more like what's > usually called "Committer".) > > > Why isn't there a "ARC review required" on the "Maintainer" line? Good question. > If Sun is the "Maintainer" (basically primary owner from the appendix > definition) then it is a Sun project, the kind which goes through > regular ARC reviews. Or does this checklist open a loophole where any > Sun project which is open source (such as all of OpenSolaris) can fill > this checklist and skip ARC? Is this the conscious intent here? In the desktop C-team we have several people who are Maintainers of Open Source projects, for example, gdm. Although a Sun engineer is the maintainer Sun is actually not the originator but the Gnome community is the originator. For things that Sun is both the originator and maintainer then I think that further review is required. Does that sound reasonable? If so then another question would follow: If a Sun engineer is the maintainer is Sun also the originator of the project? [ ] Yes -- ARC review required [ ] No > > 3.2 Libraries > > Looks like this section is about libraries which are public exported > interfaces by this project. Calling that out will probably avoid some > confusion. > > > > 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 > > Since most project teams will look at this checklist as The Way To > Avoid The Arc Overhead, the above text very strongly guides them > towards marking everything Volatile. Is this truly what we want? Probably not. What do you suggest here? > (#insert usual note about how most of these FOSS interfaces are really > more stable than Volatile but less than Uncommitted.) > > > -- > Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From sac-owner Thu Apr 3 15:55:19 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33MtJWq005871 for ; Thu, 3 Apr 2008 15:55:19 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m33MtIT3509062; Thu, 3 Apr 2008 15:55:19 -0700 (PDT) Message-ID: <47F5604F.4040207@sun.com> Date: Thu, 03 Apr 2008 12:55:11 -1000 From: Joseph Kowalski User-Agent: Thunderbird 2.0.0.9 (X11/20080225) MIME-Version: 1.0 To: John Plocher CC: John.Fischer@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <47F2C8B4.1060807@Sun.Com> In-Reply-To: <47F2C8B4.1060807@Sun.Com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2653 I must be missing something. We only have one repository. Why are we pretending that we have multiple repositories? I don't thing we should postulate about the existence of repositories or their semantics until be have an approved project to create them. - jek3 John Plocher wrote: > John Fischer wrote: > > ... > > On the whole, this looks good, but I have some Q's: > > general: Still sounds Sun/Solaris specific (and not > Community/OpenSolaris...) > > section 2.4-ish - should we add something like the following to help > determine > "what repository" and "what consolidation" this project should be > aimed at? > The choices (in broad brush strokes) are > > An "experimental/wild-west" repo where anyone can upload packages, > > An "aggregated" repo that contains optional stuff that is not part > of the WOS, and > > An "integrated" repo that values tight integration with the > "Solaris way of life" over "just like Linux". > > All three of these repos will contain software that runs on OpenSolaris; > the difference is the amount of integration and the specifics around > Sun provided warranty support - none, some, lots. > > I expect an 80/20 or even 90/10 split for ARC reviewed FOSS stuff > between aggregation and integration; I don't see any value in forcing > ARC review for experimental stuff. We simply can't afford to spend > the $lots$ it would take to tightly integrate *everything* from the > FOSS world into Solaris. > > -John > > Suggestions: > > 2.4.1 > In addition to a vast array of mostly-compatible things, Solaris > provides a rich feature set that either does not exist on Linux > or is implemented there in different (and potentially incompatible) > ways. (examples: zfs, dtrace, rbac, security, ...[longer list?]...) > > What level of use/integration with these Solaris features does > this project provide? > > A [ ] It provides an implementation of non-Solaris alternatives > B [ ] It uses non-Solaris alternatives > C [ ] When built for Solaris, it uses the Solaris style features > > > 2.4.2 > In a conceptual cross-project dependency graph that shows the > interconnections > and relationships between OpenSolaris WOS (i.e, the Core OS features), > this > project, and the set other projects and features provided with the OS, > would you say this project: > > A [ ] is, or \_ intended to be a part of the core operating system > such > B [ ] is NOT / that other parts of the WOS may depend on this > project? > > > If you checked A or B in 2.4.1, or you checked B in 2.4.2, your > project may > not go into the "integrated repository". > > From sac-owner Thu Apr 3 16:29:56 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m33NTusX007804 for ; Thu, 3 Apr 2008 16:29:56 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m33NTuvv513340; Thu, 3 Apr 2008 16:29:56 -0700 (PDT) Message-ID: <47F56874.6030401@sun.com> Date: Thu, 03 Apr 2008 16:29:56 -0700 From: Scott Rotondo User-Agent: Thunderbird 2.0.0.6 (X11/20071119) MIME-Version: 1.0 To: John.Fischer@sun.com CC: Jyri Virkki , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List References: <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <20080402022836.GE13187@sun.com> <1207248339.43474.74.camel@sr1-umpk-19> In-Reply-To: <1207248339.43474.74.camel@sr1-umpk-19> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 807 John Fischer wrote: > In the desktop C-team we have several people who are Maintainers > of Open Source projects, for example, gdm. Although a Sun engineer > is the maintainer Sun is actually not the originator but the Gnome > community is the originator. For things that Sun is both the > originator and maintainer then I think that further review is > required. Does that sound reasonable? If so then another > question would follow: > > If a Sun engineer is the maintainer is Sun also the > originator of the project? > [ ] Yes -- ARC review required > [ ] No > Why would you want to require extra review when Sun is the originator, that you would not require for exactly the same software from outside? See my previous email about perverse incentives and unintended consequences. Scott From sac-owner Thu Apr 3 20:24:02 2008 Received: from zion.sfbay.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m343O2eR012737 for ; Thu, 3 Apr 2008 20:24:02 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m343O1wJ029543; Fri, 4 Apr 2008 03:24:01 GMT Message-ID: <47F59F51.4010706@Sun.COM> Date: Thu, 03 Apr 2008 20:24:01 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.9 (X11/20080201) MIME-Version: 1.0 To: Joseph Kowalski CC: John Plocher , John.Fischer@Sun.COM, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <47F2C8B4.1060807@Sun.Com> <47F5604F.4040207@sun.com> In-Reply-To: <47F5604F.4040207@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1476 Joseph Kowalski wrote: > I must be missing something. > > We only have one repository. Why are we pretending that we have > multiple repositories? > > I don't thing we should postulate about the existence of repositories or > their semantics until > be have an approved project to create them. > Let's imagine for a moment that we have the ability to _label_ software, somewhat similar to the use of the interface stability classifications that we've squirreled away in the man pages for our customer's bemusement. Let's further more imagine that a single piece of software could accept _multiple_ labels, describing various non-conflicting attributes of that software piece such as degree of support, responsible party, etc. What attributes should we have? What attributes would be mandatory? Who/how do the labels values get set? Such labels could be manifested in package attributes in a single repo, different repos, etc; these are implementation details that actually do not affect the generation of software that will be labeled, and are not really of architecture import. We need to move faster. Figuring out what we want to see from project teams (both inside and outside of Sun) so that they can move ahead more quickly seems to me to be the most important task at hand. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From sac-owner Thu Apr 3 20:43:08 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m343h80E012952 for ; Thu, 3 Apr 2008 20:43:08 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m343h8gJ038448 for ; Thu, 3 Apr 2008 20:43:08 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m343h3lH024877 for ; Thu, 3 Apr 2008 20:43:03 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYS003017L2Z300@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for sac-review@sac.sfbay.sun.com; Thu, 03 Apr 2008 20:43:03 -0700 (PDT) Received: from wp668.local ([208.74.177.212]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYS00FOT7NR9340@fe-sfbay-09.sun.com>; Thu, 03 Apr 2008 20:43:03 -0700 (PDT) Date: Thu, 03 Apr 2008 20:42:59 -0700 From: John Plocher Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47F5604F.4040207@sun.com> Sender: John.Plocher@Sun.COM To: Joseph Kowalski Cc: John.Fischer@Sun.COM, sac-review@sac.sfbay.sun.com Message-id: <47F5A3C3.7030204@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <47F2C8B4.1060807@Sun.Com> <47F5604F.4040207@sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 2593 Joseph Kowalski wrote: > I must be missing something. > > We only have one repository. Why are we pretending that we have > multiple repositories? > > I don't thing we should postulate about the existence of repositories or > their semantics until > be have an approved project to create them. You are right. We don't have a formal spec. We haven't reviewed anything. Hogan's Heros even gives us a great tag line to use: "I see NOTHING! I know NOTHING!" Only one problem. You weren't listening yesterday. Jonathan, Rich, Anil, Ian, Jeff, Bill, TimC, TimM [etc] have already set explicit strategic business directions that move us down the road of multiple repos (or at least one repo that has attribute tags sufficient for it to be abstracted as multiple logical repos). They even have names for them: Wild West (aka experimental, aka caviat emptor) Sun Supported (aka aggregated, aka SFW) "In the WOS" (aka integrated, aka Core) StephenH told us he is going down that road. He also told us he is being told by [some set of the above] that writing the ips/repo software and deploying it in working prototype form is more important than ARC reviews. We know this is coming. The company has already defacto "Committed" to doing this and rolling out it out in the next 1 to 7 months. We don't have the luxury of passively waiting six months to a year for someone to come tell us this via an ARC case. We on the ARCs have a chance to come up with new architectural mechanisms that can solve these problems and start positioning projects so that they fit well into this new world. Either that, or we can continue treating every wild west and aggregated-but-not-integrated project as if it was really intended to be integrated - and by doing so completely throw away every last shred of value that the ARCs are giving to the company. If we try to treat the next couple of dozen "drop yet another FOSS thing onto Solaris" projects as poorly as we treated star, pkcs and unison, we might as well shut down PSARC and go home because it would be cheaper for Sun. 15 senior engineers are on PSARC. 150 more follow along at home via the PSARC-interest and opensolaris-arc mailing lists. at 5 minutes per message "involvement", and ~450 messages from these cases, just the email from those cases wasted over 6,000 engineering hours. 3/4 of an engineer-year. We can't afford to do this again. Not with 25 more cases like this in the pipeline. Not with 15,000 more sitting out there in the Debian repository. As Bart said, we need to figure out how to move faster. -John From sac-owner Fri Apr 4 13:04:12 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34K4CAK007881 for ; Fri, 4 Apr 2008 13:04:12 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m34K4Bce633724; Fri, 4 Apr 2008 13:04:11 -0700 (PDT) Message-ID: <47F689B7.3010803@sun.com> Date: Fri, 04 Apr 2008 10:04:07 -1000 From: Joseph Kowalski User-Agent: Thunderbird 2.0.0.9 (X11/20080225) MIME-Version: 1.0 To: Bart Smaalders CC: John Plocher , John.Fischer@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <47F2C8B4.1060807@Sun.Com> <47F5604F.4040207@sun.com> <47F59F51.4010706@Sun.COM> In-Reply-To: <47F59F51.4010706@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2585 Bart Smaalders wrote: > Joseph Kowalski wrote: >> I must be missing something. >> >> We only have one repository. Why are we pretending that we have >> multiple repositories? >> >> I don't thing we should postulate about the existence of repositories >> or their semantics until >> be have an approved project to create them. >> > > Let's imagine for a moment that we have the ability to _label_ > software, somewhat similar to the use of the interface stability > classifications > that we've squirreled away in the man pages for our customer's > bemusement. Let's further more imagine that a single piece of > software could accept _multiple_ labels, describing various > non-conflicting attributes of that software piece such as > degree of support, responsible party, etc. > > What attributes should we have? > What attributes would be mandatory? > Who/how do the labels values get set? > > Such labels could be manifested in package attributes in > a single repo, different repos, etc; these are implementation > details that actually do not affect the generation of software > that will be labeled, and are not really of architecture import. > > We need to move faster. Figuring out what we want to see from > project teams (both inside and outside of Sun) so that they can move > ahead > more quickly seems to me to be the most important task at hand. > > - Bart I'm not sure how I should respond to this. As such, I'll respond to it in several orthogonal ways: 1) This is a reply to a posting of mine that we shouldn't enshrine proposed repositories before they are well defined. The response seems to go well beyond that. If you've read the thread, its not hard understand where Bart is coming from, but it leaves me more than a little lost as to how *I* should reply. Perhaps being more selective as to which posts are replied to or starting with "This thread ...." rather than "Joseph Kowalski wrote" might be be more clear. Maybe an addition to Ms. Manner's e-mail guide? (We all do this sometimes.) 2) There is some precedent about these new, proposed attributes. (See 2000/486, 2000/487, 2000/488) The very clear message was that Sun should *never* express an opinion about something they don't "own". In other words, "quality" can't be an attribute (or similar value judgments). The lawyers even chimed on on this, but it should be rather obvious. In the interest of brevity, I've omitted several other responses I considered. - jek3 From sac-owner Fri Apr 4 13:52:22 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34KqMj6008526 for ; Fri, 4 Apr 2008 13:52:22 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m34KqMfG640637; Fri, 4 Apr 2008 13:52:22 -0700 (PDT) Message-ID: <47F69502.10801@sun.com> Date: Fri, 04 Apr 2008 10:52:18 -1000 From: Joseph Kowalski User-Agent: Thunderbird 2.0.0.9 (X11/20080225) MIME-Version: 1.0 To: John Plocher CC: John.Fischer@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <47F2C8B4.1060807@Sun.Com> <47F5604F.4040207@sun.com> <47F5A3C3.7030204@Sun.Com> In-Reply-To: <47F5A3C3.7030204@Sun.Com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 4955 John Plocher wrote: > Joseph Kowalski wrote: >> I must be missing something. >> >> We only have one repository. Why are we pretending that we have >> multiple repositories? >> >> I don't thing we should postulate about the existence of repositories >> or their semantics until >> be have an approved project to create them. > > You are right. We don't have a formal spec. We haven't > reviewed anything. Hogan's Heros even gives us a great > tag line to use: "I see NOTHING! I know NOTHING!" Cute, but remember the second and third sentences above. > Only one problem. You weren't listening yesterday. I find that more than a little bit presumptuious and offensive, particularly from somebody who just exercised his options as a moderator on a related alias. > Jonathan, Rich, Anil, Ian, Jeff, Bill, TimC, TimM [etc] > have already set explicit strategic business directions > that move us down the road of multiple repos (or at least > one repo that has attribute tags sufficient for it to be > abstracted as multiple logical repos). They even have > names for them: > > Wild West (aka experimental, aka caviat emptor) > Sun Supported (aka aggregated, aka SFW) > "In the WOS" (aka integrated, aka Core) > > StephenH told us he is going down that road. > > He also told us he is being told by [some set of the > above] that writing the ips/repo software and deploying > it in working prototype form is more important than ARC > reviews. > > We know this is coming. The company has already defacto > "Committed" to doing this and rolling out it out in the > next 1 to 7 months. > > We don't have the luxury of passively waiting six months to > a year for someone to come tell us this via an ARC case. So, the ARC is going to violate its own rules and ship an unapproved project. I find that more than a little bit interesting. Just Wednesday I heard a strong response from the ARC about Indiana not having time to engage in review. > We on the ARCs have a chance to come up with new architectural > mechanisms that can solve these problems and start positioning > projects so that they fit well into this new world. No. SAC has this chance. (I think this is important - ARCs must be passive, SAC can be active.) SAC (perhaps that means "Plocher") should quickly provide a solid proposal and submit it to PSARC. Read what you wrote above,... "Wild West..". The executives are expressing a need for compartimalization. > Either that, or we can continue treating every wild west > and aggregated-but-not-integrated project as if it was > really intended to be integrated - and by doing so completely > throw away every last shred of value that the ARCs are giving > to the company. If we try to treat the next couple of d > "drop yet another FOSS thing onto Solaris" projects as poorly > as we treated star, pkcs and unison, we might as well shut > down PSARC and go home because it would be cheaper for Sun. I hear you (sorta). star? Didn't you moderate this because somebody wasn't working with the process? pkcs? (No comment - I didn't pay enough attention.) Unison? We treated Unison well in one sense, but it was a pioneer (hence the arrow sticking out of them). Yes, we need something better. My concern about repositories is that they are asprin (a great drug) but not a cure for cancer. Many seem to think that they are. Let's get something on the table we can actually critique, rather than responding to everyone's own fantasy. Uh, despite the pressure to act quickly, wouldn't this happening without the buy-in of an OpenSolaris community leave the non-Sun members feeling rather disenfranchized? It the speed worth this cost? > 15 senior engineers are on PSARC. 150 more follow along at > home via the PSARC-interest and opensolaris-arc mailing lists. > at 5 minutes per message "involvement", and ~450 messages from > these cases, just the email from those cases wasted over 6,000 > engineering hours. 3/4 of an engineer-year. We can't afford > to do this again. Not with 25 more cases like this in the > pipeline. Not with 15,000 more sitting out there in the Debian > repository. This is the attitude I see as "repositories are the cure for cancer". > As Bart said, we need to figure out how to move faster. Interesting attribution. When I read Bart's mail, my first response to "We need to move faster" was that this is just another way to say "I don't have time to hear your opinion". Fortunately, the sentences that followed in Bart's mail made it clear that this was just a rational plea to work this with urgency (and I actually agree with him - it needs attention). However, in this mail I can only read this as "I have my opinion, go away." Note your characterization: "You weren't listening yesterday." Please, it you take this to be your charter, please get the proposal in order and submit it as quickly as possible, The noise to ratio on this is rather high. - jek3 > > -John From sac-owner Fri Apr 4 14:43:29 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m34LhTP7010714 for ; Fri, 4 Apr 2008 14:43:29 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m34LhTpM013891 for ; Fri, 4 Apr 2008 14:43:29 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m34LhOdC007482 for ; Fri, 4 Apr 2008 14:43:24 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYT00101LH95Z00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for sac-review@sac.sfbay.sun.com; Fri, 04 Apr 2008 14:43:24 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYT0085CLOCCPG0@fe-sfbay-09.sun.com>; Fri, 04 Apr 2008 14:43:24 -0700 (PDT) Date: Fri, 04 Apr 2008 14:43:22 -0700 From: John Plocher Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47F689B7.3010803@sun.com> Sender: John.Plocher@Sun.COM To: Joseph Kowalski Cc: Bart Smaalders , John.Fischer@Sun.COM, sac-review@sac.sfbay.sun.com Message-id: <47F6A0FA.7000209@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <47F2C8B4.1060807@Sun.Com> <47F5604F.4040207@sun.com> <47F59F51.4010706@Sun.COM> <47F689B7.3010803@sun.com> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 2921 Joseph Kowalski and Bart Smaalders wrote: > ...elided... I think some clarity is coming out of this discussion. Clarity #1: Add to the Ms Manners list: "John shouldn't post late at night, because he tends to say stupid things". Sorry, Joe, my comment was uncalled for and out of line. Clarity #2: The problem we have right now is that we only have one bucket to classify things in, and that bucket has lots and lots of associated assumptions: It has a large list of big rules, It has long term enterprise stability expectations It costs a lot (ARC, code changes, ...) to belong to the club It has huge value etc We tend to call this bucket by quite a few names (the WOS, Nevada, Solaris, Supported,...), and, while most of those names are imprecise and can be misleading, we all know what we are talking about. Because of all those presumptions, putting new stuff in that bucket is hard, because once you allow something into the bucket that does not live up to those presumptions, the system starts to unravel. This is where we are stuck - AS-IS FOSS isn't a good fit for the bucket we have, and we aren't willing to spend the major$$$ to make it all fit. But we really need the stuff. Stalemate. We have a couple of taxonomies to help us classify things and characterize their behavior. I think we may need another one. Call it the "expectations taxonomy" for lack of a better name. It defines concepts like Full fledged integrated: "Solaris WOS and Big Rule compliance" Aggregated: "Simply aggregated together with the OS, but not intended to follow all the rules or be tightly integrated", CaveatEmptor: "Experimental and Prototype stuff with no expectations at all" This seems somewhat orthogonal to consolidations, the release taxonomy and the interface taxonomy, and may best be communicated through, as Bart suggests, packaging attributes. If a project was presented as star: the ultimate tar, SFW consolidation, Committed stability Minor binding (1st release) Aggregated-level expectations the project team, the ARC and users would all be able to figure out that it was OK that it didn't use SMF for config, audit for access logging, etc etc etc. It would also mean that the project could not regress existing "Integrated" functionality (such as rmt...) With this tool in our vocabulary, it would be easy for Bart and Stephen and Danek to devise a way to encode the info in their pkg(5) stuff so that admins and customers can take advantage of it. What would ARC review of Aggregated or CaveatEmptor stuff look like? TimM said: namespace registration (filesystem, network,...) and maybe very little else. That is probably OK - we need to reserve our energy for the half dozen things that really /need/ to be "Full fledged integrated"; spending them on experiments and prototypes is a waste. -John From sac-owner Sun Apr 6 07:10:25 2008 Received: from dm-uk-01.uk.sun.com (dm-uk-01.UK.Sun.COM [129.156.101.115]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m36EAOul019607 for ; Sun, 6 Apr 2008 07:10:25 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m36EALFT017983; Sun, 6 Apr 2008 15:10:21 +0100 (BST) Received: from aldebaran.UK.Sun.COM (aldebaran [129.156.173.71]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with SMTP id m36EALsM013357; Sun, 6 Apr 2008 15:10:21 +0100 (BST) Message-Id: <200804061410.m36EALsM013357@serinus.UK.Sun.COM> Date: Sun, 6 Apr 2008 15:10:21 +0100 (BST) From: George Shepherd Reply-To: George Shepherd Subject: Re: LSARC/2008/061 - FOSS Check List To: jek3@Sun.COM, John.Plocher@Sun.COM Cc: bart.smaalders@Sun.COM, John.Fischer@Sun.COM, sac-review@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: X7V70izcEiNYncu/UR3H0A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_82 SunOS 5.11 sun4u sparc Status: RO Content-Length: 3947 Hi John, Some random thoughts below. I feel this is starting to look like a solid basis to move toward one Sun repository from which.. 1/ Enterprise customers can obtain the core enterprise level operating system which meets their stability and due dilligence expectations, just as though they installed from media. 2/ The same customers, and folks who are less constrained by level of service agreements can grab SFW packages which are guaranteed to meet the requirements for aggregated software packages. 3/ Community and Sun folks can contribute FOSS to the distribution which is only accepted into the repository when clearly labled with the expectation that the package doesn't offer any level of assurance beyond the fact that it will be signed as coming from the official repository, (and therefore has not declared itself to be more trustworthy than it really is). The packaging system could announce the levels of expectation associated with any package you are about to install, and do so REALLY LOUDLY for any attempt to install wildass CaveatEmptor stuff. It also seems reasonable to allow system owners to tell IPS the type of system they will allow by default, ie "I have Enterprise level requirements" and either, (by a policy setting) have IPS refuse to install specified lower catagories, or be really verbose about doing so in email and logs. This also leads to the expectation that 3rd party repositries will grow up over time, which we declare by default have a level of trust below ours. Equally a customer should be able to declare a local intranet repository having a level of trust equal Sun's repository by virtue of a policy setting. -George *>We have a couple of taxonomies to help us classify things and *>characterize their behavior. I think we may need another one. *> *>Call it the "expectations taxonomy" for lack of a better name. *>It defines concepts like *> *> Full fledged integrated: "Solaris WOS and Big Rule *> compliance" *> *> Aggregated: "Simply aggregated together with the OS, *> but not intended to follow all the rules or be tightly *> integrated", *> *> CaveatEmptor: "Experimental and Prototype stuff with no *> expectations at all" *> *>This seems somewhat orthogonal to consolidations, the release *>taxonomy and the interface taxonomy, and may best be communicated *>through, as Bart suggests, packaging attributes. *> *>If a project was presented as *> *> star: the ultimate tar, *> SFW consolidation, *> Committed stability *> Minor binding (1st release) *> Aggregated-level expectations *> *>the project team, the ARC and users would all be able to figure out *>that it was OK that it didn't use SMF for config, audit for access *>logging, etc etc etc. It would also mean that the project could not *>regress existing "Integrated" functionality (such as rmt...) With *>this tool in our vocabulary, it would be easy for Bart and Stephen *>and Danek to devise a way to encode the info in their pkg(5) stuff *>so that admins and customers can take advantage of it. *> *>What would ARC review of Aggregated or CaveatEmptor stuff look like? *>TimM said: namespace registration (filesystem, network,...) and maybe *>very little else. *> *>That is probably OK - we need to reserve our energy for the half dozen *>things that really /need/ to be "Full fledged integrated"; spending them *>on experiments and prototypes is a waste. *> *> -John *> George Shepherd http://clem.uk/~georges/ ============================================================================== Solaris Revenue Product Engineering: | SUN Microsystems Core team -Internet | Guillemont Park Email: George.Shepherd@Sun.COM | Camberley GU17 9QG Disclaimer: Less is more, more or less | United Kingdom ============================================================================== From sac-owner Mon Apr 7 05:28:19 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37CSJcu014388 for ; Mon, 7 Apr 2008 05:28:19 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m37CSIaq000434; Mon, 7 Apr 2008 08:28:18 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m37CSI2T000431; Mon, 7 Apr 2008 08:28:18 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18426.4962.709829.357196@gargle.gargle.HOWL> Date: Mon, 7 Apr 2008 08:28:18 -0400 From: James Carlson To: George Shepherd Cc: jek3@sun.com, John.Plocher@sun.com, bart.smaalders@sun.com, John.Fischer@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <200804061410.m36EALsM013357@serinus.UK.Sun.COM> References: <200804061410.m36EALsM013357@serinus.UK.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 3215 George Shepherd writes: > I feel this is starting to look like a solid basis to move > toward one Sun repository from which.. I don't think there is (or has ever been) much controversy over the idea that those installing a system could pull packages from multiple repositories in order to construct a system that has the characteristics they want. That's been true for a _long_ time -- longer even than blastwave's been around. The controversy I've seen is in three areas: - Can users (other than those who install the system) have any control over the stability of the things they get? The combination of the serendipitous discovery case plus configuration by someone with package install privileges (an administrator of some sort) generally means "no." That's probably good on a PC, but not so good on a SunRay. - How can the ARC handle cross-repository dependencies? - How does this work over time? Don't things just fall into the Enterprise group over time? Those latter two are tough, and I don't see us as any closer to resolving them. Let's suppose that someone integrates a library (call it "libhal") into the Wild West repository. Another project ("Tamarack"), targeting the Enterprise repository, claims to be dependent on that library. What do we do? Do we use a contract? If so, then that removes the one key feature of that Wild West repository: it can no longer change whenever desired. It's now blocked by the requirements of the Enterprise set. It might not even be a pass-through anymore. Do we force the owner of libhal to move it to the Enterprise set? How can we do that? Isn't that a "business decision?" Do we tell Tamarack to ship its own stable copy of the library? What does having duplicate and possibly incompatible components do to the overall system? Do we stop Tamarack from using the library at all? In that case, the Wild West participants have "veto power" over other repositories. The key problem I see here is that the proponents of the Wild West repository imagine that it will be populated with all sorts of attractive "leaf" software -- stuff that uses what everyone else produces, but that is not itself depended upon by any other software. Since I've seen very little _useful_ software that remains that way over time, I think the real result is that new stuff initially gets tossed unexamined into the Wild West repository. It then soaks there until someone "important" starts depending on it, and then we move it -- unchanged and unreviewed -- into the Enterprise category because we "have to" and don't have the resources to do otherwise. The result over time is that the role and effectiveness of architectural review is significantly reduced. Heck, as an effective way of avoiding sometimes difficult ARC review, it'd be good for my own projects to take the Wild West route. Less work for me, and the managers get to say we shipped it early. What's not to love? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Mon Apr 7 06:34:37 2008 Received: from dm-uk-02.uk.sun.com (dm-uk-02.UK.Sun.COM [129.156.101.196]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37DYbKo016136 for ; Mon, 7 Apr 2008 06:34:37 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m37DYWRe026458; Mon, 7 Apr 2008 14:34:33 +0100 (BST) Received: from aldebaran.UK.Sun.COM (aldebaran [129.156.173.71]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with SMTP id m37DYI8M027169; Mon, 7 Apr 2008 14:34:32 +0100 (BST) Message-Id: <200804071334.m37DYI8M027169@serinus.UK.Sun.COM> Date: Mon, 7 Apr 2008 14:34:32 +0100 (BST) From: George Shepherd Reply-To: George Shepherd Subject: Re: LSARC/2008/061 - FOSS Check List To: George.Shepherd@sun.com, james.d.carlson@sun.com Cc: jek3@sun.com, John.Plocher@sun.com, bart.smaalders@sun.com, John.Fischer@sun.com, sac-review@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 3JsehwsUbCzbhpD/RYxjng== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_82 SunOS 5.11 sun4u sparc Status: RO Content-Length: 4640 *>The controversy I've seen is in three areas: *> *> - Can users (other than those who install the system) have any *> control over the stability of the things they get? The *> combination of the serendipitous discovery case plus configuration *> by someone with package install privileges (an administrator of *> some sort) generally means "no." That's probably good on a PC, *> but not so good on a SunRay. *> No, but we can either prevent or report the install based on policy. *>Let's suppose that someone integrates a library (call it "libhal") *>into the Wild West repository. Another project ("Tamarack"), *>targeting the Enterprise repository, claims to be dependent on that *>library. What do we do? *> Why might that occur ? 1/ Tamarac is an existing pkg tagged as Enterprise or whatever in the repository and depends on an existing copy of libhal already integrated. A Wild West version of libhal should not be installable unless it's libhal resides in a wild west path. 2/ Tamarac comes to the ARCs with a case which adds a dependency on a Wild West package. Such dependencies are inherently incorrect IMHO hence they either make a stable copy which then resides in a core path, or they work to make it meet ARC requirements and promote it. No package should be promoted without meeting relevant ARC requirements. So for that promotion case we revert to the situation we have today. Somebody inside sponsors a case to promote and works with the authors or feeds changes back to the relevant community. I believe you have concerns about ARC ability to override business cases trying to shunt this stuff in, perhaps reinforcement of the ARC control of this area is a necessary part of any change. What doesn't happen though is that the new Solaris users we want to come to us from other platforms, have to build everything for themselves in the meantime, because we lack what everyone else has; a vast repository of FOSS packages. Additionally the ARC doesn't need to scale to handle every FOSS request nor to compromise the the standards which apply to core software because the business case to have FOSS available for Indiana is so pressing. -George *> Do we use a contract? If so, then that removes the one key feature *> of that Wild West repository: it can no longer change whenever *> desired. It's now blocked by the requirements of the Enterprise *> set. It might not even be a pass-through anymore. *> *> Do we force the owner of libhal to move it to the Enterprise set? *> How can we do that? Isn't that a "business decision?" *> *> Do we tell Tamarack to ship its own stable copy of the library? *> What does having duplicate and possibly incompatible components do *> to the overall system? *> *> Do we stop Tamarack from using the library at all? In that case, *> the Wild West participants have "veto power" over other *> repositories. *> *>The key problem I see here is that the proponents of the Wild West *>repository imagine that it will be populated with all sorts of *>attractive "leaf" software -- stuff that uses what everyone else *>produces, but that is not itself depended upon by any other software. *> *>Since I've seen very little _useful_ software that remains that way *>over time, I think the real result is that new stuff initially gets *>tossed unexamined into the Wild West repository. It then soaks there *>until someone "important" starts depending on it, and then we move it *>-- unchanged and unreviewed -- into the Enterprise category because we *>"have to" and don't have the resources to do otherwise. The result *>over time is that the role and effectiveness of architectural review *>is significantly reduced. *> *>Heck, as an effective way of avoiding sometimes difficult ARC review, *>it'd be good for my own projects to take the Wild West route. Less *>work for me, and the managers get to say we shipped it early. What's *>not to love? *> *>-- *>James Carlson, Solaris Networking *>Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 *>MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 George Shepherd http://clem.uk/~georges/ ============================================================================== Solaris Revenue Product Engineering: | SUN Microsystems Core team -Internet | Guillemont Park Email: George.Shepherd@Sun.COM | Camberley GU17 9QG Disclaimer: Less is more, more or less | United Kingdom ============================================================================== From sac-owner Mon Apr 7 06:59:46 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37DxkMA016497 for ; Mon, 7 Apr 2008 06:59:46 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m37Dxkl6000905; Mon, 7 Apr 2008 09:59:46 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m37Dxkrw000902; Mon, 7 Apr 2008 09:59:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18426.10449.999684.505321@gargle.gargle.HOWL> Date: Mon, 7 Apr 2008 09:59:45 -0400 From: James Carlson To: George Shepherd Cc: jek3@sun.com, John.Plocher@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <200804071334.m37DYI8M027169@serinus.UK.Sun.COM> References: <200804071334.m37DYI8M027169@serinus.UK.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 3383 George Shepherd writes: > *>Let's suppose that someone integrates a library (call it "libhal") > *>into the Wild West repository. Another project ("Tamarack"), > *>targeting the Enterprise repository, claims to be dependent on that > *>library. What do we do? > *> > > Why might that occur ? > 1/ Tamarac is an existing pkg tagged as Enterprise or whatever in the > repository and depends on an existing copy of libhal already integrated. > A Wild West version of libhal should not be installable unless it's > libhal resides in a wild west path. That skips over the question of "serendipitous discovery." There shouldn't *be* any special "wild west path." If there is, then we fall into the trap you've outlined: What doesn't happen though is that the new Solaris users we want to come to us from other platforms, have to build everything for themselves in the meantime, because we lack what everyone else has; a vast repository of ... because they can't *find* the software installed in that ghetto, so, like /usr/sfw before it, the stuff we ship doesn't exist. Thus, having an integrated version of libhal *BLOCKS* the use of a Wild West respository entry for the same thing. If we even allow the creation of such a package (I suspect we should not), end users are on the hook to decide whether they want to have removable media support on their system *OR* the latest-n-greatest version of libhal -- but they cannot have both, because both would compete for precious /usr/lib real estate. These knock-on effects from interdependent projects (Tamarack and libhal-newest being mutually exclusive) are a big part of the reason we do ARC review, and we try to guide project teams to provide adequate stability. These projects are _not_ islands to themselves. (And the above is an easy case -- harder ones would be things like openssl.) > 2/ Tamarac comes to the ARCs with a case which adds a dependency on a > Wild West package. Such dependencies are inherently incorrect IMHO > hence they either make a stable copy which then resides in a core > path, or they work to make it meet ARC requirements and promote it. Not to pick on that one project team, but the general question here is whether: (a) the team is funded to promote all of the FOSS on which the team depends, or (b) we hold these Enterprise (likely mostly "internal") projects to a stricter ("unfair") standard than we hold all other bits being integrated into the Wild West, and just deny them. If we don't have at least one of those being true, we'll walk straight into yet more endless, nonconverging email threads about the ARC's "inability to understand" FOSS. > I believe you have concerns about ARC ability to override business > cases trying to shunt this stuff in, perhaps reinforcement of the ARC > control of this area is a necessary part of any change. Yes, that's part of the problem. We're creating a "don't care" way of designing new components -- one that will likely become the default and that the ARC will have no authority to control. We end up casting ourselves into the role of ruling an increasingly irrelevant part of the world. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Mon Apr 7 07:33:34 2008 Received: from dm-uk-01.uk.sun.com (dm-uk-01.UK.Sun.COM [129.156.101.115]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37EXXsa016889 for ; Mon, 7 Apr 2008 07:33:33 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m37EXTMa012959; Mon, 7 Apr 2008 15:33:29 +0100 (BST) Received: from aldebaran.UK.Sun.COM (aldebaran [129.156.173.71]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with SMTP id m37EXTcR028231; Mon, 7 Apr 2008 15:33:29 +0100 (BST) Message-Id: <200804071433.m37EXTcR028231@serinus.UK.Sun.COM> Date: Mon, 7 Apr 2008 15:33:29 +0100 (BST) From: George Shepherd Reply-To: George Shepherd Subject: Re: LSARC/2008/061 - FOSS Check List To: George.Shepherd@sun.com, james.d.carlson@sun.com Cc: jek3@sun.com, John.Plocher@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, sac-review@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6zpVJFAeg5Q1pRjkBEZlIw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_82 SunOS 5.11 sun4u sparc Status: RO Content-Length: 2583 *>> Why might that occur ? *>> 1/ Tamarac is an existing pkg tagged as Enterprise or whatever in the *>> repository and depends on an existing copy of libhal already integrated. *>> A Wild West version of libhal should not be installable unless it's *>> libhal resides in a wild west path. *> *>That skips over the question of "serendipitous discovery." There *>shouldn't *be* any special "wild west path." If there is, then we *>fall into the trap you've outlined: *> Hmm why should there not be paths other than those used to get at core components ? We have them already, usr/sfw/bin usr/sfw/lib. (And yes I note that you would prefer we didn't). I'm not at all sure that sets a trap for the installation of software although of course, as with usr/sfw it makes it possible for users to get the wrong stuff or miss stuff, if they order their paths poorly. At least it makes it possible to have wild west software and aggregated software in addition to core packages. *>Thus, having an integrated version of libhal *BLOCKS* the use of a *>Wild West respository entry for the same thing. If we even allow the *>creation of such a package (I suspect we should not), end users are on *>the hook to decide whether they want to have removable media support *>on their system *OR* the latest-n-greatest version of libhal -- but *>they cannot have both, because both would compete for precious *>/usr/lib real estate. *> Only if we assume you don't permit paths for aggregated and wild west pkgs to install seperately. Of course that doesn't help, as you note, the project that has it's own copy of a library from FOSS and wants to use a newer one. That has to go thru the proper process. Sun projects affecting the core should not be able to avoid the correct ARC process. *> whether *> *> (a) the team is funded to promote all of the FOSS on which the team *> depends, or *> *> (b) we hold these Enterprise (likely mostly "internal") projects to *> a stricter ("unfair") standard than we hold all other bits being *> integrated into the Wild West, and just deny them. *> Both. Being unfair is fair in this case, the playing field is not intended to be level, and that's OK as long as Enterprise projects and aggregated projects can't get away with wild west standards by going outside the process. So yes, we hold Enterprise level components to a higher standard, AND if an Enterprise project wants to use a specific piece of FOSS it needs to be ready to meet the standards and feed the changes back to the community, even if they are #ifdef Sun. -George From sac-owner Mon Apr 7 07:48:25 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37EmPFR016955 for ; Mon, 7 Apr 2008 07:48:25 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m37EmOLQ001023; Mon, 7 Apr 2008 10:48:24 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m37EmOBs001020; Mon, 7 Apr 2008 10:48:24 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18426.13368.717390.955642@gargle.gargle.HOWL> Date: Mon, 7 Apr 2008 10:48:24 -0400 From: James Carlson To: George Shepherd Cc: jek3@sun.com, John.Plocher@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <200804071433.m37EXTcR028231@serinus.UK.Sun.COM> References: <200804071433.m37EXTcR028231@serinus.UK.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 5011 George Shepherd writes: > > *>> Why might that occur ? > *>> 1/ Tamarac is an existing pkg tagged as Enterprise or whatever in the > *>> repository and depends on an existing copy of libhal already integrated. > *>> A Wild West version of libhal should not be installable unless it's > *>> libhal resides in a wild west path. > *> > *>That skips over the question of "serendipitous discovery." There > *>shouldn't *be* any special "wild west path." If there is, then we > *>fall into the trap you've outlined: > *> > > Hmm why should there not be paths other than those used to get at core > components ? We have them already, usr/sfw/bin usr/sfw/lib. (And yes > I note that you would prefer we didn't). See PSARC 2005/185. The problem with /usr/sfw (and the reason why we've been trying very hard to get rid of it for quite some time now) is that placing objects in a ghetto means that users *cannot* reasonably find them. It means that we deliver a bastardized user experience. Ordinary autoconf scripts will fail to locate the FOSS libraries we ship. Ordinary users with the default path won't locate the executables. > I'm not at all sure that sets a trap for the installation of software > although of course, as with usr/sfw it makes it possible for users to > get the wrong stuff or miss stuff, if they order their paths poorly. > At least it makes it possible to have wild west software and aggregated > software in addition to core packages. Doing so means winding back the clock on 2005/185. I'd be surprised -- shocked, really -- if that's where any of the rest of the Indiana folks really wanted to go. I'd thought they want us to be more like Linux, not less so, and wanted to avoid hacking up freeware to fit into non-standard directories. > *>Thus, having an integrated version of libhal *BLOCKS* the use of a > *>Wild West respository entry for the same thing. If we even allow the > *>creation of such a package (I suspect we should not), end users are on > *>the hook to decide whether they want to have removable media support > *>on their system *OR* the latest-n-greatest version of libhal -- but > *>they cannot have both, because both would compete for precious > *>/usr/lib real estate. > *> > Only if we assume you don't permit paths for aggregated and wild west pkgs > to install seperately. Exactly. (Actually, it's worse for libraries -- having duplicate libraries is generally a toxic situation no matter what the path might be. It's fairly trivial for programs to end up with multiple distinct versions of the same thing in a single address space due to dependencies, and the result is chaos. libresolv.so.[12] was the sobering experience here.) > Of course that doesn't help, as you note, the project that has it's own copy > of a library from FOSS and wants to use a newer one. That has to go thru > the proper process. > Sun projects affecting the core should not be able to avoid the correct > ARC process. I'm asserting that having copies is an architectural problem for the system. Besides the wasted space and additional burden for administrators who must apply patches to all copies, there's the ongoing risk of incompatibilities between the copies and competition for precious resources (such as names of configuration files in /etc). > *> whether > *> > *> (a) the team is funded to promote all of the FOSS on which the team > *> depends, or > *> > *> (b) we hold these Enterprise (likely mostly "internal") projects to > *> a stricter ("unfair") standard than we hold all other bits being > *> integrated into the Wild West, and just deny them. > *> > > Both. > Being unfair is fair in this case, the playing field is not intended to > be level, and that's OK as long as Enterprise projects and aggregated > projects can't get away with wild west standards by going outside the > process. > > So yes, we hold Enterprise level components to a higher standard, AND > if an Enterprise project wants to use a specific piece of FOSS it needs > to be ready to meet the standards and feed the changes back to the community, > even if they are #ifdef Sun. It sounds like an ideal situation, but one that I suspect is very hard to accomplish in practice. We will _at least_ need to establish some clear and well-understood rules for FOSS use. Management needs to understand that contributing to the Wild West repository over time leads to the tragedy of the commons: each individual project added there costs little and degrades the environment for Enterprise bits only a smidge, but over time, nobody is responsible for making sure the Enterprise parts are kept active and useful. Given the nature of the tragedy of the commons, though, I don't think the problem is avoidable -- once you've created a commons. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Mon Apr 7 08:12:38 2008 Received: from dm-uk-01.uk.sun.com (dm-uk-01.UK.Sun.COM [129.156.101.115]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37FCbLA018463 for ; Mon, 7 Apr 2008 08:12:38 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m37FCYEf024129; Mon, 7 Apr 2008 16:12:34 +0100 (BST) Received: from aldebaran.UK.Sun.COM (aldebaran [129.156.173.71]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with SMTP id m37FCYvW028920; Mon, 7 Apr 2008 16:12:34 +0100 (BST) Message-Id: <200804071512.m37FCYvW028920@serinus.UK.Sun.COM> Date: Mon, 7 Apr 2008 16:12:34 +0100 (BST) From: George Shepherd Reply-To: George Shepherd Subject: Re: LSARC/2008/061 - FOSS Check List To: George.Shepherd@sun.com, james.d.carlson@sun.com Cc: jek3@sun.com, John.Plocher@sun.com, Bart.Smaalders@sun.com, John.Fischer@sun.com, sac-review@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7KcTJl2Rp/C/B2OBZI5MTw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_82 SunOS 5.11 sun4u sparc Status: RO Content-Length: 704 *>Doing so means winding back the clock on 2005/185. I'd be surprised *>-- shocked, really -- if that's where any of the rest of the Indiana *>folks really wanted to go. *> *>I'd thought they want us to be more like Linux, not less so, and *>wanted to avoid hacking up freeware to fit into non-standard *>directories. *> Yes AFAICS the only way we can possibly BE Linux (alike in this area) is not to have any standards of stability at the core, everything can break in the next rev.. Very Linux like, and entirely why Linux is a problem for anyone who cares about stability. The only way I can see us having our cake and eating it too, is to have multiple paths for install of this stuff. -George From sac-owner Mon Apr 7 10:41:10 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37HfAHc022670 for ; Mon, 7 Apr 2008 10:41:10 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m37HfAKa027457 for ; Mon, 7 Apr 2008 10:41: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 m37Hf5C7006648 for ; Mon, 7 Apr 2008 10:41:05 -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 <0JYY00801S4OAZ00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for sac-review@sac.sfbay.sun.com; Mon, 07 Apr 2008 10:41:05 -0700 (PDT) Received: from wp668.local ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYY00IHSUG8MCC0@fe-sfbay-10.sun.com>; Mon, 07 Apr 2008 10:40:56 -0700 (PDT) Date: Mon, 07 Apr 2008 10:40:56 -0700 From: John Plocher Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <200804071512.m37FCYvW028920@serinus.UK.Sun.COM> Sender: John.Plocher@Sun.COM To: James.D.Carlson@Sun.COM Cc: George Shepherd , Bart.Smaalders@Sun.COM, sac-review@sac.sfbay.sun.com Message-id: <47FA5CA8.6010605@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200804071512.m37FCYvW028920@serinus.UK.Sun.COM> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 412 Jim Carlson wrote: >Doing so means winding back the clock on 2005/185. If we only have one copy, putting it in a ghetto is bad. If we have 2 copies, with the easily found one having the attributes of easy to find, updated religiously and having stable interfaces, and the other living in a ghetto, that may be OK. Especially if the admin can choose the ghetto: /opt/csw, /usr/local, etc etc etc. -John From sac-owner Mon Apr 7 11:08:02 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37I819M024039 for ; Mon, 7 Apr 2008 11:08:02 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m37I81mR001953; Mon, 7 Apr 2008 14:08:01 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m37I81kW001950; Mon, 7 Apr 2008 14:08:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18426.25345.563464.33920@gargle.gargle.HOWL> Date: Mon, 7 Apr 2008 14:08:01 -0400 From: James Carlson To: John Plocher Cc: George Shepherd , Bart.Smaalders@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <47FA5CA8.6010605@Sun.Com> References: <200804071512.m37FCYvW028920@serinus.UK.Sun.COM> <47FA5CA8.6010605@Sun.Com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2615 John Plocher writes: > Jim Carlson wrote: > >Doing so means winding back the clock on 2005/185. > > If we only have one copy, putting it in a ghetto is bad. > > If we have 2 copies, with the easily found one having the attributes > of easy to find, updated religiously and having stable interfaces, > and the other living in a ghetto, that may be OK. If we have one that's updated religiously and also has stable interfaces, I'd argue that we don't really need any others. That sounds like a pretty good one for all. :-/ Presumably, the question is about ones that *aren't* updated so often: the old "staleware from Sun" versus "freshbits from da net" problem. Neither satisfies all users, and thus both are likely desired. And (as I described in my previous message, but not quoted above) the problem really does get worse when those bits compete for exclusive use of precious real estate. That includes symbol names inside an address space (think: libresolv.so.1 versus libresolv.so.2 fiasco), well-known configuration files, TCP/IP port numbers, RPC program numbers, and probably other bits. It's just too facile to say that more is better. Or that we can even handle the situation in any way that's more elegant than the current blob-on-the-side approach used for those existing non-WOS repositories. > Especially if the admin can choose the ghetto: /opt/csw, /usr/local, > etc etc etc. I'm not quite sure what you're saying here. Allowing the admin to design the file system layout on the fly potentially makes the situation much worse. How does anyone write software where the dependent components can be "anywhere?" We'll need some special infrastructure for that. "Hi, I'm a script, and I'd like the best 'diff' utility you have. Not necessarily the newest one, but the one with the fewest bugs. And some good performance. Not sure if I care if it's from GNU. What do you have in a path like that?" Otherwise, if what you're suggesting is that the administrator can install bits that the -designer- of those bits has placed into a ghetto, then we're back a square one for 2005/185 serendipitous discovery. Not everyone will know that on Solaris, unlike Linux, you have to dig into /opt/csw/lib to get the "best" version of a library (and, if you do that, you're on your own for 64-bit link paths; sorry about that). I don't think there's a free lunch here. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Mon Apr 7 11:10:02 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37IA1ff024059 for ; Mon, 7 Apr 2008 11:10:01 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m37IA1tK047544 for ; Mon, 7 Apr 2008 11:10:01 -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 m37I9ufD028749 for ; Mon, 7 Apr 2008 11:09:56 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYY00G01VFA5P00@fe-sfbay-09.sun.com> (original mail from Terrence.Miller@Sun.COM) for sac-review@sac.sfbay.sun.com; Mon, 07 Apr 2008 11:09:56 -0700 (PDT) Received: from [129.146.86.55] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYY0083PVSIIME0@fe-sfbay-09.sun.com>; Mon, 07 Apr 2008 11:09:54 -0700 (PDT) Date: Mon, 07 Apr 2008 11:09:54 -0700 From: Terrence Miller Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47F59F51.4010706@Sun.COM> Sender: Terrence.Miller@Sun.COM To: Bart Smaalders Cc: Joseph Kowalski , John Plocher , John.Fischer@Sun.COM, sac-review@sac.sfbay.sun.com Reply-to: Terrence.Miller@Sun.COM Message-id: <47FA6372.9010701@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_WFAeTBKYVOyzdb68nNjIog)" References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <47F2C8B4.1060807@Sun.Com> <47F5604F.4040207@sun.com> <47F59F51.4010706@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2281 This is a multi-part message in MIME format. --Boundary_(ID_WFAeTBKYVOyzdb68nNjIog) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT The ability to label software mentioned below translates (IMO)into making the binary objects we distribute be self-identifying. Once you can determine the exact version of an object by looking at the object the rest is database exercise. Bart Smaalders wrote: > Joseph Kowalski wrote: >> I must be missing something. >> >> We only have one repository. Why are we pretending that we have >> multiple repositories? >> >> I don't thing we should postulate about the existence of repositories >> or their semantics until >> be have an approved project to create them. >> > > Let's imagine for a moment that we have the ability to _label_ > software, somewhat similar to the use of the interface stability > classifications > that we've squirreled away in the man pages for our customer's > bemusement. Let's further more imagine that a single piece of > software could accept _multiple_ labels, describing various > non-conflicting attributes of that software piece such as > degree of support, responsible party, etc. > > What attributes should we have? > What attributes would be mandatory? > Who/how do the labels values get set? > > Such labels could be manifested in package attributes in > a single repo, different repos, etc; these are implementation > details that actually do not affect the generation of software > that will be labeled, and are not really of architecture import. > > We need to move faster. Figuring out what we want to see from > project teams (both inside and outside of Sun) so that they can move ahead > more quickly seems to me to be the most important task at hand. > > - Bart > > > > > > > > > --Boundary_(ID_WFAeTBKYVOyzdb68nNjIog) Content-type: text/x-vcard; name=Terrence.Miller.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Terrence.Miller.vcf begin:vcard fn:Terrence Miller n:Miller;Terrence adr:16 Network Circle;;UMPK-303;Menlo Park,;CA;94025;USA email;internet:terrence.miller@sun.com tel;work:650-786-9192 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_WFAeTBKYVOyzdb68nNjIog)-- From sac-owner Mon Apr 7 11:22:00 2008 Received: from zion.sfbay.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37IM05c024599 for ; Mon, 7 Apr 2008 11:22:00 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m37IM0XC001350; Mon, 7 Apr 2008 18:22:00 GMT Message-ID: <47FA6648.2000204@Sun.COM> Date: Mon, 07 Apr 2008 11:22:00 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.9 (X11/20080201) MIME-Version: 1.0 To: Terrence.Miller@Sun.COM CC: Joseph Kowalski , John Plocher , John.Fischer@Sun.COM, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List References: <47BBE3A2.9040500@Sun.COM> <1203530586.63061.29.camel@sr1-umpk-34> <18364.28413.813526.209800@gargle.gargle.HOWL> <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <47F2C8B4.1060807@Sun.Com> <47F5604F.4040207@sun.com> <47F59F51.4010706@Sun.COM> <47FA6372.9010701@Sun.COM> In-Reply-To: <47FA6372.9010701@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 970 Terrence Miller wrote: > The ability to label software mentioned below translates (IMO)into > making the binary objects we distribute be self-identifying. Once you > can determine the exact version of an object by looking at the object > the rest is database exercise. From indiana preview2 (my desktop): : barts@cyber[4]; digest -a sha1 /usr/bin/ls 48c55da1e6ba9d128a44027053f4ec551c37998b : barts@cyber[5]; pkg search 48c55da1e6ba9d128a44027053f4ec551c37998b content pkg:/SUNWcs@0.5.11,5.11-0.79:20080205T152811Z : barts@cyber[6]; pkg info pkg:/SUNWcs@0.5.11,5.11-0.79:20080205T152811Z Name: SUNWcs FMRI: pkg://opensolaris.org/SUNWcs@0.5.11,5.11-0.79:20080205T152811Z Version: 0.5.11 Branch: 0.79 Packaging Date: 2008-02-05 15:28:11 Size: 20613480 Summary: Core Solaris, (Usr) : barts@cyber[7]; -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From sac-owner Mon Apr 7 11:23:31 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37INVmd024634 for ; Mon, 7 Apr 2008 11:23:31 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m37INVjn056879 for ; Mon, 7 Apr 2008 11:23:31 -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 m37INQKE000654 for ; Mon, 7 Apr 2008 11:23:26 -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 <0JYY00201VZVKD00@fe-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM) for sac-review@sac.sfbay.sun.com; Mon, 07 Apr 2008 11:23:26 -0700 (PDT) Received: from wp668.local ([208.74.177.212]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYY00JRMWF2S7E0@fe-sfbay-10.sun.com>; Mon, 07 Apr 2008 11:23:26 -0700 (PDT) Date: Mon, 07 Apr 2008 11:23:25 -0700 From: John Plocher Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <18426.25345.563464.33920@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: George Shepherd , Bart.Smaalders@Sun.COM, sac-review@sac.sfbay.sun.com Message-id: <47FA669D.9070507@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200804071512.m37FCYvW028920@serinus.UK.Sun.COM> <47FA5CA8.6010605@Sun.Com> <18426.25345.563464.33920@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 855 James Carlson wrote: > Allowing the admin to design the file system layout on the fly > potentially makes the situation much worse. How does anyone write > software where the dependent components can be "anywhere?" The user who is installing the stuff there in the first place gets to put it where they wish, and then they go and write code that uses it. Note I am focusing on wild-west stuff here. Maybe that place is actually in $HOME. > "Hi, I'm a script, and I'd like the best 'diff' utility you have. Not > necessarily the newest one, but the one with the fewest bugs. And > some good performance. Not sure if I care if it's from GNU. What do > you have in a path like that?" Not the problem I'm trying to solve here. > I don't think there's a free lunch here. Nope, and the more I look at the menu, the less hungry I get... -John From sac-owner Mon Apr 7 11:37:04 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37Ib4xO024942 for ; Mon, 7 Apr 2008 11:37:04 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m37Ib4sH002200; Mon, 7 Apr 2008 14:37:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m37Ib3iq002197; Mon, 7 Apr 2008 14:37:03 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18426.27087.977181.617481@gargle.gargle.HOWL> Date: Mon, 7 Apr 2008 14:37:03 -0400 From: James Carlson To: John Plocher Cc: George Shepherd , bart.smaalders@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <47FA669D.9070507@Sun.Com> References: <200804071512.m37FCYvW028920@serinus.UK.Sun.COM> <47FA5CA8.6010605@Sun.Com> <18426.25345.563464.33920@gargle.gargle.HOWL> <47FA669D.9070507@Sun.Com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1075 John Plocher writes: > James Carlson wrote: > > Allowing the admin to design the file system layout on the fly > > potentially makes the situation much worse. How does anyone write > > software where the dependent components can be "anywhere?" > > The user who is installing the stuff there in the first place gets > to put it where they wish, and then they go and write code that uses it. > > Note I am focusing on wild-west stuff here. Maybe that place is actually > in $HOME. That opens the exciting possibility that no package within the Wild West repository can depend on any other package within Wild West. It's actually _worse_ in that respect than the existing solutions. At least for Companion CD, Sunfreeware, and Blastwave, they each install in a fairly well-known and fixed ghetto, and can thus can (and do) depend on each other. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Mon Apr 7 11:57:45 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37IvjBf025712 for ; Mon, 7 Apr 2008 11:57:45 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m37IviaH051391 for ; Mon, 7 Apr 2008 11:57:45 -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 m37IvdRd005047 for ; Mon, 7 Apr 2008 11:57:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYY00801XX4L100@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for sac-review@sac.sfbay.sun.com; Mon, 07 Apr 2008 11:57:39 -0700 (PDT) Received: from wp668.local ([208.74.177.212]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYY00FO0XZQ0L10@fe-sfbay-09.sun.com>; Mon, 07 Apr 2008 11:57:28 -0700 (PDT) Date: Mon, 07 Apr 2008 11:57:26 -0700 From: John Plocher Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <18426.27087.977181.617481@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: George Shepherd , sac-review@sac.sfbay.sun.com Message-id: <47FA6E96.6040700@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200804071512.m37FCYvW028920@serinus.UK.Sun.COM> <47FA5CA8.6010605@Sun.Com> <18426.25345.563464.33920@gargle.gargle.HOWL> <47FA669D.9070507@Sun.Com> <18426.27087.977181.617481@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 1191 James Carlson wrote: > ...dependencies... I think there are some big rules here as well as small ones: Big rule: dependencies can only be made on things with equal or greater "expectation taxonomy" levels. Given the three buckets: Integrated, Aggregated and WildWest, I can not depend on A or W A can not depend on W small rule: when living in a repository world, the things that you depend upon will probably be evolving at a rate that is different from your desired release schedule. This implies that you must be able to react to such change quickly and release new versions of your stuff whenever the things you depend upon change. small rule: There will need to be a way to allow multiple co-installed-but-different-versioned copies of a component to be installed at the same time: your $HOME, my $HOME, /usr/local/webstack1.3, /usr/local/webstack2.4/, ... I believe that we are in for a rough time as we start experimenting with the rope that repositories give us. I also believe that we will figure out how to do things in a way that actually works. -John From sac-owner Mon Apr 7 12:07:07 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37J77kJ026460 for ; Mon, 7 Apr 2008 12:07:07 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m37J77dX002432; Mon, 7 Apr 2008 15:07:07 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m37J77M3002429; Mon, 7 Apr 2008 15:07:07 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18426.28891.123724.23148@gargle.gargle.HOWL> Date: Mon, 7 Apr 2008 15:07:07 -0400 From: James Carlson To: John Plocher Cc: George Shepherd , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <47FA6E96.6040700@Sun.Com> References: <200804071512.m37FCYvW028920@serinus.UK.Sun.COM> <47FA5CA8.6010605@Sun.Com> <18426.25345.563464.33920@gargle.gargle.HOWL> <47FA669D.9070507@Sun.Com> <18426.27087.977181.617481@gargle.gargle.HOWL> <47FA6E96.6040700@Sun.Com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1019 John Plocher writes: > James Carlson wrote: > > ...dependencies... > > I think there are some big rules here as well as small ones: > > Big rule: dependencies can only be made on things with > equal or greater "expectation taxonomy" levels. > Given the three buckets: Integrated, Aggregated > and WildWest, > I can not depend on A or W > A can not depend on W I am explicitly arguing that: W can not depend on W It cannot be so, or you need some sort of infrastructure that allows all of the multiple-installed version instances of W components to locate each other properly at run time. Lacking a general solution for that, and with the requirement that we somehow allow administrators to install W bits "whereever," I think we end up with that new rule above. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Mon Apr 7 12:11:35 2008 Received: from dm-uk-01.uk.sun.com (dm-uk-01.UK.Sun.COM [129.156.101.115]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37JBYQF026967 for ; Mon, 7 Apr 2008 12:11:34 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m37JBW7x025061; Mon, 7 Apr 2008 20:11:32 +0100 (BST) Received: from aldebaran.UK.Sun.COM (aldebaran [129.156.173.71]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with SMTP id m37JBWg2003174; Mon, 7 Apr 2008 20:11:32 +0100 (BST) Message-Id: <200804071911.m37JBWg2003174@serinus.UK.Sun.COM> Date: Mon, 7 Apr 2008 20:11:32 +0100 (BST) From: George Shepherd Reply-To: George Shepherd Subject: Re: LSARC/2008/061 - FOSS Check List To: John.Plocher@sun.com, james.d.carlson@sun.com Cc: George.Shepherd@sun.com, sac-review@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KJhxvdp23dRRN3bP2QlaPw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_82 SunOS 5.11 sun4u sparc Status: RO Content-Length: 615 *>I am explicitly arguing that: *> *> W can not depend on W *> *>It cannot be so, or you need some sort of infrastructure that allows *>all of the multiple-installed version instances of W components to *>locate each other properly at run time. *> *>Lacking a general solution for that, and with the requirement that we *>somehow allow administrators to install W bits "whereever," I think we *>end up with that new rule above. I think though we can say that W can rely on W_version-x.y If IPS can declare those dependencies which I believe it can IPS rather than the repository can take care of that. -George From sac-owner Mon Apr 7 12:19:45 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37JJinp027352 for ; Mon, 7 Apr 2008 12:19:45 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m37JJiWA002512; Mon, 7 Apr 2008 15:19:44 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m37JJi27002509; Mon, 7 Apr 2008 15:19:44 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18426.29648.599572.414510@gargle.gargle.HOWL> Date: Mon, 7 Apr 2008 15:19:44 -0400 From: James Carlson To: George Shepherd Cc: John.Plocher@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <200804071911.m37JBWg2003174@serinus.UK.Sun.COM> References: <200804071911.m37JBWg2003174@serinus.UK.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1385 George Shepherd writes: > > *>I am explicitly arguing that: > *> > *> W can not depend on W > *> > *>It cannot be so, or you need some sort of infrastructure that allows > *>all of the multiple-installed version instances of W components to > *>locate each other properly at run time. > *> > *>Lacking a general solution for that, and with the requirement that we > *>somehow allow administrators to install W bits "whereever," I think we > *>end up with that new rule above. > > I think though we can say that W can rely on W_version-x.y > If IPS can declare those dependencies which I believe it can > IPS rather than the repository can take care of that. I still have to ask: how does that work? If I'm a W-resident package that depends on bits from other W-resident packages, how do I *find* any of those bits? John has already stated that the administrator may supply alternate paths for the bits in these packages and that there may be multiple versions installed. Clearly, that means that I have to get the installed path at run time and somehow patch myself up to run with that. Am I just being dense, or is there currently no way this can work? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Mon Apr 7 12:27:13 2008 Received: from dm-uk-02.uk.sun.com (dm-uk-02.UK.Sun.COM [129.156.101.196]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37JRCLC027442 for ; Mon, 7 Apr 2008 12:27:13 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m37JRA13022916; Mon, 7 Apr 2008 20:27:10 +0100 (BST) Received: from aldebaran.UK.Sun.COM (aldebaran [129.156.173.71]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with SMTP id m37JRAlV003405; Mon, 7 Apr 2008 20:27:10 +0100 (BST) Message-Id: <200804071927.m37JRAlV003405@serinus.UK.Sun.COM> Date: Mon, 7 Apr 2008 20:27:10 +0100 (BST) From: George Shepherd Reply-To: George Shepherd Subject: Re: LSARC/2008/061 - FOSS Check List To: George.Shepherd@sun.com, james.d.carlson@sun.com Cc: John.Plocher@sun.com, sac-review@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ziSw/Y1ART0R8uFsvACq4A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_82 SunOS 5.11 sun4u sparc Status: RO Content-Length: 883 *>If I'm a W-resident package that depends on bits from other W-resident *>packages, how do I *find* any of those bits? John has already stated *>that the administrator may supply alternate paths for the bits in *>these packages and that there may be multiple versions installed. *>Clearly, that means that I have to get the installed path at run time *>and somehow patch myself up to run with that. *> *>Am I just being dense, or is there currently no way this can work? *> I don't subscribe to the idea that the admin should be able to put stuff just anywhere, but the packaging system is what takes care of the problem in Ubuntu for example.. It goes off and FINDS the dependencies in the repository and just installs them where they can be used by the pkg you requested. AFAIK there aren't options to displace the base of the install path at administrator whim. -George From sac-owner Mon Apr 7 12:50:12 2008 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37JoBdp027665 for ; Mon, 7 Apr 2008 12:50:12 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m37JoBMd002638; Mon, 7 Apr 2008 15:50:11 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m37JoBYf002635; Mon, 7 Apr 2008 15:50:11 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18426.31475.561678.906236@gargle.gargle.HOWL> Date: Mon, 7 Apr 2008 15:50:11 -0400 From: James Carlson To: George Shepherd Cc: John.Plocher@sun.com, sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List In-Reply-To: <200804071927.m37JRAlV003405@serinus.UK.Sun.COM> References: <200804071927.m37JRAlV003405@serinus.UK.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1297 George Shepherd writes: > > *>If I'm a W-resident package that depends on bits from other W-resident > *>packages, how do I *find* any of those bits? John has already stated > *>that the administrator may supply alternate paths for the bits in > *>these packages and that there may be multiple versions installed. > *>Clearly, that means that I have to get the installed path at run time > *>and somehow patch myself up to run with that. > *> > *>Am I just being dense, or is there currently no way this can work? > *> > > I don't subscribe to the idea that the admin should be able to put stuff > just anywhere, but the packaging system is what takes care of the problem > in Ubuntu for example.. It goes off and FINDS the dependencies in the > repository and just installs them where they can be used by the pkg you > requested. > AFAIK there aren't options to displace the base of the install path > at administrator whim. It sounds like we're all talking about very different solutions. Having a concrete solution on the table would help focus the discussion. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sac-owner Mon Apr 7 12:59:34 2008 Received: from dm-uk-01.uk.sun.com (dm-uk-01.UK.Sun.COM [129.156.101.115]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37JxXYU028222 for ; Mon, 7 Apr 2008 12:59:34 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m37JxVxW005727; Mon, 7 Apr 2008 20:59:31 +0100 (BST) Received: from aldebaran.UK.Sun.COM (aldebaran [129.156.173.71]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with SMTP id m37JxVX1003916; Mon, 7 Apr 2008 20:59:31 +0100 (BST) Message-Id: <200804071959.m37JxVX1003916@serinus.UK.Sun.COM> Date: Mon, 7 Apr 2008 20:59:31 +0100 (BST) From: George Shepherd Reply-To: George Shepherd Subject: Re: LSARC/2008/061 - FOSS Check List To: George.Shepherd@Sun.COM, james.d.carlson@Sun.COM Cc: John.Plocher@Sun.COM, sac-review@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ixYvzspCBEQlWg3v1jMYRA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_82 SunOS 5.11 sun4u sparc Status: RO Content-Length: 248 James I'm going to drop it for a while it's kind of late here, but I it seemed to me John was just floating the idea that the admin should be able to choose a given pkg goes. Of course I could very easily have read incorrectly between the lines. From my standpoint the IPS functionality and the repository rules are Status: RO two parts of the same solution. Agreed though, I've not sat down with anyone and had a discussion about how this might actually work. So yes, hopefully the gab fest part of this leads to a proposal that can actually pass the test of technical and architectural merit. -George *>Date: Mon, 07 Apr 2008 15:50:11 -0400 *>From: James Carlson *>Subject: Re: LSARC/2008/061 - FOSS Check List *>To: George Shepherd *>Cc: John.Plocher@Sun.COM, sac-review@sac.sfbay.sun.com *>MIME-version: 1.0 *>Content-transfer-encoding: 7BIT *>X-PMX-Version: 5.4.1.325704 *> *>George Shepherd writes: *>> *>> *>If I'm a W-resident package that depends on bits from other W-resident *>> *>packages, how do I *find* any of those bits? John has already stated *>> *>that the administrator may supply alternate paths for the bits in *>> *>these packages and that there may be multiple versions installed. *>> *>Clearly, that means that I have to get the installed path at run time *>> *>and somehow patch myself up to run with that. *>> *> *>> *>Am I just being dense, or is there currently no way this can work? *>> *> *>> *>> I don't subscribe to the idea that the admin should be able to put stuff *>> just anywhere, but the packaging system is what takes care of the problem *>> in Ubuntu for example.. It goes off and FINDS the dependencies in the *>> repository and just installs them where they can be used by the pkg you *>> requested. *>> AFAIK there aren't options to displace the base of the install path *>> at administrator whim. *> *>It sounds like we're all talking about very different solutions. *> *>Having a concrete solution on the table would help focus the *>discussion. *> *>-- *>James Carlson, Solaris Networking *>Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 *>MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 George Shepherd http://clem.uk/~georges/ ============================================================================== Solaris Revenue Product Engineering: | SUN Microsystems Core team -Internet | Guillemont Park Email: George.Shepherd@Sun.COM | Camberley GU17 9QG Disclaimer: Less is more, more or less | United Kingdom ============================================================================== From sac-owner Mon Apr 7 13:22:17 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37KMHKg028747 for ; Mon, 7 Apr 2008 13:22:17 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m37KMHqJ045679 for ; Mon, 7 Apr 2008 13:22:17 -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 m37KMC58014700 for ; Mon, 7 Apr 2008 13:22:12 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JYZ000011PNJU00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for sac-review@sac.sfbay.sun.com; Mon, 07 Apr 2008 13:22:12 -0700 (PDT) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYZ00MBX1WYCD40@fe-sfbay-09.sun.com>; Mon, 07 Apr 2008 13:22:10 -0700 (PDT) Date: Mon, 07 Apr 2008 13:22:09 -0700 From: John Plocher Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <18426.28891.123724.23148@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: George Shepherd , sac-review@sac.sfbay.sun.com Message-id: <47FA8271.4050607@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200804071512.m37FCYvW028920@serinus.UK.Sun.COM> <47FA5CA8.6010605@Sun.Com> <18426.25345.563464.33920@gargle.gargle.HOWL> <47FA669D.9070507@Sun.Com> <18426.27087.977181.617481@gargle.gargle.HOWL> <47FA6E96.6040700@Sun.Com> <18426.28891.123724.23148@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Status: RO Content-Length: 578 James Carlson wrote: > I am explicitly arguing that: > > W can not depend on W > > It cannot be so, or you need some sort of infrastructure that allows > all of the multiple-installed version instances of W components to > locate each other properly at run time. If I install W:myfoo into $HOME, then I expect the installer to figure out the dependencies such that either they are found in the "A" or "I" parts of the already installed system (i.e., the canonical places, not other people's $HOMEs...), or are also downloaded from "I", "A" or "W" into my $HOME. -John From sac-owner Mon Apr 7 13:38:45 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02.SFBay.Sun.COM [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37KcjD1029146 for ; Mon, 7 Apr 2008 13:38:45 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m37Kcisn022353 for ; Mon, 7 Apr 2008 13:38:44 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m37KciEf013549 for ; Mon, 7 Apr 2008 20:38:44 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 <0JYZ00C010PWI200@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for sac-review@sac.sfbay.sun.com; Mon, 07 Apr 2008 14:38:44 -0600 (MDT) Received: from 129.145.154.70 ([129.145.154.70]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JYZ00B4G2OG81D0@mail-amer.sun.com>; Mon, 07 Apr 2008 14:38:41 -0600 (MDT) Date: Mon, 07 Apr 2008 13:38:40 -0700 From: John Fischer Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <47F56874.6030401@sun.com> Sender: John.Fischer@Sun.COM To: Scott Rotondo Cc: Jyri Virkki , sac-review@sac.sfbay.sun.com Reply-to: John.Fischer@Sun.COM Message-id: <1207600719.48696.9.camel@sr1-umpk-19> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1203531711.63061.56.camel@sr1-umpk-34> <18364.29441.424474.30500@gargle.gargle.HOWL> <200802201855.m1KItXIM006432@dm-holland-02.uk.sun.com> <20080220191006.GD14350@Sun.COM> <200802201913.m1KJDHDg009721@dm-holland-02.uk.sun.com> <20080220191941.GE14350@Sun.COM> <18364.32972.619727.387739@gargle.gargle.HOWL> <20080220193658.GJ14350@Sun.COM> <1203537526.63061.83.camel@sr1-umpk-34> <1207088541.43474.22.camel@sr1-umpk-19> <20080402022836.GE13187@sun.com> <1207248339.43474.74.camel@sr1-umpk-19> <47F56874.6030401@sun.com> Status: RO Content-Length: 1302 Scott, I am not necessarily saying that I am trying to keep the conversation going in a constructive direction. This goes along with the Volatile not needing review but Uncommitted and Committed needing review. What is the delineation that is reasonable. I think that you make a very good argument that origination and ownership does not matter. For some it seems that it does. Thanks, John On Thu, 2008-04-03 at 16:29, Scott Rotondo wrote: > John Fischer wrote: > > In the desktop C-team we have several people who are Maintainers > > of Open Source projects, for example, gdm. Although a Sun engineer > > is the maintainer Sun is actually not the originator but the Gnome > > community is the originator. For things that Sun is both the > > originator and maintainer then I think that further review is > > required. Does that sound reasonable? If so then another > > question would follow: > > > > If a Sun engineer is the maintainer is Sun also the > > originator of the project? > > [ ] Yes -- ARC review required > > [ ] No > > > > Why would you want to require extra review when Sun is the originator, > that you would not require for exactly the same software from outside? > > See my previous email about perverse incentives and unintended consequences. > > Scott From sac-owner Mon Apr 7 14:37:46 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01.SFBay.Sun.COM [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m37LbkbD001494 for ; Mon, 7 Apr 2008 14:37:46 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m37Lbj97032949 for ; Mon, 7 Apr 2008 14:37:46 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m37Lc8Fc028801 for ; Mon, 7 Apr 2008 21:38:08 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JYZ000015ABMU00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for sac-review@sac.sfbay.sun.com; Tue, 08 Apr 2008 05:37:09 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JYZ00B1Q5DVRGM2@mail-apac.sun.com>; Tue, 08 Apr 2008 05:37:09 +0800 (SGT) Date: Mon, 07 Apr 2008 14:37:37 -0700 From: Darren Reed Subject: Re: LSARC/2008/061 - FOSS Check List In-reply-to: <200804071927.m37JRAlV003405@serinus.UK.Sun.COM> Sender: Darren.Reed@Sun.COM To: George Shepherd Cc: James.D.Carlson@Sun.COM, John.Plocher@Sun.COM, sac-review@sac.sfbay.sun.com Message-id: <47FA9421.3010603@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en References: <200804071927.m37JRAlV003405@serinus.UK.Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 1627 George Shepherd wrote: >*>If I'm a W-resident package that depends on bits from other W-resident >*>packages, how do I *find* any of those bits? John has already stated >*>that the administrator may supply alternate paths for the bits in >*>these packages and that there may be multiple versions installed. >*>Clearly, that means that I have to get the installed path at run time >*>and somehow patch myself up to run with that. >*> >*>Am I just being dense, or is there currently no way this can work? >*> > >I don't subscribe to the idea that the admin should be able to put stuff >just anywhere, but the packaging system is what takes care of the problem >in Ubuntu for example.. It goes off and FINDS the dependencies in the >repository and just installs them where they can be used by the pkg you >requested. >AFAIK there aren't options to displace the base of the install path >at administrator whim. > > George, If the admin cannot decide what the base directory for the installation of software is then it possibly becomes impossible to install more than one version of the same package. When faced with problems like that, ISVs are left with no choice but to use tar as the install mechanism if they wish to allow more than one version of the software to be installed. That isn't all that attractive, but it works. Prior to Sun, I worked at a company that used tar to install software on Solaris for this very reason - and they continue to use tar as the installation mechanism for their software because customers do install more than one revision and pkg* fails to meet their requirements here. Darren From sac-owner Wed Apr 16 13:03:20 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m3GK3KkH023116 for ; Wed, 16 Apr 2008 13:03:20 -0700 (PDT) Received: from [129.150.13.200] (vpn-129-150-13-200.SFBay.Sun.COM [129.150.13.200]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m3GK3Keq789316; Wed, 16 Apr 2008 13:03:20 -0700 (PDT) Message-ID: <48065BA4.900@sun.com> Date: Wed, 16 Apr 2008 10:03:48 -1000 From: Joseph Kowalski User-Agent: Thunderbird 2.0.0.9 (X11/20080225) MIME-Version: 1.0 To: John Plocher CC: James Carlson , George Shepherd , sac-review@sac.sfbay.sun.com Subject: Re: LSARC/2008/061 - FOSS Check List References: <200804071512.m37FCYvW028920@serinus.UK.Sun.COM> <47FA5CA8.6010605@Sun.Com> <18426.25345.563464.33920@gargle.gargle.HOWL> <47FA669D.9070507@Sun.Com> <18426.27087.977181.617481@gargle.gargle.HOWL> <47FA6E96.6040700@Sun.Com> In-Reply-To: <47FA6E96.6040700@Sun.Com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 727 I'm way behind in this thread, and I'll try to wait to read it all, but I don't want to forget this... John Plocher wrote: > James Carlson wrote: >> ...dependencies... > > I think there are some big rules here as well as small ones: > > Big rule: dependencies can only be made on things with > equal or greater "expectation taxonomy" levels. > Given the three buckets: Integrated, Aggregated > and WildWest, > I can not depend on A or W > A can not depend on W This assumes that there is one linear set of "types". Is it all about stability? What if another axis was "can be audited" or "degree of security" (which is kinda why we have the "core Metacluster", right?)? - jek3 From sacadmin Tue Jun 10 17:05:05 2008 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 m5B054SS023157 for ; Tue, 10 Jun 2008 17:05:04 -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 m5B04jgc019659 for <@sunmail2sca.sfbay.sun.com:lsarc@sun.com>; Wed, 11 Jun 2008 08:05:00 +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 <0K2900707UWBPH00@brm-avmta-1.central.sun.com> for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 10 Jun 2008 18:04:59 -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 <0K29006U8UWAOD00@brm-avmta-1.central.sun.com> for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 10 Jun 2008 18:04:58 -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 m5B04wP1016029 for ; Tue, 10 Jun 2008 17:04:58 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K2900001UNQHP00@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 10 Jun 2008 17:04:58 -0700 (PDT) Received: from [192.168.10.12] ([76.20.56.47]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K290038YUW96WG0@fe-sfbay-09.sun.com> for lsarc@sun.com (ORCPT lsarc@sun.com); Tue, 10 Jun 2008 17:04:58 -0700 (PDT) Date: Tue, 10 Jun 2008 17:04:55 -0700 From: John Fischer Subject: LSARC/2008/061 - FOSS Check List... Sender: John.Fischer@sun.com To: lsarc Reply-to: John.Fischer@sun.com Message-id: <484F16A7.9000201@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_tJym9IS3tpmmpIMghsjXgw)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080507) Status: RO Content-Length: 17558 This is a multi-part message in MIME format. --Boundary_(ID_tJym9IS3tpmmpIMghsjXgw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT All, Here is the updated FOSS check list. Feedback is always appreciated. I will be resending this to SAC for review on Friday. Thanks, John --Boundary_(ID_tJym9IS3tpmmpIMghsjXgw) Content-type: text/plain; name=foss-check-list.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=foss-check-list.txt FCL--FOSS Check List 0. Introduction 0.1 Document History Version Author Changes Date 0.1 John Fischer Initial Draft 01/11/2008 0.2 John Fischer Modified based upon feedback from ARC members 01/29/2008 0.3 John Fischer Modified based upon feedback during committee 02/12/2008 review 0.4 John Fischer Modified based upon SAC review feedback 04/01/2008 0.5 John Fischer Modified based upon LSARC business meeting 06/10/2008 adding familiarity question and mod dates. 0.2 Purpose Architecture review at Sun has allowed the company to evolve our projects within multiple disjoint groups while still maintaining a cohesive product line. Each architecture review was conducted within Sun's control. With the advent of Free Open Source Software processes the control that Sun as a company can wield has been diminished. Now that Sun is moving to a more fluid delivery mechanism with project Indiana we need to evolve the architecture review process. This document is meant to aid in the architecture review process. Each new project must complete this check list to help ensure that the overall resulting product conforms to Sun product standards. If the project deviates from these standards further review would be necessary by an architecture review committee. After the check list is completed the project team should be able to determine if a project can be automatically approved. This will occur if all checks result in no "ARC review required" answers. A committee member will assist the project team in filing the automatically approved fast track. An automatically approved fast track is still required in order to record the interfaces for future reference. If the project needs to have further review then follow the regular process for getting projects reviewed. 1.0 Project Information 1.1 Name of project/component 1.2 Author of document 2.0 Project Summary 2.1 Project Description 2.2 Release binding What is is the release binding? (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/) [ ] Major [ ] Minor [ ] Patch or Micro [ ] Unknown -- ARC review required 2.3 Type of project Is this case a Linux Familiarity project? [ ] Yes [ ] No 2.4 Originating Community 2.4.1 Community Name 2.4.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [ ] Contributor [ ] Monitoring Will the project team work with the upstream community to resolve architectural issues of interest to Sun? [ ] Yes [ ] No - briefly explain Will we or are we forking from the community? [ ] Yes - ARC review required prior to forking [ ] 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? [ ] Yes [ ] No - ARC review required Does this project install into /usr under [sbin|bin|lib|include|man|share]? [ ] Yes [ ] No or N/A Does this project install into /opt? [ ] Yes - explain below [ ] No or N/A Does this project install into a different directory structure? [ ] Yes - ARC review required [ ] 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 [ ] No If conflicts exist then will this project install under /usr/gnu? [ ] Yes [ ] No - ARC review required [ ] N/A Is this project installing into /usr/sfw? [ ] Yes - ARC review required [ ] No 3.1.1W Windows Installation - section only required for Windows Software (see http://sac.sfbay/WSARC/2002/494 for details) Does this project install software into a :\Program Files\Sun\ or :\Sun\ directory? [ ] Yes [ ] No - ARC review required Does the project use the Windows registry? [ ] Yes [ ] No - ARC review required Does the project use HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\ for the registry key? [ ] Yes [ ] No - ARC review required Is the project's stored location HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\\\Path? [ ] Yes [ ] No - ARC review required 3.1.2 Share and Sharable Does the module include any components that are used or shared by other projects? [ ] Yes [ ] No If yes are these components packaged to be shared with the other FOSS? [ ] Yes [ ] No - ARC review required [ ] N/A Are these components already in the Solaris WOS? [ ] Yes [ ] No - continue with next section (section 3.2) 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 Exported Libraries Are 64-bit versions of the libraries being delivered? [ ] Yes [ ] No - ARC review required Are static versions of the libraries being delivered? [ ] Yes - ARC review required [ ] No 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 [ ] No Does the project integrate any new entries into /etc/inittab or /etc/inetd.conf? [ ] Yes - ARC review required [ ] No Does the project integrate any private non-public files into /etc/default or /etc/ configuration files? [ ] Yes - ARC review required [ ] No Does the service manifests method context grant rights above that of the noaccess user and basic privilege set? [ ] Yes - ARC review required [ ] No 3.4 Security 3.4.1 Secure By Default (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 [ ] N/A Are network services automatically enabled by the project during installation? [ ] Yes - ARC review required [ ] No [ ] N/A Are inbound network communications denied by default? [ ] Yes [ ] No - ARC review required [ ] N/A Is inbound data checked to prevent content-based attacks? [ ] Yes [ ] No - ARC review required [ ] N/A Is the outbound receiver authenticated? [ ] Yes [ ] No - ARC review required [ ] N/A Is the receiver authenticated prior to receiving any sensitive outbound communication? [ ] Yes [ ] No - ARC review required [ ] 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 [ ] No - continue with next section (section 3.4.3) 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 [ ] No - continue to next section (section 3.4.4) (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 [ ] No - continue to next section (section 3.4.5) 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 [ ] No - continue to next section (section 3.4.6) 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 (section 3.4.6) 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? [ ] Yes [ ] No - ARC review required Do network services for the project make decisions based upon user, host or service identities? [ ] Yes - explain below [ ] No [ ] N/A Do the components make use of secret information during authentication and/or authorization? [ ] Yes - explain below [ ] No [ ] N/A 3.5 Networking Do the components access the network? [ ] Yes [ ] No - continue to next section (section 3.6) If yes do the components support IPv6? [ ] Yes [ ] 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 [ ] 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 --------------------------- ------------------- --------------------------- Wizzy Volatile version 0.65 Bang Project Private internally used by Wizzy for extra punch SUNWwizzy Uncommitted Wizzy's packaging 4.2 Imported Interfaces Interface Name Classification Comments --------------------------- -------------------- -------------------------- Slushy Volatile Cherry Flavor Committed Stingy Contracted Volatile see contract-4 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 - interfaces are fluid and will follow a rapidly changing community Uncommitted - interfaces are still evolving in the community and might follow the community Committed - interfaces are stable in the community Project Private - no review required, just document 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 --Boundary_(ID_tJym9IS3tpmmpIMghsjXgw)-- From sacadmin Thu Jun 12 16:09:41 2008 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 m5CN9enn013889 for ; Thu, 12 Jun 2008 16:09:40 -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 m5CN8soB000269; Fri, 13 Jun 2008 07:09:37 +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 <0K2D00J0FHO01200@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 16:09:36 -0700 (PDT) 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 <0K2D00BNIHNZR6A0@nwk-avmta-2.sfbay.sun.com>; Thu, 12 Jun 2008 16:09:35 -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-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5CN9ZY6003926; Thu, 12 Jun 2008 23:09:35 +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 m5CN9Ym14977; Thu, 12 Jun 2008 16:09:34 -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 m5CN9YG9014200; Thu, 12 Jun 2008 16:09:34 -0700 (PDT) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m5CN9YYh014199; Thu, 12 Jun 2008 16:09:34 -0700 (PDT) Date: Thu, 12 Jun 2008 16:09:34 -0700 From: Jyri Virkki Subject: Re: LSARC/2008/061 - FOSS Check List... In-reply-to: <484F16A7.9000201@sun.com> To: John Fischer Cc: lsarc Message-id: <20080612230934.GJ13095@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: <484F16A7.9000201@sun.com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 341 John Fischer wrote: > > 2.3 Type of project > Is this case a Linux Familiarity project? > [ ] Yes > [ ] No While that's the phrase of the moment, I'm not sure there's a crisp enough definition of what that really means for this to be a useful Y/N question. -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems