From sacadmin Fri Oct 6 14:57:47 2006 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k96LvlbL005260; Fri, 6 Oct 2006 14:57:47 -0700 (PDT) Received: (from plocher@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id k96Lvl0P005256; Fri, 6 Oct 2006 14:57:47 -0700 (PDT) Date: Fri, 6 Oct 2006 14:57:47 -0700 (PDT) From: John Plocher Message-Id: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: arc-chairs@sun.com Subject: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] Status: RO Content-Length: 13430 Subject: PSARC FastTrack: sac changes to support open psarc cases As promised/threatened, here is the proposal for opening up ARC discussions to include the OpenSolaris community. While this proposal presumes some knowledge of "how things are currently being done", I've tried to make it make sense without having to deep dive into the details of the sac infrastructure. -John Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2006 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: sac changes to support open psarc cases 1.2. Name of Document Author/Supplier: Author: John Plocher 1.3 Date of This Document: 06 October, 2006 4. Technical Description Contents: Requirements Scope Constraints Proposal Details Use cases Failure modes Requirements: R1) The OpenSolaris bound projects going thru the existing ARC process need to be observable by the external members of the OpenSolaris community. This implies that they: R1a) will receive all email relating to the case R1b) will see the same case archives/materials as internal ARC participants R2) External members of the OpenSolaris community must be able to participate as equals in the review of open ARC cases. This implies that they: R2a) can send mail about the case that goes to the entire ARC community Out of scope: R2b) Direct submission of fasttracks and onepagers by members of the external community. R3) Cross-ARC discussions still need to be supported (i.e., joint PSARC/LSARC reviews...) Scope: In: Participating as peers in the review of all OpenSolaris ARC Reviews. This means being able to comment, not just watch. Out: External ARC membership, internship or licensees Out: Direct external submission of cases or materials (These will be the focus of followup efforts) In: PSARC focus Out: Other ARCs (but R3 (above) may require more) In: Mechanisms focused on email communication Out: Logistics of ARC meetings, conference calls, etc Out: Moving all of PSARC and its SAC archives/tools off of sac.sfbay and onto opensolaris.org. Constraints: C1) Don't surprise people by delivering mail to external people when it is sent to a Sun-internal alias. C2) Don't expose mail archives that contain "internal" email messages (via C1) (This impacts the mirroring of case materials on opensolaris.org and the diligance needed to publish historical cases) C3) Don't subdivide the community when reviewing open cases. Internal PSARC and external Community participants should experience the same behaviors (and face the same obstacles) C4) Internal and External participants should use the same tools where possible. C4) Don't break the existing tools used by PSARC members. Proposal: Ditch the current psarc-ext cruft as a failed (but useful) experiment. Move all 3 of the psarc-ext cases (550, 555, 561) back into the psarc case hierarchy. Fix up the projects.db file on sac to reassign them to psarc. New cases will be assigned to PSARC independently of whether or not they were open or closed. Modify the onepager template to ask whether a proposal is open or closed. Ditto for sac_nextcase. Use the info to initialize the IAM:Exposure field. Set up the sac aliases to have the sac mail filter do "bounce mail checks" before sending mail on to real people (psarc members, opensolaris.org subscribers, ...) or bouncing back to the sender. Have the sac mail filter automatically forward open mail to external observers for open cases. Detect "intent mismatches": Open case mail sent to a closed alias should bounce, closed case mail to an open alias can be allowed. Use the IAM:Exposure field to identify whether a case is open or not; use the sac mail filter and /etc/aliases to tag aliases as open or closed. Details: Modify sac_mail_filter.pl: M1) Add command line option: --policy={open,closed} The default is closed. sac_mail_filter and all the sac.sfbay mail aliases are "SAC tools consolidation" private implementation details For each case found on the Subject: line: M1a) if any "Exposure: open" and --policy=closed Do not deliver the mail to anyone. If there is only ONE To: or Cc: address, bounce it back to the sender with a message like the following: "Error: Private conversations are not allowed about open cases. Your email was not delivered to anyone. You addressed your mail to a 'closed' alias, but referred to an 'open' case () on the Subject: line. To Fix: ..." If there are multiple To:/Cc: aliases, bounce with a message like: "Error: Private conversations are not allowed about open cases. Your email was not delivered to , but it was delivered to . You addressed your mail to a 'closed' alias, but referred to an 'open' case () on the Subject: line. To Fix: ..." M1b) "Exposure: open" and --policy=open Forward to psarc-subscribers Forward to IAM:Interest list Forward to psarc-interest-ext@sun. M1c) "Exposure: closed/manual and --policy=closed Forward to psarc-subscribers Forward to any "*@sun.com" on IAM:Interest list. DO NOT forward to non-@sun.com IAM:Interest DO NOT forward to psarc-interest-ext@sun. M1d) "Exposure: closed/manual and --policy=open ALTERNATIVE 1: (same as M1b: open/open) Forward to psarc-subscribers Forward to all IAM:Interest lists Forward to psarc-interest-ext@sun ALTERNATIVE 2: (similar to M1a: mismatch) Do not deliver the mail to anyone, but instead bounce the mail with an "intent error" like the above. M2) log messageIDs and check for duplicates. This needs to be multi-thread/multi-process safe to avoid race conditions. M3) Allow IAM:Interest to contain the name of an ARC to be included in discussions (instead of requiring a hardcoded alias). That is, allow Interest: WSARC, John.Plocher@Sun.Com, Joerg@OpenSolaris.org Use this to generate the proper forwarding aliases depending on the case's open/closed state: open => *arc-subscribers, *arc-interest-ext@sun closed => *arc-subscribers ONLY M4) Modify the existing Committed Private PSARC sac mail alias implementation from the existing psarc@sac: sac-mail-filter psarc-subscribers [for reference, psarc-subscribers is a project private implementation detail, made up of psarc-member-list psarc-intern-list psarc-interest private-psarc-log private-psarc-hypermail arc-interest ] to simply: psarc@sac: sac_mail_filter --policy=closed M5) Create (as "SAC tools consolidation private") psarc-ext@sac: sac_mail_filter --policy=open M6) Create (as "SAC tools consolidation private") psarc-interest-ext@sun.com (via netadmin) Populate with "opensolaris-arc@OpenSolaris.org" M7) Create (as Public/Committed) psarc@OpenSolaris.org" as an alias that only redirects incoming email to psarc-ext@sac (repeat for psarc-members, psarc-record, psarc-agenda and psarc-business as required) M8) Repeat for lsarc, wsarc, fwarc, but don't populate their *-interest-ext@sun.com aliases with anything for now. Use cases: Send all closed case email to PSARC@sun.com Send all open case email to PSARC@opensolaris.org Generate bounce messages when an open/closed mismatch is detected. Normal closed behavior: To: PSARC@Sun.Com (a closed alias) Subject: 2006/400 (a closed case) PSARC@Sun.Com -> psarc@sac -> sac-mail-filter-filter --policy=closed PSARC/2006/400/IAM::Exposure: closed matches the --policy=closed filter attribute, so send out mail to the usual internal suspects... Normal open behavior: To: PSARC@OpenSolaris.org (an open alias) Subject: 2006/555 (an open case) PSARC@OpenSolaris.org -> psarc-ext@sac -> sac-mail-filter-filter --policy=open Exposure: open matches the --policy=open filter attribute, so send out mail to the usual internal and external suspects... Mismatch (private discussions on open cases): To: PSARC@Sun.Com (a closed alias) Subject: 2006/555 (an open case) Exposure: open DOES NOT match the --policy=closed filter attribute, so bounce the message back to sender with an error. Mismatch (open discussions on closed cases): To: PSARC@OpenSolaris.org (an open alias) Subject: 2006/400 (a closed case) Exposure: closed DOES NOT match the --policy=open filter attribute, but the message itself is non- proprietary. Send a warning message to the sender informing them that, since the case is closed, public discussion is not desirable, but that their message *was* delivered. Send out mail to the usual internal and external suspects. [Option: tag the message with a note saying "public discussion about a private case" to alert recipients to consider what they say?] Crossposting to multiple internal ARCs: To: WSARC@Sun.Com Cc: PSARC@Sun.Com Subject: 2006/400 (a closed case) Message will get processed by the mail filter twice. The first invocation will log the messageID, process the message, archive the mail and forward it on to any sun-internal IAM:Interest lists; all other filter invocations will see that the messageID has been processed and will only send the message on to the per-ARC specific subscribers (but not re-archive or resend to any IAM:interest aliases). Crossposting to multiple external ARCs: To: WSARC@OpenSolaris.org Cc: PSARC@OpenSolaris.org Subject: 2006/550 (an open case) Message will get processed by the mail filter twice. The first invocation will log the messageID, process the message, archive the mail and forward it on to any IAM:Interest lists; all other filter invocations will see that the messageID has been processed and will only send the message on to their per-ARC specific subscribers (but not re-archive or resend to any IAM:interest aliases). Failure modes: Crossposting between open and closed aliases starts conversations that can not be continued, gives incorrect user feedback and segregates the community: To: WSARC@Sun.Com Cc: PSARC@OpenSolaris.org Subject: 2006/555 (an open case) The message will generate a bounce back to the sender via the WSARC alias due to the mismatch between a closed alias and an open case. This means that WSARC members will not see this email. The message *will* go to PSARC members (et.al) and psarc-interest-ext@sun as expected because of the Cc to PSARC@OpenSolaris.org. The bounce message will alert the sender to the fact that their email only went to part of the intended audience. Followups from external people to the "closed ARC alias" will be dropped by netadmin (because of the "no mail from the Internet" alias property). Followups from external people cc'd to the "open ARC alias" will succeed, but only to part of the intended audience. Followups from within Sun will again trigger this failure. There is not much that tools on sac.sfbay can do about this type of "pilot error"; even lifting the "no internet mail" block on the *ARC@sun aliases won't help. Take away: Don't mix open and closed policy aliases. Instead, use either M3 (vastly preferred): Add "WSARC" to PSARC/2006/550's IAM:Interest Send mail to To: PSARC@OpenSolaris.org Subject: 2006/555 (an open case) or M6: Send mail to To: WSARC@OpenSolaris.org Cc: PSARC@OpenSolaris.org Subject: 2006/555 (an open case) To: WSARC@Sun.Com Bcc: psarc-ext@sac.sfbay Subject: 2006/555 (an open case) This is similar to the above failure, except that nobody at all will be able to reply. The message will generate a bounce via the WSARC alias, but will go to PSARC members(et.al) and psarc-interest-ext@sun because of the Bcc. Follow ups (to WSARC@sun.com) from outside of Sun will be dropped by netadmin because of its "no mail from the Internet property; follow ups from within Sun to the WSARC alias will generate bounces (M1a, above). Take away: The *@sac aliases (like psarc-ext) are ARC consolidation private interfaces; don't use them. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: sac 6.5. ARC review type: FastTrack From sacadmin Mon Oct 9 05:12:56 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99CCttZ012296; Mon, 9 Oct 2006 05:12:55 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k99CFTgr004176; Mon, 9 Oct 2006 08:15:29 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k99CFTPu004173; Mon, 9 Oct 2006 08:15:29 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17706.15712.785161.378129@gargle.gargle.HOWL> Date: Mon, 9 Oct 2006 08:15:28 -0400 From: James Carlson To: John Plocher Cc: PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> References: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 3098 [Should we be having these discussions in public instead? ;-}] John Plocher writes: > M1d) "Exposure: closed/manual and --policy=open > ALTERNATIVE 1: (same as M1b: open/open) > Forward to psarc-subscribers > Forward to all IAM:Interest lists > Forward to psarc-interest-ext@sun > ALTERNATIVE 2: (similar to M1a: mismatch) > Do not deliver the mail to anyone, but > instead bounce the mail with an "intent error" > like the above. I prefer (1), because doing (2) puts us into one of those awful "please dial 1 for calls outside your area" situations. If I can just switch over to doing "psarc-ext" in all cases, that'd be good. If we must do (2) for some reason (concern about secrets?), then I'd like to have a "--policy=do-not-care" option, so there's some place I can send that always delivers the message without pestering me about internal/external distinctions. Note that (2) does mean that if someone from the outside sends mail to psarc@opensolaris.org citing a "closed" case, then that message will end up distributed internally and added to the archives, and other internal people can end up replying to and cc-ing that message. Also note that case numbers and titles aren't treated as secret information, at least once the code hits the gate or the bug-tracking system. The system isn't completely foolproof, so those who think they're buying some privacy might be misled. Perhaps if we really need a "secret ARC" we should just create a secret ARC. > M7) Create (as Public/Committed) > psarc@OpenSolaris.org" > as an alias that only redirects incoming > email to psarc-ext@sac I think this misses something. psarc@opensolaris.org isn't going to be too useful for external people unless there's also a psarc-interest@opensolaris.org that allows anyone to subscribe and that has published archives. An important part of the ARC is that everyone gets to participate. Not just the few people who are listed in the IAM file, but _everyone_ who has any interest in the case. For what it's worth, and though I don't have a better solution, I'm not too happy with the psarc/interest split. I think external folks will realize that we're filtering messages. Despite our claim that we're just participants in Open Solaris, one among equals, we reserve alone the right to run "secret" cases that the other participants can't see and can't comment on. The whole idea of 'closed' cases makes me really uneasy, at least for Solaris and other open projects. > To: WSARC@Sun.Com > Bcc: psarc-ext@sac.sfbay > Subject: 2006/555 (an open case) Bcc-ing any of the normal ARC lists is probably a mistake, as it defeats the purpose of having a conversation. I wouldn't mind seeing mail that lacks a proper ^TO: recipient rejected with a nastygram back to the sender. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Oct 9 09:40:42 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99GegiR022468; Mon, 9 Oct 2006 09:40:42 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99Gefcl012248; Mon, 9 Oct 2006 09:40:42 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99Gea0g010084; Mon, 9 Oct 2006 09:40:36 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6V00A01NN8QR00@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 09 Oct 2006 09:40:36 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6V00DTSNNLCB9H@d1-sfbay-10.sun.com>; Mon, 09 Oct 2006 09:40:35 -0700 (PDT) Date: Mon, 09 Oct 2006 09:40:33 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <17706.15712.785161.378129@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: John Plocher , PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452A7B81.3020404@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> <17706.15712.785161.378129@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 1177 +-- James Carlson wrote On 10/09/06 05:15,: >> M7) Create (as Public/Committed) >> psarc@OpenSolaris.org" >> as an alias that only redirects incoming >> email to psarc-ext@sac > > > I think this misses something. psarc@opensolaris.org isn't going to > be too useful for external people unless there's also a > psarc-interest@opensolaris.org that allows anyone to subscribe and > that has published archives. The intent (which I didn't make clear) is that The netadmin alias "*ARC-interest-ext" is intended to be maintained by the ARC chair/SAC staff, and to hold a list of external aliases where community members can be found. For PSARC, the psarc-interest-ext@sun netadmin alias will contain "opensolaris-arc@opensolaris.org". That is: psarc@OpenSolaris.org => sac mail filter (to do the open/closed dance) => psarc-interest-ext@sun => opensolaris-arc@opensolaris.org For other arcs (WSARC...), when they get around to needing to be open, this mechanism lets them have their external communities hosted somewhere other than opensolaris.org, if desired. -- John Plocher SAC Processes and Tools MPK17-3674 x87604 From sacadmin Mon Oct 9 09:48:29 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99GmSHk022628 for ; Mon, 9 Oct 2006 09:48:28 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k99Gp4M9005731; Mon, 9 Oct 2006 12:51:04 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k99Gp3N8005728; Mon, 9 Oct 2006 12:51:03 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17706.32247.429711.258292@gargle.gargle.HOWL> Date: Mon, 9 Oct 2006 12:51:03 -0400 From: James Carlson To: John Plocher Cc: PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <452A7B81.3020404@Sun.COM> References: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> <17706.15712.785161.378129@gargle.gargle.HOWL> <452A7B81.3020404@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 646 John Plocher writes: > For PSARC, the psarc-interest-ext@sun netadmin alias > will contain "opensolaris-arc@opensolaris.org". I had thought that opensolaris-arc was for discussing all ARC related matters -- sort of an "all-arcs" for opensolaris.org, not just PSARC. So, if I'm an opensolaris-arc member, my choice is to be involved in the day-to-day reviews of PSARC cases, or to stay away from the ARC process. Right? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Oct 9 10:23:04 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99HN4Zg023686 for ; Mon, 9 Oct 2006 10:23:04 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99HN4mw002520 for ; Mon, 9 Oct 2006 10:23:04 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99HMxDU016233 for ; Mon, 9 Oct 2006 10:22:59 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6V00401PJHO200@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 09 Oct 2006 10:22:59 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6V00D2IPM2VO3I@d1-sfbay-09.sun.com>; Mon, 09 Oct 2006 10:22:54 -0700 (PDT) Date: Mon, 09 Oct 2006 10:22:50 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <17706.32247.429711.258292@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452A856A.6040806@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> <17706.15712.785161.378129@gargle.gargle.HOWL> <452A7B81.3020404@Sun.COM> <17706.32247.429711.258292@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 1347 +-- James Carlson wrote On 10/09/06 09:51,: > I had thought that opensolaris-arc was for discussing all ARC related > matters -- sort of an "all-arcs" for opensolaris.org, not just PSARC. There are two aliases on OpenSolaris dealing with ARC stuff: opensolaris-arc arc reviews of OS.O stuff arc-discuss discussion of arc process and community Maybe we need others/more. What do you think? I've talked (on web-discuss) about how to identify community leaders via email lists (i.e, -core, So, if I'm an opensolaris-arc member, my choice is to be involved in > the day-to-day reviews of PSARC cases, or to stay away from the ARC > process. Right? It could be that you just need to subscribe to the arc-discuss alias. -John From sacadmin Mon Oct 9 10:35:17 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99HZHth024061 for ; Mon, 9 Oct 2006 10:35:17 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k99HZBu7310183; Mon, 9 Oct 2006 10:35:16 -0700 (PDT) Message-Id: <200610091735.k99HZBu7310183@jurassic.eng.sun.com> Date: Mon, 9 Oct 2006 07:34:39 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: James.D.Carlson@sun.com, John.Plocher@sun.com Cc: PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: e5QF7TG6f7XqbcXNoPBezw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1687 > From: John Plocher ... > There are two aliases on OpenSolaris dealing with ARC stuff: > > opensolaris-arc arc reviews of OS.O stuff > arc-discuss discussion of arc process and community > > Maybe we need others/more. What do you think? This was actually discussed with the CAB about a year ago. The thought was that we should try to funnel as much OpenSolaris stuff as possible to one ARC and in order to provide the most contemptable experience to the outside community members, PSARC was selected... OK, most cases would be PSARC appropriate anyway and the goal of "one arc" was consistancy of initial experience (on both sides of the SWAN). Hence, I think opensolaris-arc is actually just a misnamed opensolaris-psarc alias. The point is we don't need the other arcs at the moment. > I've talked (on web-discuss) about how to identify community leaders > via email lists (i.e, -core, having them tied into the voting mechanism as well as the ARC process. > This is an area where much more work needs to be done. > > Remember, "OpenSolaris" is really a playground for things related > to Solaris; it is not a place for things relating to Java, > the compiler tools/netbeans, staroffice/openoffice or JES, so it > is a bit of a stretch to presume that the ARC exposure from > Sun would be restricted to that site. This seems very obvious to me, but you'ld be surprized how many don't get this. However, there are valid exceptions. The Gnome team wants an active area on OpenSolaris so that Solaris-specific modifications to Gnome (that would never go back to Gnome.org) can be produced there. - jek3 From sacadmin Mon Oct 9 10:45:07 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99Hj7Wg024128 for ; Mon, 9 Oct 2006 10:45:07 -0700 (PDT) Received: from [192.168.0.101] (vpn-129-150-26-96.SFBay.Sun.COM [129.150.26.96]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99Hj36N013394; Mon, 9 Oct 2006 10:45:05 -0700 (PDT) Message-ID: <452A8A5F.8000306@sun.com> Date: Mon, 09 Oct 2006 10:43:59 -0700 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: Joseph Kowalski CC: James.D.Carlson@sun.com, John.Plocher@sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] References: <200610091735.k99HZBu7310183@jurassic.eng.sun.com> In-Reply-To: <200610091735.k99HZBu7310183@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 827 Joseph Kowalski wrote: > This was actually discussed with the CAB about a year ago. The thought > was that we should try to funnel as much OpenSolaris stuff as possible > to one ARC and in order to provide the most contemptable experience to > the outside community members, PSARC was selected... > > OK, most cases would be PSARC appropriate anyway and the goal of "one > arc" was consistancy of initial experience (on both sides of the SWAN). > > Hence, I think opensolaris-arc is actually just a misnamed opensolaris-psarc > alias. The point is we don't need the other arcs at the moment. Should we be moving the X & JDS cases from LSARC to PSARC then? Or don't we need the non-ON consolidations either? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Mon Oct 9 10:57:04 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99Hv4uB024692 for ; Mon, 9 Oct 2006 10:57:04 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k99Huw8s316883; Mon, 9 Oct 2006 10:57:03 -0700 (PDT) Message-Id: <200610091757.k99Huw8s316883@jurassic.eng.sun.com> Date: Mon, 9 Oct 2006 07:56:26 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Joseph.Kowalski@eng.sun.com, alan.coopersmith@sun.com Cc: James.D.Carlson@sun.com, John.Plocher@sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: qYE5IHTKgQRrXvf8/1MAvw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1510 > From: Alan Coopersmith ... > Joseph Kowalski wrote: > > This was actually discussed with the CAB about a year ago. The thought > > was that we should try to funnel as much OpenSolaris stuff as possible > > to one ARC and in order to provide the most contemptable experience to > > the outside community members, PSARC was selected... > > > > OK, most cases would be PSARC appropriate anyway and the goal of "one > > arc" was consistancy of initial experience (on both sides of the SWAN). > > > > Hence, I think opensolaris-arc is actually just a misnamed opensolaris-psarc > > alias. The point is we don't need the other arcs at the moment. > > Should we be moving the X & JDS cases from LSARC to PSARC then? > Or don't we need the non-ON consolidations either? Isn't X already in PSARC? At least sometimes? (If not, I think this was just overlooked as an exception.) Do we expect any JDS work on OpenSolaris? Anyway, I recall the CAB understanding there would be exceptions and we could deal with them in the start-up phase. If a few cases which don't fit the PSARC expectation appear, I think we can just deal with them. If a lot start to appear, then we should make the Sun/OpenSolaris ARC infrastructure more robust/flexible. Let's all hope that OpenSolaris is so successful, that we have this problem. Note also the "J-thingies" (Java) can't really be worked under OpenSolaris any more than "G-thingies" (Gnome). Its that multi-platform requirement. - jek3 From sacadmin Mon Oct 9 11:01:49 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99I1nxK024852 for ; Mon, 9 Oct 2006 11:01:49 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k99I1mnq019123 for ; Mon, 9 Oct 2006 11:01:48 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99I1h1f021807 for ; Mon, 9 Oct 2006 11:01:43 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6V00M01RB6U300@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC@sac.sfbay.sun.com; Mon, 09 Oct 2006 11:01:43 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6V00DOPRESW0WF@d1-sfbay-09.sun.com>; Mon, 09 Oct 2006 11:01:43 -0700 (PDT) Date: Mon, 09 Oct 2006 11:01:40 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452A8A5F.8000306@sun.com> Sender: John.Plocher@Sun.COM To: Alan Coopersmith Cc: Joseph Kowalski , James.D.Carlson@Sun.COM, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452A8E84.4080405@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610091735.k99HZBu7310183@jurassic.eng.sun.com> <452A8A5F.8000306@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 465 +-- Alan Coopersmith wrote On 10/09/06 10:43,: > Should we be moving the X & JDS cases from LSARC to PSARC then? > Or don't we need the non-ON consolidations either? Lets figure out how to make ON/PSARC work first, and then complicate the world with the other ARCs. I have a few ideas on how to do LSARC/WSARC; the difficulty is that not all open LSARC cases will map to the JDS/os.o community in the way that (most) open psarc cases map to on/os.o. -John From sacadmin Mon Oct 9 11:03:36 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99I3ZHf024936 for ; Mon, 9 Oct 2006 11:03:36 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k99I68dP006065; Mon, 9 Oct 2006 14:06:08 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k99I68Hb006062; Mon, 9 Oct 2006 14:06:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17706.36752.474639.657197@gargle.gargle.HOWL> Date: Mon, 9 Oct 2006 14:06:08 -0400 From: James Carlson To: John Plocher , Joseph Kowalski Cc: PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <452A856A.6040806@Sun.COM> References: <200610091735.k99HZBu7310183@jurassic.eng.sun.com> <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> <17706.15712.785161.378129@gargle.gargle.HOWL> <452A7B81.3020404@Sun.COM> <17706.32247.429711.258292@gargle.gargle.HOWL> <452A856A.6040806@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2152 John Plocher writes: > > +-- James Carlson wrote On 10/09/06 09:51,: > > I had thought that opensolaris-arc was for discussing all ARC related > > matters -- sort of an "all-arcs" for opensolaris.org, not just PSARC. > > There are two aliases on OpenSolaris dealing with ARC stuff: > > opensolaris-arc arc reviews of OS.O stuff > arc-discuss discussion of arc process and community > > Maybe we need others/more. What do you think? OK. I guess I misunderstood the underlying purpose of opensolaris-arc. It seems ok to me if it's similar to 'arc-interest,' though it isn't quite that. > Remember, "OpenSolaris" is really a playground for things related > to Solaris; it is not a place for things relating to Java, > the compiler tools/netbeans, staroffice/openoffice or JES, so it > is a bit of a stretch to presume that the ARC exposure from > Sun would be restricted to that site. Sure; understood. It's also the case that there's no direct mapping from *ARC to product, so any open system is going to have holes in it unless everything's opened. > > So, if I'm an opensolaris-arc member, my choice is to be involved in > > the day-to-day reviews of PSARC cases, or to stay away from the ARC > > process. Right? > > It could be that you just need to subscribe to the arc-discuss alias. I am, but ok. Joseph Kowalski writes: > Hence, I think opensolaris-arc is actually just a misnamed opensolaris-psarc > alias. The point is we don't need the other arcs at the moment. I'm not sure that it is actually 'opensolaris-psarc'. It's more like "opensolaris-psarc-plus-some-lsarc-and-perhaps-others." Unlike the existing ARCs and aliases, it's specific to a product line rather than to a technology area. > This seems very obvious to me, but you'ld be surprized how many don't get > this. I'm not sure what might lead to someone thinking that I didn't realize that Java still exists and isn't Solaris. :-/ -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Oct 9 11:11:32 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99IBVVJ024965 for ; Mon, 9 Oct 2006 11:11:31 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99IBU4u028702; Mon, 9 Oct 2006 11:11:30 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k99IBTbf002779; Mon, 9 Oct 2006 11:11:29 -0700 (PDT) Message-ID: <452A90BC.7010207@sun.com> Date: Mon, 09 Oct 2006 11:11:08 -0700 From: David Kahn User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Joseph Kowalski CC: alan.coopersmith@sun.com, James.D.Carlson@sun.com, John.Plocher@sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 67 OpenSolaris is not the only open source project Sun has. -David From sacadmin Mon Oct 9 12:43:22 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99JhMeo026477 for ; Mon, 9 Oct 2006 12:43:22 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k99Jgj34346217; Mon, 9 Oct 2006 12:43:20 -0700 (PDT) Message-Id: <200610091943.k99Jgj34346217@jurassic.eng.sun.com> Date: Mon, 9 Oct 2006 09:42:43 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Joseph.Kowalski@eng.sun.com, David.Kahn@sun.com Cc: alan.coopersmith@sun.com, James.D.Carlson@sun.com, John.Plocher@sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: W5eoM/zfrS/MHX+5OCwfbQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 512 > From: David Kahn ... > OpenSolaris is not the only open source project > Sun has. Yea, but its the only one where the whole community gets to enjoy the pleasure of interacting with PSARC. All the other (current) FOSS projects don't have this privilage. That said, at least indirectly, the nacent open sourcing of Java will need to interact at some level. Its not clear if this will be directly or not. I should have a hand in formulating this in the next couple of months. - jek3 From sacadmin Mon Oct 9 12:52:18 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99JqItZ026740 for ; Mon, 9 Oct 2006 12:52:18 -0700 (PDT) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99JqF8s016859; Mon, 9 Oct 2006 12:52:16 -0700 (PDT) Message-ID: <452AA86F.40904@sun.com> Date: Mon, 09 Oct 2006 12:52:15 -0700 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.5 (X11/20060731) MIME-Version: 1.0 To: Joseph Kowalski CC: James.D.Carlson@sun.com, John.Plocher@sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com, Glynn Foster Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] References: <200610091757.k99Huw8s316883@jurassic.eng.sun.com> In-Reply-To: <200610091757.k99Huw8s316883@jurassic.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 653 Joseph Kowalski wrote: > Isn't X already in PSARC? At least sometimes? (If not, I think this > was just overlooked as an exception.) The X protocol is usually the borderline between PSARC & LSARC. The X server and it's interaction with the kernel/hardware goes to PSARC, the X client libraries and their interfaces provided for use by the desktops (JDS/CDE) usually goes to LSARC. > Do we expect any JDS work on OpenSolaris? All JDS work is being done on OpenSolaris now. We don't expect any JDS work that's not for OpenSolaris. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Mon Oct 9 13:05:01 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99K51Sx027405 for ; Mon, 9 Oct 2006 13:05:01 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k99K4tiG351887; Mon, 9 Oct 2006 13:05:00 -0700 (PDT) Message-Id: <200610092005.k99K4tiG351887@jurassic.eng.sun.com> Date: Mon, 9 Oct 2006 10:04:23 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Joseph.Kowalski@eng.sun.com, alan.coopersmith@sun.com Cc: James.D.Carlson@sun.com, John.Plocher@sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com, Glynn.Foster@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2m6qzZadGhvF4TRQfsgXbA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 796 > From: Alan Coopersmith ... > All JDS work is being done on OpenSolaris now. We don't expect any JDS > work that's not for OpenSolaris. Oh, this is the G-thingie stuff I mentioned in another mail. ie: Solaris specific modifications. Yes, that a good example, but I suspect it will only be Sun employees involved for a long time, because interesting JDS development is done at gnome.org, mozilla.org, etc. JDS is out on OpenSolaris to make our latest and greatest port rapidly available to all OpenSolaris developers. I don't think anyone expects any serious development to come from this. As a matter of fact, we should actively stop serious development with the gentle prod, "Wouldn't it be better to do this at gnome.org?" (for you favorite .org). - jek3 From sacadmin Mon Oct 9 13:23:00 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99KN0Ds028054; Mon, 9 Oct 2006 13:23:00 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k99KN08o028929; Mon, 9 Oct 2006 13:23:00 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99KMtYp004807; Mon, 9 Oct 2006 13:22:55 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6V00L01XWWSI00@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM); Mon, 09 Oct 2006 13:22:55 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6V00DEIXY6W0LG@d1-sfbay-09.sun.com>; Mon, 09 Oct 2006 13:22:55 -0700 (PDT) Date: Mon, 09 Oct 2006 13:23:00 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> Sender: Ed.Gould@Sun.COM To: John Plocher Cc: PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452AAFA4.2090502@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_E2UxGWo4yP9xZlm+V2Zh5w)" References: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1443 This is a multi-part message in MIME format. --Boundary_(ID_E2UxGWo4yP9xZlm+V2Zh5w) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT John Plocher wrote: > Detect "intent mismatches": Open case mail sent to a closed > alias should bounce, closed case mail to an open alias can > be allowed. Use the IAM:Exposure field to identify whether > a case is open or not; use the sac mail filter and /etc/aliases > to tag aliases as open or closed. This doesn't sound right to me. Why is it ok to allow mail for a closed case to an open alias? The other way around (closed mail for an open case) seems safe, but should perhaps be questioned--I can imagine some internal discussion related to an open case being reasonable, but it should not be the norm. For example, discussing the business ramifications of a change that is wanted by the outside community. -- --Ed --Boundary_(ID_E2UxGWo4yP9xZlm+V2Zh5w) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_E2UxGWo4yP9xZlm+V2Zh5w)-- From sacadmin Mon Oct 9 13:38:20 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99KcKIj028184; Mon, 9 Oct 2006 13:38:20 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k99KesZU006864; Mon, 9 Oct 2006 16:40:54 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k99KesNo006861; Mon, 9 Oct 2006 16:40:54 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17706.46037.931565.598063@gargle.gargle.HOWL> Date: Mon, 9 Oct 2006 16:40:53 -0400 From: James Carlson To: Ed Gould Cc: John Plocher , PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <452AAFA4.2090502@sun.com> References: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> <452AAFA4.2090502@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1779 Ed Gould writes: > John Plocher wrote: > > Detect "intent mismatches": Open case mail sent to a closed > > alias should bounce, closed case mail to an open alias can > > be allowed. Use the IAM:Exposure field to identify whether > > a case is open or not; use the sac mail filter and /etc/aliases > > to tag aliases as open or closed. > > This doesn't sound right to me. Why is it ok to allow mail for a closed > case to an open alias? The other way around (closed mail for an open > case) seems safe, but should perhaps be questioned--I can imagine some > internal discussion related to an open case being reasonable, but it > should not be the norm. For example, discussing the business > ramifications of a change that is wanted by the outside community. Each one is bad, but for different reasons. Too many people "reply to all" without bothering to look at the list of recipients. Just one of those accidental closed-mail-for-open-case events is enough to poison the well so that external participants are just plain unable to participate fully. This would be a bad enough event on its own -- but it's also silent! You'd have no good way of knowing that it happened unless someone looked at the cc-list, the case, and said "hey, why isn't that open?" The other failure mode means potentially disclosing internal secrets on an open list. As I expect that there really are few of these must-be-secret cases compared with the must-be-open ones for PSARC, I think erring on the side of openness is a very good thing. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Oct 9 13:49:36 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99Kna4T028346; Mon, 9 Oct 2006 13:49:36 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k99KnUKd362839; Mon, 9 Oct 2006 13:49:35 -0700 (PDT) Message-Id: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> Date: Mon, 9 Oct 2006 10:48:57 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Ed.Gould@sun.com, james.d.carlson@sun.com Cc: plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Vyy65bKrKMEbNK0lvpa/Ww== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 741 > From: James Carlson ... > As I expect that there really are few of these must-be-secret cases > compared with the must-be-open ones for PSARC, I think erring on the > side of openness is a very good thing. The conclusion from Teressa's OpenSolaris process group was that there were to be two kinds of cases: psarc psarc-closed There is no reason to exclude non-Sun OpenSolaris community members from commenting on cases which happen to be funded/staffed by Sun. As a matter of fact, it would be a very good and inclusive thing. So, we should be talking about how to make a case be closed and the default should just be open. We should probably look into a sensitivity training for PSARC members. - jek3 From sacadmin Mon Oct 9 13:57:24 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99KvO6A029002; Mon, 9 Oct 2006 13:57:24 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99KvO5D014408; Mon, 9 Oct 2006 13:57:24 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99KvI4F008990; Mon, 9 Oct 2006 13:57:18 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6V00901ZE22P00@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM); Mon, 09 Oct 2006 13:57:18 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6V00DNAZJICBXI@d1-sfbay-10.sun.com>; Mon, 09 Oct 2006 13:57:18 -0700 (PDT) Date: Mon, 09 Oct 2006 13:57:24 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <17706.46037.931565.598063@gargle.gargle.HOWL> Sender: Ed.Gould@Sun.COM To: James Carlson Cc: John Plocher , PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452AB7B4.2000509@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_4uEbFUdhbRYO4R7XYIYvkw)" References: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> <452AAFA4.2090502@sun.com> <17706.46037.931565.598063@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 2471 This is a multi-part message in MIME format. --Boundary_(ID_4uEbFUdhbRYO4R7XYIYvkw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT James Carlson wrote: > Too many people "reply to all" without bothering to look at the list > of recipients. Just one of those accidental closed-mail-for-open-case > events is enough to poison the well so that external participants are > just plain unable to participate fully. > > This would be a bad enough event on its own -- but it's also silent! > You'd have no good way of knowing that it happened unless someone > looked at the cc-list, the case, and said "hey, why isn't that open?" I agree that this is a potential problem, and that's why I suggested that it be questioned. Maybe I wasn't clear about what I meant. Rather than silently allowing the post to a private list, the poster would have to do something extraordinary to send such a message, such as add a "closed" keyword to the subject. Maybe even require a moderator to look at such postings to confirm that they deserve to be closed. But in some sense, it's not dangerous to Sun's business, in that it does not allow leaking sensitive information. > The other failure mode means potentially disclosing internal secrets > on an open list. > > As I expect that there really are few of these must-be-secret cases > compared with the must-be-open ones for PSARC, I think erring on the > side of openness is a very good thing. Yes, but since the mechanism is there, and the case is already marked closed, why not just bounce a closed-case message for an open list? I agree that the default should be that cases are marked "open," but when one is marked "closed" (which should, perhaps, be more difficult than just answering one question differently - maybe a justification field as well, when closed is chosen), I think we should make it more difficult to let information out about it. -- --Ed --Boundary_(ID_4uEbFUdhbRYO4R7XYIYvkw) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_4uEbFUdhbRYO4R7XYIYvkw)-- From sacadmin Mon Oct 9 14:00:27 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99L0RHO029019; Mon, 9 Oct 2006 14:00:27 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99L0R0t015774; Mon, 9 Oct 2006 14:00:27 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99L0LpG013698; Mon, 9 Oct 2006 14:00:21 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6V00A01ZJYRS00@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM); Mon, 09 Oct 2006 14:00:21 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6V00H1LZOKAKU7@d1-sfbay-10.sun.com>; Mon, 09 Oct 2006 14:00:20 -0700 (PDT) Date: Mon, 09 Oct 2006 14:00:26 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> Sender: Ed.Gould@Sun.COM To: Joseph Kowalski Cc: James.D.Carlson@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452AB86A.30402@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_B5qel4fYn5wk72eyVt6Ycw)" References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1169 This is a multi-part message in MIME format. --Boundary_(ID_B5qel4fYn5wk72eyVt6Ycw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Joseph Kowalski wrote: > So, we should be talking about how to make a case be closed and > the default should just be open. Fundamentally, I agree (and see my direct response to Jim's reply), but I think John is trying to figure out the details of the mechanism to do this. > We should probably look into a sensitivity training for PSARC members. Most of the people I thought needed such training, from the ksh case, weren't members. Some may be employees, though. -- --Ed --Boundary_(ID_B5qel4fYn5wk72eyVt6Ycw) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_B5qel4fYn5wk72eyVt6Ycw)-- From sacadmin Mon Oct 9 14:10:44 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99LAhBr029887; Mon, 9 Oct 2006 14:10:44 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k99LDHTc006997; Mon, 9 Oct 2006 17:13:17 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k99LDHx0006994; Mon, 9 Oct 2006 17:13:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17706.47981.375121.6796@gargle.gargle.HOWL> Date: Mon, 9 Oct 2006 17:13:17 -0400 From: James Carlson To: Joseph Kowalski Cc: Ed.Gould@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1342 Joseph Kowalski writes: > So, we should be talking about how to make a case be closed and > the default should just be open. I strongly agree. Not just "how" but also "if:" it'd be a very good thing if we didn't have to deal with secret cases involving Solaris. Not only will there be much less of a chance of error, but we'll actually be keeping faith with the community. Too bad our ITops security rules don't allow psarc@sun.com to reach external addresses. It'd be much easier to achieve that better default otherwise. Perhaps we could create psarc-closed@sun.com and opensolaris-arc@opensolaris.org instead, and get rid of psarc@sun.com. Or we need a FISA-like court just for secret matters. For what it's worth, we're facing exactly the same problem with all of our Solaris project mailing lists. We want them to be open (which means hosted on opensolaris.org), but there are a lot of people who still post to xxx@sun.com either by accident or (in some cases) due to differing understandings of what being open really means. > We should probably look into a sensitivity training for PSARC members. ;-} -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Oct 9 14:13:10 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99LDAIL000029; Mon, 9 Oct 2006 14:13:10 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99LDALA022077; Mon, 9 Oct 2006 14:13:10 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99LD5DV015265; Mon, 9 Oct 2006 14:13:05 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6W0080107SFK00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 09 Oct 2006 14:13:05 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6W00DP309OW0TG@d1-sfbay-09.sun.com>; Mon, 09 Oct 2006 14:13:04 -0700 (PDT) Date: Mon, 09 Oct 2006 14:13:00 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452AAFA4.2090502@sun.com> Sender: John.Plocher@Sun.COM To: Ed Gould Cc: John Plocher , PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452ABB5C.5080409@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> <452AAFA4.2090502@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 1162 +-- Ed Gould wrote On 10/09/06 13:23,: > This doesn't sound right to me. Why is it ok to allow mail for a closed Because the content of the email can be presumed to be public because the sender sent it to an "open" alias, and the mail is seen by all participants,inside and outside Sun. Use cases include "Please open up this historical case". I'm not sure there are good examples of community interaction while a closed case is being reviewed, since the materials are not exposed... > case to an open alias? The other way around (closed mail for an open > case) seems safe, but should perhaps be questioned--I can imagine some The reason for this is that the mail log of the open case (including all such "closed comments") is exposed on opensolaris.org's case archive mirror. > internal discussion related to an open case being reasonable, but it > should not be the norm. For example, discussing the business > ramifications of a change that is wanted by the outside community. This could happen on the PSARC alias *without* the case number being included in the Subject: line. -- John Plocher SAC Processes and Tools MPK17-3674 x87604 From sacadmin Mon Oct 9 14:15:14 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99LFEGI000047; Mon, 9 Oct 2006 14:15:14 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k99LHmID007003; Mon, 9 Oct 2006 17:17:48 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k99LHmp1007000; Mon, 9 Oct 2006 17:17:48 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17706.48252.343853.3563@gargle.gargle.HOWL> Date: Mon, 9 Oct 2006 17:17:48 -0400 From: James Carlson To: Ed Gould Cc: John Plocher , PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <452AB7B4.2000509@sun.com> References: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> <452AAFA4.2090502@sun.com> <17706.46037.931565.598063@gargle.gargle.HOWL> <452AB7B4.2000509@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2359 Ed Gould writes: > James Carlson wrote: > > This would be a bad enough event on its own -- but it's also silent! > > You'd have no good way of knowing that it happened unless someone > > looked at the cc-list, the case, and said "hey, why isn't that open?" > > I agree that this is a potential problem, and that's why I suggested > that it be questioned. Maybe I wasn't clear about what I meant. Rather > than silently allowing the post to a private list, the poster would have > to do something extraordinary to send such a message, such as add a > "closed" keyword to the subject. Maybe even require a moderator to look > at such postings to confirm that they deserve to be closed. But in some > sense, it's not dangerous to Sun's business, in that it does not allow > leaking sensitive information. I think that part is incorrect. It's corrosive to the Open Solaris process to allow development discussions to go on in private. As the success of the Open Solaris process itself is _crucial_ for Sun's business, it is most certainly dangerous if Open Solaris participants get the wrong idea about what we're doing here. Advocates of other operating systems don't need to get a toe-hold on our turf. If we hide what we're working on, we're just handing them loaded weapons. > Yes, but since the mechanism is there, and the case is already marked > closed, why not just bounce a closed-case message for an open list? Sure ... that's one of the possibilities. But it seems like it's potentially unnecessarily restrictive. How do Open Solaris participants, who can see the code and can see the verision information that includes the case names and numbers, ever discuss the cases if we bounce the email? > I agree that the default should be that cases are marked "open," but > when one is marked "closed" (which should, perhaps, be more difficult > than just answering one question differently - maybe a justification > field as well, when closed is chosen), I think we should make it more > difficult to let information out about it. Maybe. I'm just not quite seeing the usage case for "closed" so clearly. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Mon Oct 9 14:23:12 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99LNBXC000528; Mon, 9 Oct 2006 14:23:11 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k99LNB90027477; Mon, 9 Oct 2006 14:23:11 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99LN6q9016511; Mon, 9 Oct 2006 14:23:06 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6W00M010Q7RE00@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM); Mon, 09 Oct 2006 14:23:06 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6W00DZR0QHVO7J@d1-sfbay-09.sun.com>; Mon, 09 Oct 2006 14:23:05 -0700 (PDT) Date: Mon, 09 Oct 2006 14:23:11 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452ABB5C.5080409@Sun.COM> Sender: Ed.Gould@Sun.COM To: John Plocher Cc: John Plocher , PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452ABDBF.6010903@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_CkqgwZ+XICIAg9NJFd/tqQ)" References: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> <452AAFA4.2090502@sun.com> <452ABB5C.5080409@Sun.COM> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1924 This is a multi-part message in MIME format. --Boundary_(ID_CkqgwZ+XICIAg9NJFd/tqQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT John Plocher wrote: > +-- Ed Gould wrote On 10/09/06 13:23,: >> This doesn't sound right to me. Why is it ok to allow mail for a closed > > Because the content of the email can be presumed to be public because > the sender sent it to an "open" alias, and the mail is seen by all > participants,inside and outside Sun. I guess so. > Use cases include "Please open up this historical case". I would prefer that such cases not be marked "closed" but either be left unmarked or marked something like "unopened." I guess I'd like the "closed" mark to actually mean something. That said, it should not be easy to mark a case closed. > I'm not sure there are good examples of community interaction > while a closed case is being reviewed, since the materials are > not exposed... > >> case to an open alias? The other way around (closed mail for an open >> case) seems safe, but should perhaps be questioned--I can imagine some > > The reason for this is that the mail log of the open case (including > all such "closed comments") is exposed on opensolaris.org's case > archive mirror. Hmm. I guess I was imagining mail that wouldn't go to the case log, or might go to a parallel internal log that isn't mirrored. -- --Ed --Boundary_(ID_CkqgwZ+XICIAg9NJFd/tqQ) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_CkqgwZ+XICIAg9NJFd/tqQ)-- From sacadmin Mon Oct 9 14:26:28 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99LQSoq000852; Mon, 9 Oct 2006 14:26:28 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k99LQRe7029264; Mon, 9 Oct 2006 14:26:27 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99LQMc3016926; Mon, 9 Oct 2006 14:26:22 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6W002010TURP00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 09 Oct 2006 14:26:22 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6W00DT70VVW0VG@d1-sfbay-09.sun.com>; Mon, 09 Oct 2006 14:26:22 -0700 (PDT) Date: Mon, 09 Oct 2006 14:26:18 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> Sender: John.Plocher@Sun.COM To: Joseph Kowalski Cc: Ed.Gould@Sun.COM, James.D.Carlson@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452ABE7A.9060700@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 1040 +-- Joseph Kowalski wrote On 10/09/06 13:48,: > So, we should be talking about how to make a case be closed and > the default should just be open. Virtual yesterday the default (and only implemented behavior) was closed. Today, we are attempting to design/implement a mechanism whereby things *can* be open. There are still unsolved issues relating to identifying and training external ARC interns and members, infrastructure to support external submission of fasttracks and onepagers, etc. Without these, we can't be completely open for all use cases, so a policy of default=closed still makes sense. Virtual tomorrow, we _will_ have the mechanisms in place for things to choose to be either open or closed. There may even be pre-completion milestones where it makes sense to reassess the default policy. At that point, we can have a profitable discussion as to how and when we should transition the default to open. My vote will be for "as soon as the infrastructure and SMI (not just OPG) policy support doing so". -John From sacadmin Mon Oct 9 15:48:27 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99MmR8r008635; Mon, 9 Oct 2006 15:48:27 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99MmPHB008452; Mon, 9 Oct 2006 15:48:26 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119] (may be forged)) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99MmKP2027569; Mon, 9 Oct 2006 23:48:20 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6W009014MMJU00@d1-emea-09.sun.com> (original mail from Glynn.Foster@Sun.COM); Mon, 09 Oct 2006 23:48:20 +0100 (BST) Received: from [192.9.61.46] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6W00JTE4O1MMXV@d1-emea-09.sun.com>; Mon, 09 Oct 2006 23:48:19 +0100 (BST) Date: Mon, 09 Oct 2006 22:47:52 +0000 From: Glynn Foster Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <17706.47981.375121.6796@gargle.gargle.HOWL> Sender: Glynn.Foster@Sun.COM To: James Carlson Cc: Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452AD198.6000207@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0a1 (X11/20060925) Status: RO Content-Length: 1385 James Carlson wrote: > Joseph Kowalski writes: > >> So, we should be talking about how to make a case be closed and >> the default should just be open. >> > > I strongly agree. Not just "how" but also "if:" it'd be a very good > thing if we didn't have to deal with secret cases involving Solaris. > Not only will there be much less of a chance of error, but we'll > actually be keeping faith with the community. > > Too bad our ITops security rules don't allow psarc@sun.com to reach > external addresses. It'd be much easier to achieve that better > default otherwise. > > Perhaps we could create psarc-closed@sun.com and > opensolaris-arc@opensolaris.org instead, and get rid of psarc@sun.com. > Should this thread not be a discussion on arc-discuss@opensolaris.org? As a casual observer, I actually like this suggestion a whole lot better - not only does it seem intuitive, it also feels like a much more open process rather than us trying to retro-fit what everyone is used to. It also has the added value of being able to archive, internally or externally [1], by subscribing an alias which feeds into the script with appropriate options nothing of which would seem to violate ITops security rules. Glynn [1] Though I have worries that if we continually archive the open cases internally as well, it sort of feels like we're playing in a different sandbox still From sacadmin Mon Oct 9 16:22:04 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99NM493011092; Mon, 9 Oct 2006 16:22:04 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k99NM3pB024456; Mon, 9 Oct 2006 16:22:03 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99NLwGu026096; Mon, 9 Oct 2006 16:21:58 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6W00C0166KV400@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 09 Oct 2006 16:21:58 -0700 (PDT) Received: from [129.146.59.228] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6W00DZ768HW0GH@d1-sfbay-09.sun.com>; Mon, 09 Oct 2006 16:21:58 -0700 (PDT) Date: Mon, 09 Oct 2006 16:21:49 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452AD198.6000207@sun.com> Sender: John.Plocher@Sun.COM To: Glynn Foster Cc: James Carlson , Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452AD98D.60405@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452AD198.6000207@sun.com> User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) Status: RO Content-Length: 2491 Glynn Foster wrote > Should this thread not be a discussion on arc-discuss@opensolaris.org? > Not these specifics - they concern details of how the internal SAC infrastructure needs to change. Note that this discussion is narrowly focused on the mechanisms used by PSARC/SAC, even though Joe and others seem to be trying to expand the scope to include the "default=closed/open" bit. > As a casual observer, I actually like this suggestion a whole lot better > - not only does it seem intuitive, it also feels like a much more open > process rather than us trying to retro-fit what everyone is used to. It > We are NOT at the point where we can implement "open=default" - see my previous email. Other than that, what is the difference between this suggestion and the proposal on the table? IMO, they are effectively the same, with this one taking a smaller step at first. The downside of using "opensolaris-arc@os.o" for both a subscriber list and a gateway into the sac email tools is that we lose the ability to validate (aka bounce) invalid submissions before they get sent out to (some of) the community. The proposal on the table is to keep the two functions distinct: ARC mail goes to psarc@opensolaris.org Community members wishing to subscribe to the ARC discussion list do so by subscribing to opensolaris-arc@opensolaris.org All the stuff discussed here fits in between those two aliases, and is an implementation detail from the community's perspective. Of course, the names are not set in stone - this would still work if we had ARC mail goes to opensolaris-arc@opensolaris.org Community members wishing to subscribe to the ARC discussion list do so by subscribing to opensolaris-arc-interest@opensolaris.org > also has the added value of being able to archive, internally or > externally [1], by subscribing an alias which feeds into the script with > appropriate options nothing of which would seem to violate ITops > security rules. > The current proposal does this. > [1] Though I have worries that if we continually archive the open cases > internally as well, it sort of feels like we're playing in a different > sandbox still > There is no mechanism on opensolaris.org to cause specific threads on an alias to be archived in a project-specific archive, giving us no alternative. In addition, giving up the internal mirror would mean that all our internal metrics/scripts/workflows would break. -John From sacadmin Mon Oct 9 16:30:19 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k99NUJNK011161; Mon, 9 Oct 2006 16:30:19 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k99NUJse003438; Mon, 9 Oct 2006 16:30:19 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k99NUEZ6001189; Mon, 9 Oct 2006 16:30:14 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6W002016KDFW00@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM); Mon, 09 Oct 2006 16:30:14 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6W00HOE6MDAKY7@d1-sfbay-10.sun.com>; Mon, 09 Oct 2006 16:30:13 -0700 (PDT) Date: Mon, 09 Oct 2006 16:30:20 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452AD98D.60405@Sun.Com> Sender: Ed.Gould@Sun.COM To: John Plocher Cc: Glynn Foster , James Carlson , Joseph Kowalski , plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452ADB8C.4070303@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_4sgx6UZk1IreJNx3/HJI6Q)" References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452AD198.6000207@sun.com> <452AD98D.60405@Sun.Com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1410 This is a multi-part message in MIME format. --Boundary_(ID_4sgx6UZk1IreJNx3/HJI6Q) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT John Plocher wrote: > Note that this discussion is narrowly focused on the mechanisms used by > PSARC/SAC, even though > Joe and others seem to be trying to expand the scope to include the > "default=closed/open" bit. Except that the behavior seems to depend on the valoe of that field. Further, I'm not convinced that it should be a binary field, and the behavior definitely depends on the value of that field. In particular, I see value in distinguishing between cases that are explicitly marked "closed" and those that were historically unmarked (perhaps these should become "unopened"). In the short term, "unopened" would function the same as "closed," but in the long term it might be different. -- --Ed --Boundary_(ID_4sgx6UZk1IreJNx3/HJI6Q) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_4sgx6UZk1IreJNx3/HJI6Q)-- From sacadmin Mon Oct 9 17:10:37 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9A0Abs1012133; Mon, 9 Oct 2006 17:10:37 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9A0AbMO008155; Mon, 9 Oct 2006 17:10:37 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9A0AWuG000523; Mon, 9 Oct 2006 17:10:32 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6W00I018DJYA00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 09 Oct 2006 17:10:32 -0700 (PDT) Received: from [129.146.59.11] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6W00DY88HJVO0K@d1-sfbay-09.sun.com>; Mon, 09 Oct 2006 17:10:31 -0700 (PDT) Date: Mon, 09 Oct 2006 17:10:27 -0700 From: John Plocher Subject: IAM:Exposure values - Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452ADB8C.4070303@sun.com> Sender: John.Plocher@Sun.COM To: Ed Gould Cc: Glynn Foster , James Carlson , Joseph Kowalski , plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452AE4F3.30108@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452AD198.6000207@sun.com> <452AD98D.60405@Sun.Com> <452ADB8C.4070303@sun.com> User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) Status: RO Content-Length: 2735 Ed Gould wrote: > John Plocher wrote: >> Note that this discussion is narrowly focused on the mechanisms used >> by PSARC/SAC, even though >> Joe and others seem to be trying to expand the scope to include the >> "default=closed/open" bit. > > Except that the behavior seems to depend on the valoe of that field. > Further, I'm not convinced that it should be a binary field, and the > behavior definitely depends on the value of that field. If the case is (!open), it is inappropriate for Sun people to discuss its details with outsiders. We will always have cases like this, though everyone expects the frequency to drop quickly over time for some subsets of Sun's internal development community. From a communication perspective, you are either having an open conversation or a closed one. Thus the binary nature of the alias discussion - either open @ -ext/opensolaris.org or closed. > > In particular, I see value in distinguishing between cases that are > explicitly marked "closed" and those that were historically unmarked > (perhaps these should become "unopened"). In the short term, > "unopened" would function the same as "closed," but in the long term > it might be different. This is a good idea, capturing the "we made an explicit decision to close this" bit. Practically, though, I'm not sure there is any real difference between that and "the case happened when everything was closed and we have not spent any resources to make it open". That is, an application of scrubbing resources can change either to an "open" state. I'll fold this suggestion into the proposal: A case's IAM file may contain an "Exposure" entry to indicate whether the case and its materials can be exposed outside of Sun: Exposure: [open|closed|manual] For cases that do not have an explicit IAM:Exposure line, their state will default to be "unknown". For publishing/disclosure purposes, "unknown" cases shall be treated as if they were "closed". It is an error for a case's IAM file to explicitly contain "Exposure: unknown" Cases marked "closed" are marked that way because there is some explicit reason as to why they can not be exposed. There should be an IAM:Comment that describes why this case is closed and what (if any) actions c/would trigger a change. Cases marked "open" imply that everything in the case directory (with the exception of the "uirb" and "sc" subdirs) is appropriate for unrestricted disclosure to external-to-sun communities. Cases marked "manual" imply that some details about the case can be made public; in general, those things are contained in files that have "opensolaris" in their name. -John From sacadmin Mon Oct 9 17:10:58 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9A0AwgS012150; Mon, 9 Oct 2006 17:10:58 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9A0AuJM008351; Mon, 9 Oct 2006 17:10:57 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9A0Apa5020382; Tue, 10 Oct 2006 01:10:51 +0100 (BST) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6W00B018FUIQ00@d1-emea-10.sun.com> (original mail from Glynn.Foster@Sun.COM); Tue, 10 Oct 2006 01:10:51 +0100 (BST) Received: from [192.9.61.46] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6W00JS68HMCXMI@d1-emea-10.sun.com>; Tue, 10 Oct 2006 01:10:51 +0100 (BST) Date: Tue, 10 Oct 2006 00:10:25 +0000 From: Glynn Foster Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452AD98D.60405@Sun.Com> Sender: Glynn.Foster@Sun.COM To: John Plocher Cc: James Carlson , Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452AE4F1.5010808@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452AD198.6000207@sun.com> <452AD98D.60405@Sun.Com> User-Agent: Thunderbird 2.0a1 (X11/20060925) Status: RO Content-Length: 2025 John Plocher wrote: >> As a casual observer, I actually like this suggestion a whole lot better >> - not only does it seem intuitive, it also feels like a much more open >> process rather than us trying to retro-fit what everyone is used to. It >> > We are NOT at the point where we can implement "open=default" - see my > previous email. While I agree that we're not in the position for community members to contribute their own cases, I'm not get why we're not in a position for open=default. I would have assumed that project teams would have already made the call, separate to ARC, as to whether their project was going to be public or not. > The downside of using "opensolaris-arc@os.o" for both a subscriber > list and a gateway into the > sac email tools is that we lose the ability to validate (aka bounce) > invalid submissions before they > get sent out to (some of) the community. Yeah, that's probably an important requirement if closed=default. However, by making psarc@opensolaris.org an alias, then you effectively open it up to spam, and don't have the moderation facility that mailman provides. Either way - at this stage, whichever works and as long as the proposal gives you the ability of switching over in future, then that's ok with me. >> [1] Though I have worries that if we continually archive the open cases >> internally as well, it sort of feels like we're playing in a different >> sandbox still >> > > There is no mechanism on opensolaris.org to cause specific threads on > an alias to be archived in > a project-specific archive, giving us no alternative. In addition, > giving up the internal mirror would > mean that all our internal metrics/scripts/workflows would break. No reason though that the sac-mail-filter script couldn't be run on the opensolaris.org server - though, you'd have the added complication of trying to sync the case numbers. You could argue that breaking the metrics/scripts/workflows may be a step closer to an open development environment. Glynn From sacadmin Mon Oct 9 17:34:17 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9A0YHV2012404; Mon, 9 Oct 2006 17:34:17 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9A0YHS5023277; Mon, 9 Oct 2006 17:34:17 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9A0YBJB002227; Mon, 9 Oct 2006 17:34:12 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6W00H019IK6S00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 09 Oct 2006 17:34:11 -0700 (PDT) Received: from [129.146.59.11] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6W00D7Z9KZVO4K@d1-sfbay-09.sun.com>; Mon, 09 Oct 2006 17:34:11 -0700 (PDT) Date: Mon, 09 Oct 2006 17:34:07 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452AE4F1.5010808@sun.com> Sender: John.Plocher@Sun.COM To: Glynn Foster Cc: James Carlson , Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452AEA7F.8060505@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452AD198.6000207@sun.com> <452AD98D.60405@Sun.Com> <452AE4F1.5010808@sun.com> User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) Status: RO Content-Length: 1661 Glynn Foster wrote: > While I agree that we're not in the position for community members to > contribute their own cases, I'm not get why we're not in a position for > open=default. I would have assumed that project teams would have already > made the call, separate to ARC, as to whether their project was going to > be public or not. > > This is not a technical decision, it is an executive discussion that has not yet reached closure because (IMO) the Solaris-PAC/OPG has not done a good job of managing the CAP associated with this change; there are still significant parts of Sun that are not bought into the fact that their stuff going into an open sourced system (think new platforms/ and devices). Some of this is foolishness, but some is not,; it may require the development of some sort of "closed until putback" scheme, which (IMHO) would be an unmitigated disaster WRT an open ARC process... > Yeah, that's probably an important requirement if closed=default. > However, by making psarc@opensolaris.org an alias, then you effectively > open it up to spam, and don't have the moderation facility that mailman > provides. > > Mail to xxx@sun.com goes thru Sun's spam filters, so I'm not too worried about it. > > No reason though that the sac-mail-filter script couldn't be run on the > opensolaris.org server - though, you'd have the added complication of > trying to sync the case numbers. > > Except that it can't be run on os.o due to lots of IT/OPS issues. > You could argue that breaking the metrics/scripts/workflows may be a > step closer to an open development environment. > > You could so argue; I won't. -John From sacadmin Tue Oct 10 03:48:11 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AAmBF0023495; Tue, 10 Oct 2006 03:48:11 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9AAmAss003911; Tue, 10 Oct 2006 03:48:10 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AAm400000331; Tue, 10 Oct 2006 11:48:04 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00E011XX6S00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 10 Oct 2006 11:48:04 +0100 (BST) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00A68203T910@d1-emea-09.sun.com>; Tue, 10 Oct 2006 11:48:04 +0100 (BST) Date: Tue, 10 Oct 2006 11:48:01 +0100 From: Darren J Moffat Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <17706.47981.375121.6796@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452B7A61.5010900@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060828) Status: RO Content-Length: 1137 James Carlson wrote: > Joseph Kowalski writes: >> So, we should be talking about how to make a case be closed and >> the default should just be open. > > I strongly agree. Not just "how" but also "if:" it'd be a very good > thing if we didn't have to deal with secret cases involving Solaris. > Not only will there be much less of a chance of error, but we'll > actually be keeping faith with the community. > > Too bad our ITops security rules don't allow psarc@sun.com to reach > external addresses. It'd be much easier to achieve that better > default otherwise. > > Perhaps we could create psarc-closed@sun.com and > opensolaris-arc@opensolaris.org instead, and get rid of psarc@sun.com. I like this too and I think this is where we should be aiming for in the first step. If that means we need more advanced mail filtering on the mail server that runs the @opensolaris.org aliases then so be it that is what we should do. I personally don't see any value in the interim step given how much of an email disaster the PSARC-EXT cases have been (not the technical discussion part but the email part). -- Darren J Moffat From sacadmin Tue Oct 10 11:25:48 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AIPmLe007016; Tue, 10 Oct 2006 11:25:48 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9AIPmL8023913; Tue, 10 Oct 2006 11:25:48 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AIPg24001049; Tue, 10 Oct 2006 11:25:42 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00001N5H9B00@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Tue, 10 Oct 2006 11:25:42 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00DLFN6OCBNN@d1-sfbay-10.sun.com>; Tue, 10 Oct 2006 11:25:39 -0700 (PDT) Date: Tue, 10 Oct 2006 11:25:36 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452B7A61.5010900@Sun.COM> Sender: John.Plocher@Sun.COM To: Darren J Moffat Cc: James Carlson , Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452BE5A0.3040308@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 775 +-- Darren J Moffat wrote On 10/10/06 03:48,: > I personally don't see any value in the interim step given how much of > an email disaster the PSARC-EXT cases have been (not the technical > discussion part but the email part). I don't have a problem with replacing "psarc@sun" with "psarc-closed@sun", nor with creating an alias on opensolaris.org for the open arc efforts. But, I'm not sure doing so would have prevented the problems we saw with the ksh case That is, how would have this alternative changed anything about the ksh case's email volume? Or the moderation hell caused by the general opensolaris.org ruleset that said "moderate all mail from people not directly subscribed to this alias"? -- John Plocher SAC Processes and Tools MPK17-3674 x87604 From sacadmin Tue Oct 10 11:39:52 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AIdqK3007576; Tue, 10 Oct 2006 11:39:52 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9AIgRBX010141; Tue, 10 Oct 2006 14:42:27 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9AIgRhw010138; Tue, 10 Oct 2006 14:42:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17707.59794.895953.184663@gargle.gargle.HOWL> Date: Tue, 10 Oct 2006 14:42:26 -0400 From: James Carlson To: John Plocher Cc: Darren J Moffat , Joseph Kowalski , Ed.Gould@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <452BE5A0.3040308@Sun.COM> References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> <452BE5A0.3040308@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1067 John Plocher writes: > with the ksh case That is, how would have this alternative > changed anything about the ksh case's email volume? Or I don't think it would. > the moderation hell caused by the general opensolaris.org > ruleset that said "moderate all mail from people not > directly subscribed to this alias"? I think that part can be fixed only by making sure there's exactly one alias to which people both subscribe and send mail. I think that could be accomplished if the opensolaris.org script were smart enough to: - add a header tag and forward to open-arc-inbound@sac.sfbay, where the rest of the work is done and then ... - forward back out to opensolaris-arc@opensolaris.org, where the tag is detected, and the email sent to the list rather than the filter. Bonus points for making the tag unforgeable. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Oct 10 11:45:10 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AIjAeB007954; Tue, 10 Oct 2006 11:45:10 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9AIj8Jh004394; Tue, 10 Oct 2006 11:45:09 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AIj3uw012768; Tue, 10 Oct 2006 19:45:03 +0100 (BST) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00G01O10BY00@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 10 Oct 2006 19:45:03 +0100 (BST) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X002D2O2FBP20@d1-emea-10.sun.com>; Tue, 10 Oct 2006 19:45:02 +0100 (BST) Date: Tue, 10 Oct 2006 19:44:36 +0100 From: Darren J Moffat Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452BE5A0.3040308@Sun.COM> Sender: Darren.Moffat@Sun.COM To: John Plocher Cc: James Carlson , Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452BEA14.70509@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> <452BE5A0.3040308@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060828) Status: RO Content-Length: 1333 John Plocher wrote: > > > +-- Darren J Moffat wrote On 10/10/06 03:48,: >> I personally don't see any value in the interim step given how much of >> an email disaster the PSARC-EXT cases have been (not the technical >> discussion part but the email part). > > I don't have a problem with replacing "psarc@sun" with > "psarc-closed@sun", nor with creating an alias on > opensolaris.org for the open arc efforts. But, I'm > not sure doing so would have prevented the problems we saw > with the ksh case That is, how would have this alternative > changed anything about the ksh case's email volume? Or > the moderation hell caused by the general opensolaris.org > ruleset that said "moderate all mail from people not > directly subscribed to this alias"? > Part of the problem in the ksh case was because of the ksh alias and part of it was because of implicit redirects. The ksh alias problem would have been solved if the functionality that several people have been asking for was implemented on opensolaris.org. That is make mail work like the forums do - anyone who is an opensolaris.org registered member can post to any mail list - since they already can by using the forums anyway. If we were only using @opensolaris.org mail aliases that problem wouldn't exist if the above was present. -- Darren J Moffat From sacadmin Tue Oct 10 12:21:03 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AJL2sX009488; Tue, 10 Oct 2006 12:21:02 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AJKv42016513; Tue, 10 Oct 2006 12:21:02 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AJKqKU012306; Tue, 10 Oct 2006 12:20:52 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00D01PJZG300@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Tue, 10 Oct 2006 12:20:52 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00D18PQPCB0O@d1-sfbay-10.sun.com>; Tue, 10 Oct 2006 12:20:52 -0700 (PDT) Date: Tue, 10 Oct 2006 12:20:49 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <17707.59794.895953.184663@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: Darren J Moffat , Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452BF291.5000307@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> <452BE5A0.3040308@Sun.COM> <17707.59794.895953.184663@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 2240 +-- James Carlson wrote On 10/10/06 11:42,: > I think that part can be fixed ... I do not believe that there is any way to put such a filter in place *on* os.o, nor do I think that it is the right long term answer. Lets step back a bit and remember that the current open subscriber "opensolaris-arc@opensolaris.org" alias is *really* only a misnamed "open-arc-interest@" alias. Among the things it is not: It is not open-arc-member-list@ It is not open-arc-intern-list@ It is not open-arc-licensee-list@ It is not even "voting-members-of-open-arc-community@" It is not open-arc-onepager-submissions@" It is not open-arc-fasttrack-submissions@" A "complete" open-arc proposal needs to address all of these roles and workflows. Looking at things this way, I think we are moving towards the following (names open to change, of course): open-arc-member-list@ => the list of PSARC members who are active (as core contributers) to an OpenSolaris community. They are the ones who have the voting rights for open ARC decisions. It may be that, as a transition plan, current PSARC members who are not involved as leaders of opensolaris communities are grandfathered as members. open-arc-intern-list@ => the list of PSARC interns and Community members who wish to play an active role in "open ARC", but who do not get to vote. open-arc-interest-list@ => Anyone who wishes to "listen in" and join in the discussions, but who don't get a vote. open-arc-licensee-list@ => the current list of "sponsors" (which seems to be disjoint from PSARC-licensees...) open-arc@ => this proposal's filtering script with the "--policy=open" flag set, forwarding on to the set of open-arc-member-list@ open-arc-intern-list@ open-arc-interest-list@ as well as IAM:Interest lists on a per-case basis Thoughts? -John PS - In my opinion, the membership of the "open ARC" *should* be (as a future goal) the set of every OpenSolaris Community's core contributers, modulo the training/indoctrination represented by internship/licensee status. That is, the communities themselves should be responsible for the evolution and management of their creations. It is still an open question of how to get there from where we are at today. From sacadmin Tue Oct 10 12:40:06 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AJe6PQ009980; Tue, 10 Oct 2006 12:40:06 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9AJgfI8010496; Tue, 10 Oct 2006 15:42:41 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9AJgf9H010493; Tue, 10 Oct 2006 15:42:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17707.63408.889352.768514@gargle.gargle.HOWL> Date: Tue, 10 Oct 2006 15:42:40 -0400 From: James Carlson To: John Plocher Cc: Darren J Moffat , Joseph Kowalski , Ed.Gould@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <452BF291.5000307@Sun.COM> References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> <452BE5A0.3040308@Sun.COM> <17707.59794.895953.184663@gargle.gargle.HOWL> <452BF291.5000307@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2419 John Plocher writes: > I do not believe that there is any way to put such a filter in > place *on* os.o, nor do I think that it is the right long term > answer. There needs to be some list to which one can send mail to discuss a case. Currently, on opensolaris.org, you need to subscribe to a list in order to post to it. In order to get to a world with multiple lists, that second part needs to be fixed, so this proposal seems (to me at least) to be contingent on a fix. > A "complete" open-arc proposal needs to address all of these > roles and workflows. It needs to reflect the relevant ones, yes. > open-arc-licensee-list@ => the current list of "sponsors" > (which seems to be disjoint from PSARC-licensees...) Though I mostly agree with the breakdown you gave, I'm not sure I understand that parenthetic comment. The licensee list is supposed to be the list of sponsors other than interns or members, who are automatically also sponsors. If it's not that for PSARC, then please let the chair know so that the lists can be fixed. > open-arc@ => this proposal's filtering script with the > "--policy=open" flag set, forwarding on to the set of [...] > Thoughts? That works only if opensolaris.org gets fixed. :-/ > PS - In my opinion, the membership of the "open ARC" *should* be (as > a future goal) the set of every OpenSolaris Community's core > contributers, modulo the training/indoctrination represented by > internship/licensee status. That is, the communities themselves > should be responsible for the evolution and management of their > creations. I'm not quite sure what you're saying here. What are "core contributors?" I think the ARC process (including membership) needs to be disjoint from the current "Community Leader" process, because the latter is just plain haphazard. There's no real rhyme or reason to the membership, which isn't the way I think this ought to work. For instance, take a look at the list of networking community leaders. If it's really to be bound up with the list of Community Leaders (as I'm guessing you _might_ mean), then the mess of web site change permission and leader identification really needs to be sorted out first. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Oct 10 13:00:17 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AK0G62010737; Tue, 10 Oct 2006 13:00:16 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AK0GUj005483; Tue, 10 Oct 2006 13:00:16 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AK0BcI016894; Tue, 10 Oct 2006 13:00:11 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00701RGUKH00@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Tue, 10 Oct 2006 13:00:11 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00DQ5RK6CB5O@d1-sfbay-10.sun.com>; Tue, 10 Oct 2006 13:00:11 -0700 (PDT) Date: Tue, 10 Oct 2006 13:00:06 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <17707.63408.889352.768514@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: Darren J Moffat , Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452BFBC6.1020500@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> <452BE5A0.3040308@Sun.COM> <17707.59794.895953.184663@gargle.gargle.HOWL> <452BF291.5000307@Sun.COM> <17707.63408.889352.768514@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 4041 +-- James Carlson wrote On 10/10/06 12:42,: > John Plocher writes: > There needs to be some list to which one can send mail to discuss a That list *should* be open-arc@opensolaris.org (or whatever name we end up with...) > case. Currently, on opensolaris.org, you need to subscribe to a list > in order to post to it. This has been changed as a result of the ksh case (so I have been told). Subscription to *any* os.o alias gives you unmoderated posting ability to any other os.o alias. In addition, mail from the sac mail filter account is also allowed. >>PS - In my opinion, the membership of the "open ARC" *should* be (as >>a future goal) the set of every OpenSolaris Community's core >>contributers, modulo the training/indoctrination represented by >>internship/licensee status. That is, the communities themselves >>should be responsible for the evolution and management of their >>creations. > > > I'm not quite sure what you're saying here. What are "core > contributors?" See http://www.genunix.org/wiki/index.php/OpenSolaris_Governance_Draft_02#ARTICLE_IIIa.__Structure.2C_Participation.2C_and_Roles 3.3. Roles. Various terms are used to describe the people who are involved in the OpenSolaris Community efforts, based on their recognized contributions, length of commitment, and current activity. The OpenSolaris Community recognizes four classes of levels of involvement by registered persons: 1. Participant. Any registered person who participates in the OpenSolaris Community, either through general discussion areas or within one or more Community Group efforts, shall be termed an OpenSolaris Participant. 2. Contributor. A participant who has been acknowledged by one or more OpenSolaris Community Groups as having substantively contributed toward accomplishing the tasks of that Community Group, or by the OGB for at-large contributions, shall be termed an OpenSolaris Contributor. Such designation is permanent and persists regardless of the person's current level of activity or status within the OpenSolaris Community. A Contributor may request that their status not be published or published only in the form of a pseudonym that is unique within the Community. 3. Core Contributor. A Contributor who accepts recognition by any OpenSolaris Community Group as being an active and sustained contributor to said Group shall be termed a Core Contributor for said Group and granted the status of "Voting Member" Member for the OpenSolaris Community as a whole. 4. Emeritus Contributor. A former Core Contributor whose prior grants of Core Contributor status have all expired, or who has voluntarily resigned from Core Contributor status by declining all grants, is termed an OpenSolaris Emeritus Contributor. The Emeritus Contributor class is a designation of respect for Core Contributors who have moved on to activities outside the OpenSolaris Community or who are temporarily unable to perform the duties of a Voting Member. An Emeritus Contributor can return to Core Contributor status by acquiring and accepting new grants. > > I think the ARC process (including membership) needs to be disjoint > from the current "Community Leader" process, because the latter is > just plain haphazard. There's no real rhyme or reason to the > membership, which isn't the way I think this ought to work. > > For instance, take a look at the list of networking community leaders. > > If it's really to be bound up with the list of Community Leaders (as > I'm guessing you _might_ mean), then the mess of web site change > permission and leader identification really needs to be sorted out > first. > It is, and I agree (thus my comment of it being an open question...) In the (perfect) future, the open-arc-member-list is a constructed alias made up of all the various community-core-contributers. We (and the os.o web site/community structure/...) are a long way away from that point right now. -- John Plocher SAC Processes and Tools MPK17-3674 x87604 From sacadmin Tue Oct 10 13:02:56 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AK2u3S010780; Tue, 10 Oct 2006 13:02:56 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9AK2oMe664376; Tue, 10 Oct 2006 13:02:55 -0700 (PDT) Message-Id: <200610102002.k9AK2oMe664376@jurassic.eng.sun.com> Date: Tue, 10 Oct 2006 10:02:14 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Joseph.Kowalski@eng.sun.com, Ed.Gould@sun.com Cc: James.D.Carlson@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HyV0CgcFITbv1vTlmU2zPA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1123 > From: Ed Gould ... > Joseph Kowalski wrote: ... > > We should probably look into a sensitivity training for PSARC members. > > Most of the people I thought needed such training, from the ksh case, > weren't members. Some may be employees, though. Yea, wasn't this a surprize? 8^( Actually, it wasn't much of a surprize. I think to FOSS community is perhaps 10% just flamers who have nothing else to contribute. There were definately 2 such masses of protoplasm in the ksh discussion. It will be quite awhile before I remove the "Felix Filter" from my configuration. Although my original comment should have had a smiley, there is a bit of truth to it - but its not due to abusive behavior. We need to be sensitive to the fact that all these new lurkers don't have our history of a context for a lot of our "insider information". This probably applies to me more than anyone else, because I have this charming habit of mentioning precedents by allusion. (You do think its charming, right?) I think for a couple of years, we're going to need to provide more context in our mail. - jek3 From sacadmin Tue Oct 10 13:12:07 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AKC7RX010920; Tue, 10 Oct 2006 13:12:07 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9AKC1U2667873; Tue, 10 Oct 2006 13:12:05 -0700 (PDT) Message-Id: <200610102012.k9AKC1U2667873@jurassic.eng.sun.com> Date: Tue, 10 Oct 2006 10:11:25 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Joseph.Kowalski@eng.Sun.COM, John.Plocher@sun.com Cc: Ed.Gould@sun.com, James.D.Carlson@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5puA5HIYjm1BwM6szfB9zQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2119 > From: John Plocher ... > +-- Joseph Kowalski wrote On 10/09/06 13:48,: > > So, we should be talking about how to make a case be closed and > > the default should just be open. > > Virtual yesterday the default (and only implemented behavior) > was closed. > > Today, we are attempting to design/implement a mechanism > whereby things *can* be open. There are still unsolved > issues relating to identifying and training external ARC > interns and members, infrastructure to support external > submission of fasttracks and onepagers, etc. Without > these, we can't be completely open for all use cases, so > a policy of default=closed still makes sense. I strongly disagree. As Jim (and maybe Ed) have said, this is handing loaded weapons to those who have agendas counter to OpenSolaris. More importantly, a large chartered team (with which you somewhat participated) decided otherwise. As far as I'm concerned, our directive is to move to a fully open ARC process ASAP. > Virtual tomorrow, we _will_ have the mechanisms in place for > things to choose to be either open or closed. There may even > be pre-completion milestones where it makes sense to reassess > the default policy. I think you (and perhaps Ed) are making too much of a thing about "closed". The only cases which whould be closed would be those that reflect a product offering we need to keep under wraps. 99.44% of the time, that would be a project which revealed *significant* hardware characteristics. If the folk writing the hardware based case learn to be a little more careful (like not citing prerformance numbers we don't really need), I think there should be less than 5 closed cases a year. > At that point, we can have a profitable discussion as to how > and when we should transition the default to open. My vote > will be for "as soon as the infrastructure and SMI (not just > OPG) policy support doing so". What infrastructure change are needed for "default" over "non-default"? Yes, building a light switch is kinda difficult, but once its built even my mom can flip it. > -John - jek3 From sacadmin Tue Oct 10 13:17:54 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AKHsGf011015; Tue, 10 Oct 2006 13:17:54 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9AKHnp6669781; Tue, 10 Oct 2006 13:17:53 -0700 (PDT) Message-Id: <200610102017.k9AKHnp6669781@jurassic.eng.sun.com> Date: Tue, 10 Oct 2006 10:17:12 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: James.D.Carlson@sun.com, Glynn.Foster@sun.com Cc: Joseph.Kowalski@eng.sun.com, Ed.Gould@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: stxQafsydPGCNvMCHPsaOw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 467 > From: Glynn Foster ... > [1] Though I have worries that if we continually archive the open cases > internally as well, it sort of feels like we're playing in a different > sandbox still I agree with Glynn on this. Moving forward **everything possible** should be open. If we had unlimited resources, we'd like to make 95% of our existing archive public. Why would we continue to make the results of a public discussion private? - jek3 From sacadmin Tue Oct 10 13:27:44 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AKRiur011227; Tue, 10 Oct 2006 13:27:44 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AKRiFH018269; Tue, 10 Oct 2006 13:27:44 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AKRd0q020250; Tue, 10 Oct 2006 13:27:39 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00F01SQXMD00@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM); Tue, 10 Oct 2006 13:27:38 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00DXRSU2VOVP@d1-sfbay-09.sun.com>; Tue, 10 Oct 2006 13:27:38 -0700 (PDT) Date: Tue, 10 Oct 2006 13:27:44 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <200610102017.k9AKHnp6669781@jurassic.eng.sun.com> Sender: Ed.Gould@Sun.COM To: Joseph Kowalski Cc: James.D.Carlson@Sun.COM, Glynn.Foster@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452C0240.9060002@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_c0iSdx9rxfSvHE1dp2UO+Q)" References: <200610102017.k9AKHnp6669781@jurassic.eng.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 2138 This is a multi-part message in MIME format. --Boundary_(ID_c0iSdx9rxfSvHE1dp2UO+Q) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Joseph Kowalski wrote: > I agree with Glynn on this. Moving forward **everything possible** should > be open. If we had unlimited resources, we'd like to make 95% of our > existing archive public. Why would we continue to make the results of > a public discussion private? I agree that everything possible should be open. But there will always be some things (even if it's just a case or two a year) that need to stay closed. So we need the mechanism. And there are often business discussions that relate directly to open cases. We need a convenient mechanism to have those discussions, too. The case is open, and the architectural issues and decisions are open, but we are *also* dealing with product strategy and business issues that are not open. Just because something architecturally is acceptable for OpenSolaris does not automatically make it a good business choice for Sun. I hope that it is rare that Sun's business needs will diverge from the technical decisions taken by OpenSolaris. But even if that is rare (and I'm sure it will not be a null set), I do not believe that the discussions to make the business case for keeping the tracking close will be as rare (at least, not initially). These discussions are not ones that I think should be open. Yet they may still be closely tied to a specific case, and I would want an easy way to participate in both the open and closed parts of the discussion. -- --Ed --Boundary_(ID_c0iSdx9rxfSvHE1dp2UO+Q) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_c0iSdx9rxfSvHE1dp2UO+Q)-- From sacadmin Tue Oct 10 13:41:13 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AKfDfB011442; Tue, 10 Oct 2006 13:41:13 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9AKf7JN676304; Tue, 10 Oct 2006 13:41:11 -0700 (PDT) Message-Id: <200610102041.k9AKf7JN676304@jurassic.eng.sun.com> Date: Tue, 10 Oct 2006 10:40:31 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Glynn.Foster@sun.com, John.Plocher@sun.com Cc: James.D.Carlson@sun.com, Joseph.Kowalski@eng.Sun.COM, Ed.Gould@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: pMnZNqpTrikOhU1QrAd4nQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1391 > From: John Plocher ... > Glynn Foster wrote: > > While I agree that we're not in the position for community members to > > contribute their own cases, I'm not get why we're not in a position for > > open=default. I would have assumed that project teams would have already > > made the call, separate to ARC, as to whether their project was going to > > be public or not. > > > > > This is not a technical decision, it is an executive discussion that has > not yet reached closure > because (IMO) the Solaris-PAC/OPG has not done a good job of managing > the CAP associated > with this change; there are still significant parts of Sun that are not > bought into the fact that their > stuff going into an open sourced system (think new platforms/ and > devices). Some of this is > foolishness, but some is not,; it may require the development of some > sort of "closed until > putback" scheme, which (IMHO) would be an unmitigated disaster WRT an > open ARC process... John, Which executive told you that we are not ready? To the best of my knowledge, Harpster thinks we are ready (or thought, this is rather old data). I think Harpster has the call here, but maybe its Jackson or maybe even Green. If we are going to be forced to do a halfway measure which will only add to long term confusion, I'd like to know who is forcing it. - thanks, - jek3 From sacadmin Tue Oct 10 13:43:35 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AKhZZE011500; Tue, 10 Oct 2006 13:43:35 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9AKkAg5010740; Tue, 10 Oct 2006 16:46:10 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9AKkAdX010737; Tue, 10 Oct 2006 16:46:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17708.1681.749419.476312@gargle.gargle.HOWL> Date: Tue, 10 Oct 2006 16:46:09 -0400 From: James Carlson To: John Plocher Cc: Darren J Moffat , Joseph Kowalski , Ed.Gould@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <452BFBC6.1020500@Sun.COM> References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> <452BE5A0.3040308@Sun.COM> <17707.59794.895953.184663@gargle.gargle.HOWL> <452BF291.5000307@Sun.COM> <17707.63408.889352.768514@gargle.gargle.HOWL> <452BFBC6.1020500@Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1388 John Plocher writes: > > I'm not quite sure what you're saying here. What are "core > > contributors?" > > See http://www.genunix.org/wiki/index.php/OpenSolaris_Governance_Draft_02#ARTICLE_IIIa.__Structure.2C_Participation.2C_and_Roles [...] Yes, I know about that document. I still don't quite know what it means in this context, as the definitions don't quite seem to line up. A "Participant" looks somewhat like an intern to me, but I see no analog for "Contributor" or any particular way to discern core from non-core. Or, perhaps, the "Contributors" are the members and the "Core Contributors" are actually the ARC chairs. Note that the "voting" it's talking about here isn't about ARC cases, but rather about the community itself; which translates as "SAC" to me. Since it's about futures, though, I suppose it doesn't matter right now. > It is, and I agree (thus my comment of it being an open question...) > In the (perfect) future, the open-arc-member-list is a constructed > alias made up of all the various community-core-contributers. We > (and the os.o web site/community structure/...) are a long way > away from that point right now. OK. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Oct 10 14:02:20 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AL2JJv012586; Tue, 10 Oct 2006 14:02:19 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9AL2EHx682874; Tue, 10 Oct 2006 14:02:18 -0700 (PDT) Message-Id: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> Date: Tue, 10 Oct 2006 11:01:38 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Joseph.Kowalski@eng.sun.com, Ed.Gould@sun.com Cc: James.D.Carlson@sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LEBrjkj2jNsNdzmjGIejww== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1788 > From: Ed Gould ... > Joseph Kowalski wrote: > > I agree with Glynn on this. Moving forward **everything possible** should > > be open. If we had unlimited resources, we'd like to make 95% of our > > existing archive public. Why would we continue to make the results of > > a public discussion private? > > I agree that everything possible should be open. But there will always > be some things (even if it's just a case or two a year) that need to > stay closed. So we need the mechanism. And there are often business > discussions that relate directly to open cases. We need a convenient > mechanism to have those discussions, too. The case is open, and the > architectural issues and decisions are open, but we are *also* dealing > with product strategy and business issues that are not open. Just > because something architecturally is acceptable for OpenSolaris does not > automatically make it a good business choice for Sun. > > I hope that it is rare that Sun's business needs will diverge from the > technical decisions taken by OpenSolaris. But even if that is rare (and > I'm sure it will not be a null set), I do not believe that the > discussions to make the business case for keeping the tracking close > will be as rare (at least, not initially). These discussions are not > ones that I think should be open. Yet they may still be closely tied to > a specific case, and I would want an easy way to participate in both the > open and closed parts of the discussion. > -- > --Ed Somebody here is not understanding the other. History would suggest that it might be me. All I'm saying is that moving forward, access to the case's archive should be exactly the same as the open/closed/unopened status of the case. - jek3 From sacadmin Tue Oct 10 14:06:39 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AL6cT3012612; Tue, 10 Oct 2006 14:06:38 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AL6cTd006801; Tue, 10 Oct 2006 14:06:38 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AL6XmF025401; Tue, 10 Oct 2006 14:06:33 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00L01ULIN100@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM); Tue, 10 Oct 2006 14:06:33 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00DUMUMXCBHO@d1-sfbay-10.sun.com>; Tue, 10 Oct 2006 14:06:33 -0700 (PDT) Date: Tue, 10 Oct 2006 14:06:39 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> Sender: Ed.Gould@Sun.COM To: Joseph Kowalski Cc: James.D.Carlson@Sun.COM, Glynn.Foster@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452C0B5F.6080309@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_gOuPqTFLxlV7+9kEhSG/6Q)" References: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1055 This is a multi-part message in MIME format. --Boundary_(ID_gOuPqTFLxlV7+9kEhSG/6Q) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Joseph Kowalski wrote: > All I'm saying is that moving forward, access to the case's archive > should be exactly the same as the open/closed/unopened status of the > case. I'm saying I don't think it's quite that simple. Yes, for the architectural log, but I expect there will be closed discussions associated with open cases that should be logged, too. -- --Ed --Boundary_(ID_gOuPqTFLxlV7+9kEhSG/6Q) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_gOuPqTFLxlV7+9kEhSG/6Q)-- From sacadmin Tue Oct 10 14:12:50 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9ALCoK0012688; Tue, 10 Oct 2006 14:12:50 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9ALCiMM685933; Tue, 10 Oct 2006 14:12:49 -0700 (PDT) Message-Id: <200610102112.k9ALCiMM685933@jurassic.eng.sun.com> Date: Tue, 10 Oct 2006 11:12:08 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Joseph.Kowalski@eng.sun.com, Ed.Gould@sun.com Cc: James.D.Carlson@sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +B1KU/3argi2kCUjEUHDoQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 381 > From: Ed Gould ... > I'm saying I don't think it's quite that simple. Yes, for the > architectural log, but I expect there will be closed discussions > associated with open cases that should be logged, too. Oh, I missed that. Kinda an edge condition, but I agree that the infrastructure should handle this. I think policy should discourage it. - jek3 From sacadmin Tue Oct 10 14:16:09 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9ALG9OA013025; Tue, 10 Oct 2006 14:16:09 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9ALIjik010900; Tue, 10 Oct 2006 17:18:45 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9ALIjUu010897; Tue, 10 Oct 2006 17:18:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17708.3636.881598.726349@gargle.gargle.HOWL> Date: Tue, 10 Oct 2006 17:18:44 -0400 From: James Carlson To: Ed Gould Cc: Joseph Kowalski , Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <452C0B5F.6080309@sun.com> References: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> <452C0B5F.6080309@sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1404 Ed Gould writes: > Joseph Kowalski wrote: > > All I'm saying is that moving forward, access to the case's archive > > should be exactly the same as the open/closed/unopened status of the > > case. > > I'm saying I don't think it's quite that simple. Yes, for the > architectural log, but I expect there will be closed discussions > associated with open cases that should be logged, too. Do we have a technical means available to extract those closed discussions from the log, so that we can make the proper set available to Open Solaris participants? Is this really a matter of having some human editor go through and separate the bits? If we have no good means to do this, and if these discussions really aren't about the system architecture itself, then I think we might be better off if we move those discussions to some place that's more suitable, such as a PAC. Otherwise, I think we're wandering into an area where we're bound to make lots of expensive mistakes. The idea of interleaving these things seems too complicated to me. (Are you thinking of the OPL cases? Is there something in particular that you have in mind? A hard usage case would be worthwhile.) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Tue Oct 10 14:18:20 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9ALIKL2013044; Tue, 10 Oct 2006 14:18:20 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9ALIJVJ012474; Tue, 10 Oct 2006 14:18:19 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9ALIEfs026899; Tue, 10 Oct 2006 14:18:14 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00701V3GBD00@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM); Tue, 10 Oct 2006 14:18:14 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00D6SV6BW0SK@d1-sfbay-09.sun.com>; Tue, 10 Oct 2006 14:18:11 -0700 (PDT) Date: Tue, 10 Oct 2006 14:18:18 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <200610102112.k9ALCiMM685933@jurassic.eng.sun.com> Sender: Ed.Gould@Sun.COM To: Joseph Kowalski Cc: James.D.Carlson@Sun.COM, Glynn.Foster@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452C0E1A.1010103@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_h5S+Oqp7MAFpSNZ+xRT6bw)" References: <200610102112.k9ALCiMM685933@jurassic.eng.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1368 This is a multi-part message in MIME format. --Boundary_(ID_h5S+Oqp7MAFpSNZ+xRT6bw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Joseph Kowalski wrote: >> From: Ed Gould >> I'm saying I don't think it's quite that simple. Yes, for the >> architectural log, but I expect there will be closed discussions >> associated with open cases that should be logged, too. > > Oh, I missed that. > > Kinda an edge condition, but I agree that the infrastructure should > handle this. I don't think it's an edge condition. I expect business discussions that relate to open cases to happen. Perhaps they'll drop off with time, but I think they'll always be there to some degree. > I think policy should discourage it. I agree so far as technical content, but not for business issues. -- --Ed --Boundary_(ID_h5S+Oqp7MAFpSNZ+xRT6bw) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_h5S+Oqp7MAFpSNZ+xRT6bw)-- From sacadmin Tue Oct 10 14:23:07 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9ALN6lC013192; Tue, 10 Oct 2006 14:23:06 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9ALN6LT020284; Tue, 10 Oct 2006 14:23:06 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9ALN1xN023408; Tue, 10 Oct 2006 14:23:01 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00G01VD9L500@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM); Tue, 10 Oct 2006 14:23:01 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00DQNVECVO9Q@d1-sfbay-09.sun.com>; Tue, 10 Oct 2006 14:23:00 -0700 (PDT) Date: Tue, 10 Oct 2006 14:23:07 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <17708.3636.881598.726349@gargle.gargle.HOWL> Sender: Ed.Gould@Sun.COM To: James Carlson Cc: Joseph Kowalski , Glynn.Foster@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452C0F3B.2090807@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_QURTqJW2nu+DVT/fqYWyWg)" References: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> <452C0B5F.6080309@sun.com> <17708.3636.881598.726349@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1822 This is a multi-part message in MIME format. --Boundary_(ID_QURTqJW2nu+DVT/fqYWyWg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT James Carlson wrote: > Do we have a technical means available to extract those closed > discussions from the log, so that we can make the proper set available > to Open Solaris participants? Is this really a matter of having some > human editor go through and separate the bits? I would not want an editor do do this post hoc. I'm looking for a mechanism that an employee could use to fork the discussion into open and closed parts. It may not be easy enough to do to make it worthwhile. > If we have no good means to do this, and if these discussions really > aren't about the system architecture itself, then I think we might be > better off if we move those discussions to some place that's more > suitable, such as a PAC. We may have to do that, but I'd like it to be easy to associate with a case. > (Are you thinking of the OPL cases? Is there something in particular > that you have in mind? A hard usage case would be worthwhile.) I'm thinking more about the support ramifications, for example, of a sound architectural decision that the community wants to take, but is at odds with our business needs. -- --Ed --Boundary_(ID_QURTqJW2nu+DVT/fqYWyWg) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_QURTqJW2nu+DVT/fqYWyWg)-- From sacadmin Tue Oct 10 14:38:57 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9ALcvVR013507; Tue, 10 Oct 2006 14:38:57 -0700 (PDT) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9ALcqgh021816; Tue, 10 Oct 2006 14:38:53 -0700 (PDT) Message-ID: <452C12EC.8030800@sun.com> Date: Tue, 10 Oct 2006 14:38:52 -0700 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.5 (X11/20060731) MIME-Version: 1.0 To: Ed Gould CC: James Carlson , Joseph Kowalski , Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] References: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> <452C0B5F.6080309@sun.com> <17708.3636.881598.726349@gargle.gargle.HOWL> <452C0F3B.2090807@sun.com> In-Reply-To: <452C0F3B.2090807@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 630 Ed Gould wrote: > I'm thinking more about the support ramifications, for example, of a > sound architectural decision that the community wants to take, but is at > odds with our business needs. So would this be someting like the community wants to integrate KDE alongside GNOME, but we don't want to double our desktop support costs/committments? Things like that may lead to a better definition of what's Solaris vs. OpenSolaris - can we let the community do that in OpenSolaris and not include it in Solaris? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Tue Oct 10 14:40:57 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9ALev2I013527; Tue, 10 Oct 2006 14:40:57 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9ALevPx022594; Tue, 10 Oct 2006 14:40:57 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9ALeql7025847; Tue, 10 Oct 2006 14:40:52 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00J01W59N500@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM); Tue, 10 Oct 2006 14:40:52 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00DQGW83CBOO@d1-sfbay-10.sun.com>; Tue, 10 Oct 2006 14:40:51 -0700 (PDT) Date: Tue, 10 Oct 2006 14:40:58 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452C12EC.8030800@sun.com> Sender: Ed.Gould@Sun.COM To: Alan Coopersmith Cc: James Carlson , Joseph Kowalski , Glynn.Foster@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452C136A.9070000@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_kq6hY+NQYI1iqU2PBO5OwQ)" References: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> <452C0B5F.6080309@sun.com> <17708.3636.881598.726349@gargle.gargle.HOWL> <452C0F3B.2090807@sun.com> <452C12EC.8030800@sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1303 This is a multi-part message in MIME format. --Boundary_(ID_kq6hY+NQYI1iqU2PBO5OwQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Alan Coopersmith wrote: > Ed Gould wrote: >> I'm thinking more about the support ramifications, for example, of a >> sound architectural decision that the community wants to take, but is >> at odds with our business needs. > > So would this be someting like the community wants to integrate KDE > alongside GNOME, but we don't want to double our desktop support > costs/committments? > > Things like that may lead to a better definition of what's Solaris > vs. OpenSolaris - can we let the community do that in OpenSolaris and > not include it in Solaris? Yes, that's the kind of issue I had in mind. -- --Ed --Boundary_(ID_kq6hY+NQYI1iqU2PBO5OwQ) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_kq6hY+NQYI1iqU2PBO5OwQ)-- From sacadmin Tue Oct 10 15:12:27 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AMCRXc014544; Tue, 10 Oct 2006 15:12:27 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AMCRZv006017; Tue, 10 Oct 2006 15:12:27 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AMCMun004040; Tue, 10 Oct 2006 15:12:22 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00L01XN0YN00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Tue, 10 Oct 2006 15:12:22 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00DWDXOIW01L@d1-sfbay-09.sun.com>; Tue, 10 Oct 2006 15:12:19 -0700 (PDT) Date: Tue, 10 Oct 2006 15:12:18 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452C0B5F.6080309@sun.com> Sender: John.Plocher@Sun.COM To: Ed Gould Cc: Joseph Kowalski , James.D.Carlson@Sun.COM, Glynn.Foster@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452C1AC2.6050304@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> <452C0B5F.6080309@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 588 +-- Ed Gould wrote On 10/10/06 14:06,: > I'm saying I don't think it's quite that simple. Yes, for the > architectural log, but I expect there will be closed discussions > associated with open cases that should be logged, too. Then don't log them with the open case. Log them elsewhere (such as in the psarc-closed logs, on a PAC alias, ...). It is not in the ARC's best interest to have or promote closed architectural conversations about open items; it is even less useful for them to have business/marketing discussions about cases whatever their open/closed state. -John From sacadmin Tue Oct 10 15:19:23 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AMJNc3014593; Tue, 10 Oct 2006 15:19:23 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AMJMgR009155; Tue, 10 Oct 2006 15:19:22 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AMJH4Q000607; Tue, 10 Oct 2006 15:19:17 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00601XXERB00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Tue, 10 Oct 2006 15:19:17 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00DY6Y04VR2F@d1-sfbay-09.sun.com>; Tue, 10 Oct 2006 15:19:17 -0700 (PDT) Date: Tue, 10 Oct 2006 15:19:16 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452C0F3B.2090807@sun.com> Sender: John.Plocher@Sun.COM To: Ed Gould Cc: James Carlson , Joseph Kowalski , Glynn.Foster@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452C1C64.2080705@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> <452C0B5F.6080309@sun.com> <17708.3636.881598.726349@gargle.gargle.HOWL> <452C0F3B.2090807@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 796 +-- Ed Gould wrote On 10/10/06 14:23,: > I'm thinking more about the support ramifications, for example, of a > sound architectural decision that the community wants to take, but is at > odds with our business needs. Why wouldn't those things be OK to discuss on an open alias? Isn't such open discussion part and parcel of doing our development in an open community? If a community project will impact support (or other products or ...), isn't it a requirement that the community be aware of that impact - especially if it will influence the architectural decisions of (part of) the ARC? IMO, this all leads to a dysfunctional ARC process whereby some of the ARC participants are excluded from conversations involving the others - something that should be avoided if possible. -John From sacadmin Tue Oct 10 15:23:29 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AMNTot014667; Tue, 10 Oct 2006 15:23:29 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AMNTaM010689; Tue, 10 Oct 2006 15:23:29 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AMNNlG005316; Tue, 10 Oct 2006 15:23:24 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00D01Y67Q600@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM); Tue, 10 Oct 2006 15:23:23 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00D5AY6ZVT5A@d1-sfbay-09.sun.com>; Tue, 10 Oct 2006 15:23:23 -0700 (PDT) Date: Tue, 10 Oct 2006 15:23:30 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452C1C64.2080705@Sun.COM> Sender: Ed.Gould@Sun.COM To: John Plocher Cc: James Carlson , Joseph Kowalski , Glynn.Foster@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452C1D62.7020408@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_gJzniPv4fzt/CuVbXd0hPw)" References: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> <452C0B5F.6080309@sun.com> <17708.3636.881598.726349@gargle.gargle.HOWL> <452C0F3B.2090807@sun.com> <452C1C64.2080705@Sun.COM> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1416 This is a multi-part message in MIME format. --Boundary_(ID_gJzniPv4fzt/CuVbXd0hPw) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT John Plocher wrote: > +-- Ed Gould wrote On 10/10/06 14:23,: >> I'm thinking more about the support ramifications, for example, of a >> sound architectural decision that the community wants to take, but is >> at odds with our business needs. > > Why wouldn't those things be OK to discuss on an open alias? Isn't > such open discussion part and parcel of doing our development in > an open community? If a community project will impact support > (or other products or ...), isn't it a requirement that the community > be aware of that impact - especially if it will influence the > architectural decisions of (part of) the ARC? Because this is about resource management. That's not something to discuss openly. -- --Ed --Boundary_(ID_gJzniPv4fzt/CuVbXd0hPw) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_gJzniPv4fzt/CuVbXd0hPw)-- From sacadmin Tue Oct 10 15:37:42 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AMbfaW014716; Tue, 10 Oct 2006 15:37:42 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9AMbanT019890; Tue, 10 Oct 2006 18:37:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9AMbYZT006858; Tue, 10 Oct 2006 18:37:34 -0400 (EDT) Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] From: Bill Sommerfeld To: Ed Gould Cc: John Plocher , James Carlson , Joseph Kowalski , Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com In-Reply-To: <452C1D62.7020408@sun.com> References: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> <452C0B5F.6080309@sun.com> <17708.3636.881598.726349@gargle.gargle.HOWL> <452C0F3B.2090807@sun.com> <452C1C64.2080705@Sun.COM> <452C1D62.7020408@sun.com> Content-Type: text/plain Date: Tue, 10 Oct 2006 18:37:33 -0400 Message-Id: <1160519853.4380.87.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 213 On Tue, 2006-10-10 at 15:23 -0700, Ed Gould wrote: > Because this is about resource management. That's not something to > discuss openly. That sounds to me more like a PACish concern than an ARCish concern. From sacadmin Tue Oct 10 15:45:05 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AMj57V014771; Tue, 10 Oct 2006 15:45:05 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9AMj4aa026991; Tue, 10 Oct 2006 15:45:04 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AMixsE007716; Tue, 10 Oct 2006 15:44:59 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00G01Z4ZD300@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM); Tue, 10 Oct 2006 15:44:59 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00HEEZ6ZAKM8@d1-sfbay-10.sun.com>; Tue, 10 Oct 2006 15:44:59 -0700 (PDT) Date: Tue, 10 Oct 2006 15:45:04 -0700 From: Ed Gould Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <1160519853.4380.87.camel@thunk> Sender: Ed.Gould@Sun.COM To: Bill Sommerfeld Cc: John Plocher , James Carlson , Joseph Kowalski , Glynn.Foster@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452C2270.6000006@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_F8njowhasyrLu2E6U2M/VA)" References: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> <452C0B5F.6080309@sun.com> <17708.3636.881598.726349@gargle.gargle.HOWL> <452C0F3B.2090807@sun.com> <452C1C64.2080705@Sun.COM> <452C1D62.7020408@sun.com> <1160519853.4380.87.camel@thunk> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1442 This is a multi-part message in MIME format. --Boundary_(ID_F8njowhasyrLu2E6U2M/VA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Bill Sommerfeld wrote: > On Tue, 2006-10-10 at 15:23 -0700, Ed Gould wrote: >> Because this is about resource management. That's not something to >> discuss openly. > > That sounds to me more like a PACish concern than an ARCish concern. Yes, it mostly is. But it will come up in the context of the ARC discussion. Take Alan's example. The community wants to include KDE along with Gnome as the desktop, a la RedHat. It's sound architecture, but perhaps not a business we want to take on. How does this get raised to the PAC? This looks like a potential fork between OpenSolaris and our product. I believe that is a discussion that should be archived along with the architectural discussion, but it is not an open discussion. -- --Ed --Boundary_(ID_F8njowhasyrLu2E6U2M/VA) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_F8njowhasyrLu2E6U2M/VA)-- From sacadmin Tue Oct 10 15:45:09 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AMj9Po014776; Tue, 10 Oct 2006 15:45:09 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9AMj99e027066; Tue, 10 Oct 2006 15:45:09 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9AMj4vO007731; Tue, 10 Oct 2006 15:45:04 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6X00I01Z5XU800@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Tue, 10 Oct 2006 15:45:04 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6X00DJKZ6QVOQQ@d1-sfbay-09.sun.com>; Tue, 10 Oct 2006 15:45:03 -0700 (PDT) Date: Tue, 10 Oct 2006 15:44:49 -0700 From: John Plocher Subject: open ARC structure - Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <17708.1681.749419.476312@gargle.gargle.HOWL> Sender: John.Plocher@Sun.COM To: James Carlson Cc: plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452C2261.4060302@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> <452BE5A0.3040308@Sun.COM> <17707.59794.895953.184663@gargle.gargle.HOWL> <452BF291.5000307@Sun.COM> <17707.63408.889352.768514@gargle.gargle.HOWL> <452BFBC6.1020500@Sun.COM> <17708.1681.749419.476312@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 2266 +-- James Carlson wrote On 10/10/06 13:46,: > John Plocher writes: > >>>I'm not quite sure what you're saying here. What are "core >>>contributors?" >> >>See http://www.genunix.org/wiki/index.php/OpenSolaris_Governance_Draft_02#ARTICLE_IIIa.__Structure.2C_Participation.2C_and_Roles > > [...] > > Yes, I know about that document. I still don't quite know what it > means in this context, as the definitions don't quite seem to line up. IMO (this part of the discussion really should be part of an open conversation): There are many OpenSolaris Communities. Assume for this discussion that the current chaotic set is somehow transmorgified into a useful set. Each Community provides ARC participants. In addition to the normal ARC duties, their role is also to represent their community on the ARC when reviewing proposals from other communities, to act as an ARC/Community liaison and to mentor projects coming from their communities. In the current governance model, this "ARC participant" role maps relatively well onto that of Community Core Contributer. This implies that one of the responsibilities of being a core community member is being active on the ARC. There is only one "OpenSolaris ARC". It has many members and interns. The set of ARC(members+interns) is by intent identical to that of Community(all)(core). It also has licensees from the set of Community Contributers. The ARC elects its own chair from among its members. The appeals process for "OpenSolaris ARC" will be different than that for PSARC, although the transition from "goes up to Greg" to "goes to the CAB" has not been spec'd out yet. There is an OpenSolaris ARC community. It exists to manage the open ARC process, its tools, mailing lists, archives etc. It is also the maintainer of the OS.o ARC web site for the process docs, policies, caselogs and other published documents. Its core contributers are also ARC participants, but there is otherwise nothing special (read "can override the ARC") about them. The existing SAC staff and (some of) the tonic I-Team are the seeds of this community. There are meta-communities other than OpenSolaris that will have their own ARCs. Their creation, interaction, etc is the topic of another discussion. -John From sacadmin Tue Oct 10 16:04:56 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9AN4u7l015677; Tue, 10 Oct 2006 16:04:56 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9AN4kl3720490; Tue, 10 Oct 2006 16:04:51 -0700 (PDT) Message-Id: <200610102304.k9AN4kl3720490@jurassic.eng.sun.com> Date: Tue, 10 Oct 2006 13:04:11 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Ed.Gould@sun.com, james.d.carlson@sun.com Cc: Joseph.Kowalski@eng.sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tyGKreFL3X0Nh6FzuQMYYg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 601 > From: James Carlson ... > Do we have a technical means available to extract those closed > discussions from the log, so that we can make the proper set available > to Open Solaris participants? Is this really a matter of having some > human editor go through and separate the bits? I assumed that the open discussion would go to the open alias, that the closed dicussion would go to the closed alias, each would log to its own, distinct log file. Isn't the only minor question where the closed log for an open case? (.mail? nah,...) Am I missing something? - jek3 From sacadmin Tue Oct 10 22:40:46 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9B5ekcT022940; Tue, 10 Oct 2006 22:40:46 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9B5ekmN003651; Tue, 10 Oct 2006 22:40:46 -0700 (PDT) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9B5eiee010306; Tue, 10 Oct 2006 23:40:46 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Y00601G179D00@mail-amer.sun.com> (original mail from Arieh.Markel@Sun.COM); Tue, 10 Oct 2006 23:40:43 -0600 (MDT) Received: from [192.168.21.7] ([88.155.9.72]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Y00BQAIFRP0W0@mail-amer.sun.com>; Tue, 10 Oct 2006 23:40:43 -0600 (MDT) Date: Wed, 11 Oct 2006 07:40:41 +0200 From: Arieh Markel Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <17708.1681.749419.476312@gargle.gargle.HOWL> Sender: Arieh.Markel@Sun.COM To: James Carlson Cc: John Plocher , Darren J Moffat , Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452C83D9.1000400@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> <452BE5A0.3040308@Sun.COM> <17707.59794.895953.184663@gargle.gargle.HOWL> <452BF291.5000307@Sun.COM> <17707.63408.889352.768514@gargle.gargle.HOWL> <452BFBC6.1020500@Sun.COM> <17708.1681.749419.476312@gargle.gargle.HOWL> User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) Status: RO Content-Length: 2618 I have been following the thread and reading the docs and although just an Open Solaris community member, here is what I am understanding from below in the hope of providing clarification - if I indeed am understanding as it was intended ... James Carlson wrote: >John Plocher writes: > > >>>I'm not quite sure what you're saying here. What are "core >>>contributors?" >>> >>> >>See http://www.genunix.org/wiki/index.php/OpenSolaris_Governance_Draft_02#ARTICLE_IIIa.__Structure.2C_Participation.2C_and_Roles >> >> >[...] > >Yes, I know about that document. I still don't quite know what it >means in this context, as the definitions don't quite seem to line up. > >A "Participant" looks somewhat like an intern to me, but I see no >analog for "Contributor" or any particular way to discern core from >non-core. Or, perhaps, the "Contributors" are the members and the >"Core Contributors" are actually the ARC chairs. Note that the >"voting" it's talking about here isn't about ARC cases, but rather >about the community itself; which translates as "SAC" to me. > > > I believe the exercise is to try to bridge the way open source communities are organized and recognize different levels of membership and map them to what we have today in ARC-land. A 'participant' I understand to be a 'member of the community' - for the analogy, a subscriber to the 'interest' list. A 'Contributor' would be one who takes a more active role, but is not a 'qualified voting member', this would fit to be mapped to an 'intern', essentially one who wants to get 'committer' status but needs to be proven. A 'Core Contributor' would be one who has voting rights, probably due to actual contributions, essentially one who obtained 'committer' status due to its previous contributions. I don't see an analogy to ARC chair except as a 'chosen-by-the-community' lead of the community (see how the Apache foundation does it for projects). Arieh >Since it's about futures, though, I suppose it doesn't matter right >now. > > > >>It is, and I agree (thus my comment of it being an open question...) >>In the (perfect) future, the open-arc-member-list is a constructed >>alias made up of all the various community-core-contributers. We >>(and the os.o web site/community structure/...) are a long way >>away from that point right now. >> >> > >OK. > > > -- Arieh Markel Sun Microsystems, Inc. SysNet - UC/Enterprise 33 Bezalel St. 13th flr. MS ERAM01 e-mail: arieh.markel@sun.COM Ramat Gan, Israel http://blogs.sun.com/arieh Phone: +972-3-753-4307 From sacadmin Wed Oct 11 04:11:06 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BBB5wK000384; Wed, 11 Oct 2006 04:11:05 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9BBB4ii020160; Wed, 11 Oct 2006 04:11:05 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119] (may be forged)) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9BBAx2F002097; Wed, 11 Oct 2006 12:10:59 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Y00A01XQ6EU00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 11 Oct 2006 12:10:59 +0100 (BST) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Y005N4XQ94F20@d1-emea-09.sun.com>; Wed, 11 Oct 2006 12:10:58 +0100 (BST) Date: Wed, 11 Oct 2006 12:10:57 +0100 From: Darren J Moffat Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452BF291.5000307@Sun.COM> Sender: Darren.Moffat@Sun.COM To: John Plocher Cc: James Carlson , Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452CD141.3060603@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> <452BE5A0.3040308@Sun.COM> <17707.59794.895953.184663@gargle.gargle.HOWL> <452BF291.5000307@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060912) Status: RO Content-Length: 759 John Plocher wrote: > > > +-- James Carlson wrote On 10/10/06 11:42,: >> I think that part can be fixed ... > > I do not believe that there is any way to put such a filter in > place *on* os.o, nor do I think that it is the right long term > answer. Why not ? If this is the ARC for OpenSolaris or is this the ARC for Solaris ? If it is for OpenSolaris then the only correct place IMO is on opensolaris.org. If it is for Solaris then I assert that we have failed in our open development model and are instead just open source. You should not assume that the infrastructure on opensolaris.org can't be extended to do what ever mail filtering you need - in fact I think you should not only assume that it can but that it must. -- Darren J Moffat From sacadmin Wed Oct 11 04:17:37 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BBHbZd000476; Wed, 11 Oct 2006 04:17:37 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9BBHax9022424; Wed, 11 Oct 2006 04:17:37 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119] (may be forged)) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9BBHUhJ003105; Wed, 11 Oct 2006 12:17:30 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Y00H01XYPBV00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 11 Oct 2006 12:17:30 +0100 (BST) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Y005P0Y154F20@d1-emea-09.sun.com>; Wed, 11 Oct 2006 12:17:30 +0100 (BST) Date: Wed, 11 Oct 2006 12:17:29 +0100 From: Darren J Moffat Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452C12EC.8030800@sun.com> Sender: Darren.Moffat@Sun.COM To: Alan Coopersmith Cc: Ed Gould , James Carlson , Joseph Kowalski , Glynn.Foster@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452CD2C9.6020302@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200610102102.k9AL2EHx682874@jurassic.eng.sun.com> <452C0B5F.6080309@sun.com> <17708.3636.881598.726349@gargle.gargle.HOWL> <452C0F3B.2090807@sun.com> <452C12EC.8030800@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060912) Status: RO Content-Length: 1294 Alan Coopersmith wrote: > Ed Gould wrote: >> I'm thinking more about the support ramifications, for example, of a >> sound architectural decision that the community wants to take, but is >> at odds with our business needs. > > So would this be someting like the community wants to integrate KDE > alongside GNOME, but we don't want to double our desktop support > costs/committments? > > Things like that may lead to a better definition of what's Solaris > vs. OpenSolaris - can we let the community do that in OpenSolaris and > not include it in Solaris? I get what you are saying but, this isn't a great example because it is something that existing distros of OpenSolaris other than Sun's are already doing. I think a better divergence between Solaris and OpenSolaris example would be incompatible changes to a bit of code rather than shipping a whole new parallel thing (similarly gnu userland tools vs what we have isn't a great example either). For example lets say some change to the VM system. How would we accomodate that for non Sun OpenSolaris distros ? How do Linux distros do that today ? Answer: Each vendor applies their own set of kernel patches and the main-line Linus Linux stays the same. That might be the answer we go for as well. -- Darren J Moffat From sacadmin Wed Oct 11 06:09:36 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BD9aI5002845; Wed, 11 Oct 2006 06:09:36 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9BDC7Ix012998; Wed, 11 Oct 2006 09:12:07 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9BDC7P0012995; Wed, 11 Oct 2006 09:12:07 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17708.60838.473496.936917@gargle.gargle.HOWL> Date: Wed, 11 Oct 2006 09:12:06 -0400 From: James Carlson To: Joseph Kowalski Cc: Ed.Gould@sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <200610102304.k9AN4kl3720490@jurassic.eng.sun.com> References: <200610102304.k9AN4kl3720490@jurassic.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 2713 Joseph Kowalski writes: > > From: James Carlson > ... > > Do we have a technical means available to extract those closed > > discussions from the log, so that we can make the proper set available > > to Open Solaris participants? Is this really a matter of having some > > human editor go through and separate the bits? > > I assumed that the open discussion would go to the open alias, that > the closed dicussion would go to the closed alias, each would log > to its own, distinct log file. Isn't the only minor question where > the closed log for an open case? (.mail? nah,...) > > Am I missing something? I didn't see that in the proposal. In any event, I'm still opposed to the idea of having closed architectural discussions about an open case. Given the risks for Open Solaris, I don't think it's wise. I don't see how saying "Sun isn't in a position to support both KDE and Gnome, so we're not committing resources to the former and the projects we fund won't include KDE support" in public is actually a sensitive matter. Customers already know this. And we can have that discussion without actually mentioning the names, salaries, or budgets involved. The sticky point is in traditional ARC work. Suppose this KDE project (like SMF or Zones) imposes a system-wide set of requirements (a "tax"). ARC approval of that project would thus endorse extra work for others outside of the project team ("you must also deliver *.kde files"). As we always do, we need to balance the desires of a project team against the costs imposed on everyone else, and seek the "best" solution. The central question, then, is whether the ARC's decisions reflect what's best for Solaris or what's best for Sun. Given that the effect of such a decision is across the entire community -- future cases will be reviewed against the requirements set by such a case -- I don't see how we can reasonably have such a discussion in private. The whole community must accept the costs of the decisions made. The simple result, I think, is that because of Open Solaris, Sun is no longer in direct and complete control of the direction of Solaris. That might be a frightening concept, but I think it's inevitable. There is no Open Solaris without a loss of control. If the issues to be discussed are in fact sensitive and business related, I'd rather see them taken up by a different group. We're walking into an area where I think we can do little but hurt ourselves. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Oct 11 08:44:59 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BFivl3006295 for ; Wed, 11 Oct 2006 08:44:58 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9BFinMT029385; Wed, 11 Oct 2006 16:44:53 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J6Z00N13AEV4J00@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Oct 2006 08:44:55 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J6Z00K12AEUP0C0@nwk-avmta-2.sfbay.sun.com>; Wed, 11 Oct 2006 08:44:54 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9BFisQF013750; Wed, 11 Oct 2006 08:44:54 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Z00001AES5X00@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Wed, 11 Oct 2006 08:44:54 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Z00DUJAEQCB5R@d1-sfbay-10.sun.com>; Wed, 11 Oct 2006 08:44:53 -0700 (PDT) Date: Wed, 11 Oct 2006 08:44:50 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452CD141.3060603@Sun.COM> Sender: John.Plocher@sun.com To: Darren J Moffat Cc: plocher@sac.sfbay.sun.com, psarc@sun.com, arc-chairs@sun.com Message-id: <452D1172.8000706@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> <452BE5A0.3040308@Sun.COM> <17707.59794.895953.184663@gargle.gargle.HOWL> <452BF291.5000307@Sun.COM> <452CD141.3060603@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 970 +-- Darren J Moffat wrote On 10/11/06 04:10,: > +-- John Plocher wrote: > > I do not believe that there is any way to put such a filter in > > place *on* os.o, nor do I think that it is the right long term > > answer. > > Why not ? The current implementation of os.o (run by IT/ops...) makes it effectively impossible to add executable infrastructure to the site. Yes this is broken, no it isn't being fixed - no $$$$. If and when it does get fixed, I'll be first in line to move much of the sac automation out there where it belongs. Until then, I'm not willing to make the opening of the ARC process dependent upon such a change, especially since it is not strictly required. The "not", however, was aimed at the "one big alias" suggestion, which I went on to point out didn't deal with our need to make a distinction between core arc members who can vote, interns who can't, licensees who can sponsor new fasttracks and interest lists of hangers-on. -John From sacadmin Wed Oct 11 08:57:06 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BFv6a6007078 for ; Wed, 11 Oct 2006 08:57:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9BFv5x22884; Wed, 11 Oct 2006 09:57:05 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6Z00K01AZ3WH00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Oct 2006 08:57:03 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6Z00IR8AZ2XU10@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Oct 2006 08:57:03 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119] (may be forged)) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9BFv2qV020185; Wed, 11 Oct 2006 16:57:02 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Z00K01AWFU400@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 11 Oct 2006 16:57:02 +0100 (BST) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Z005OHAZ04F50@d1-emea-09.sun.com>; Wed, 11 Oct 2006 16:57:01 +0100 (BST) Date: Wed, 11 Oct 2006 16:57:00 +0100 From: Darren J Moffat Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <452D1172.8000706@Sun.COM> Sender: Darren.Moffat@Sun.COM To: John Plocher Cc: plocher@sac.sfbay.sun.com, psarc@Sun.COM, arc-chairs@Sun.COM Message-id: <452D144C.3080805@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: <200610092049.k99KnUKd362839@jurassic.eng.sun.com> <17706.47981.375121.6796@gargle.gargle.HOWL> <452B7A61.5010900@Sun.COM> <452BE5A0.3040308@Sun.COM> <17707.59794.895953.184663@gargle.gargle.HOWL> <452BF291.5000307@Sun.COM> <452CD141.3060603@Sun.COM> <452D1172.8000706@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060912) Status: RO Content-Length: 1332 John Plocher wrote: > > > +-- Darren J Moffat wrote On 10/11/06 04:10,: >> +-- John Plocher wrote: >> > I do not believe that there is any way to put such a filter in >> > place *on* os.o, nor do I think that it is the right long term >> > answer. >> >> Why not ? > > The current implementation of os.o (run by IT/ops...) makes it OpenSolaris.org is run by Sun IT/ops ? Really ? That is news to me . > effectively impossible to add executable infrastructure > to the site. Yes this is broken, no it isn't being fixed - no $$$$. Have you escalated this all they way up to the people who control the purse strings and make sure they understand that we can not do proper open development with out it ? Have you brought this up on website-discuss@opensolaris.org ? I couldn't fine a thread requesting scripting based filtering only the discussion about non member postings. > If and when it does get fixed, I'll be first in line to move much > of the sac automation out there where it belongs. Until then, > I'm not willing to make the opening of the ARC process dependent > upon such a change, especially since it is not strictly required. As long as the infrastructure is hosted @sun.com it will appear to not be open to some people, it needs all be on @opensolaris.org to be truely open IMO. -- Darren J Moffat From sacadmin Wed Oct 11 09:36:41 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BGafbO007953; Wed, 11 Oct 2006 09:36:41 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9BGafTY010089; Wed, 11 Oct 2006 09:36:41 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9BGaaXc020672; Wed, 11 Oct 2006 09:36:36 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J6Z00101CO0E900@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Wed, 11 Oct 2006 09:36:36 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J6Z00DVQCSZW0JM@d1-sfbay-09.sun.com>; Wed, 11 Oct 2006 09:36:35 -0700 (PDT) Date: Wed, 11 Oct 2006 09:36:35 -0700 From: John Plocher Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> Sender: John.Plocher@Sun.COM To: John Plocher Cc: PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452D1D93.6080303@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Wp7frEcSGwm1Uu1PC/gGIg)" X-Accept-Language: en-us, en References: <200610062157.k96Lvl0P005256@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 17067 This is a multi-part message in MIME format. --Boundary_(ID_Wp7frEcSGwm1Uu1PC/gGIg) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT An updated spec (with changebars) is attached. A copy is also in the case directory. At a high level, theis new proposal has changed the following: Formalize the IAM:Exposure keyword usage Make the default for PSARC be OPEN replace the the psarc@sun/@sac aliases with psarc-closed@ (for closed cases) and opensolaris-arc@OpenSolaris.org (for open ones) move the membership rosters for open-psarc to os.o: opensolaris-arc-members@OpenSolaris.org opensolaris-arc-interns@OpenSolaris.org opensolaris-arc-licensees@OpenSolaris.org opensolaris-arc-chair@OpenSolaris.org opensolaris-arc-interest@OpenSolaris.org generate "change of address" bounce mail for messages sent to psarc@sun/@sac -John --Boundary_(ID_Wp7frEcSGwm1Uu1PC/gGIg) Content-type: text/plain; name=spec.update Content-transfer-encoding: 7BIT Content-disposition: inline; filename=spec.update Subject: PSARC FastTrack: sac changes to support open psarc cases Updated 10/11/06 - plocher As promised/threatened, here is the proposal for opening up ARC discussions to include the OpenSolaris community. While this proposal presumes some knowledge of "how things are currently being done", I've tried to make it make sense without having to deep dive into the details of the sac infrastructure. -John Contents: Requirements Scope Constraints Proposal Details Use cases Failure modes Requirements: R1) The OpenSolaris bound projects going thru the existing ARC process need to be observable by the external members of the OpenSolaris community. This implies that they: R1a) will receive all email relating to the case R1b) will see the same case archives/materials as internal ARC participants R2) External members of the OpenSolaris community must be able to participate as equals in the review of open ARC cases. This implies that they: R2a) can send mail about the case that goes to the entire ARC community Out of scope: R2b) Direct submission of fasttracks and onepagers by members of the external community. R3) Cross-ARC discussions still need to be supported (i.e., joint PSARC/LSARC reviews...) Scope: In: Participating as peers in the review of all OpenSolaris ARC Reviews. This means being able to comment, not just watch. Out: External ARC membership, internship or licensees Out: Direct external submission of cases or materials (These will be the focus of followup efforts) In: PSARC focus Out: Other ARCs (but R3 (above) may require more) In: Mechanisms focused on email communication Out: Logistics of ARC meetings, conference calls, etc Out: Moving all of PSARC and its SAC archives/tools off of sac.sfbay and onto opensolaris.org. Constraints: C1) Don't surprise people by delivering mail to external people when it is sent to a Sun-internal alias. C2) Don't expose mail archives that contain "internal" email messages (via C1) (This impacts the mirroring of case materials on opensolaris.org and the diligance needed to publish historical cases) C3) Don't subdivide the community when reviewing open cases. Internal PSARC and external Community participants should experience the same behaviors (and face the same obstacles) C4) Internal and External participants should use the same tools where possible. C4) Don't break the existing tools used by PSARC members. Proposal: Ditch the current psarc-ext cruft as a failed (but useful) experiment. Move all 3 of the psarc-ext cases (550, 555, 561) back into the psarc case hierarchy. Fix up the projects.db file on sac to reassign them to psarc. New cases will be assigned to PSARC independently of whether or not they were open or closed. Modify the onepager template to ask whether a proposal is open or closed. Ditto for sac_nextcase. Use the info to initialize the IAM:Exposure field. Set up the sac aliases to have the sac mail filter do "bounce mail checks" before sending mail on to real people (psarc members, opensolaris.org subscribers, ...) or bouncing back to the sender. Have the sac mail filter automatically forward open mail to external observers for open cases. Detect "intent mismatches": Open case mail sent to a closed alias should bounce, closed case mail to an open alias can be allowed. Use the IAM:Exposure field to identify whether a case is open or not; use the sac mail filter and /etc/aliases to tag aliases as open or closed. | Formalize the IAM:Exposure keyword usage | Make the default for PSARC be OPEN Details: (See materials.inception/aliases.arc.template for the changes to /etc/aliases) Modify sac_mail_filter.pl: M1) Add command line option to specify the Exposure Policy: -p {open,closed} The default is closed. sac_mail_filter and all the sac.sfbay mail aliases are "SAC tools consolidation" private implementation details For each case found on the Subject: line: M1a) if any "Exposure: open" and -p closed Do not deliver the mail to anyone. If there is only ONE To: or Cc: address, bounce it back to the sender with a message like the following: "Error: Private conversations are not allowed about open cases. Your email was not delivered to anyone. You addressed your mail to a 'closed' alias, but referred to an 'open' case () on the Subject: line. To Fix: ..." If there are multiple To:/Cc: aliases, bounce with a message like: "Error: Private conversations are not allowed about open cases. Your email was not delivered to , but it was delivered to . You addressed your mail to a 'closed' alias, but referred to an 'open' case () on the Subject: line. To Fix: ..." M1b) "Exposure: open" and -p open Forward to psarc-subscribers Forward to IAM:Interest list Forward to psarc-interest-ext@sun. M1c) "Exposure: closed/manual and -p closed Forward to psarc-subscribers Forward to any "*@sun.com" on IAM:Interest list. DO NOT forward to non-@sun.com IAM:Interest DO NOT forward to psarc-interest-ext@sun. M1d) "Exposure: closed/manual and -p open | [preferred] ALTERNATIVE 1: (same as M1b: open/open) Forward to psarc-subscribers Forward to all IAM:Interest lists Forward to psarc-interest-ext@sun ALTERNATIVE 2: (similar to M1a: mismatch) Do not deliver the mail to anyone, but instead bounce the mail with an "intent error" like the above. M2) log messageIDs and check for duplicates. This needs to be multi-thread/multi-process safe to avoid race conditions. M3) Allow IAM:Interest to contain the name of an ARC to be included in discussions (instead of requiring a hardcoded alias). That is, allow Interest: WSARC, John.Plocher@Sun.Com, Joerg@OpenSolaris.org Use this to generate the proper forwarding aliases depending on the case's open/closed state: open => *arc-subscribers, *arc-interest-ext@sun closed => *arc-subscribers ONLY | M4) Make the default for PSARC be OPEN: | Modify the existing Committed Private PSARC sac mail alias implementation from the existing psarc@sac: sac-mail-filter psarc-subscribers [for reference, psarc-subscribers is a project private implementation detail, made up of psarc-member-list psarc-intern-list psarc-interest private-psarc-log private-psarc-hypermail arc-interest ] | to: | o Retire the existing PSARC aliases | Find and replace instances of psarc on IAM:Interest lists | o Have people send all psarc mail to opensolaris-arc@os.o | instead. | o Create a set of PSARC-CLOSED aliases to replace them | o Set the mail filter for these closed aliases to -p closed | psarc@sac: | bounce mail with an explanation about | the new opensolaris aliases and psarc-closed | psarc-closed@sac: | sac_mail_filter -p closed M5) Create (as "SAC tools consolidation private") psarc-ext@sac: sac_mail_filter -p open M6) Create (as "SAC tools consolidation private") psarc-interest-ext@sun.com (via netadmin) Populate with | opensolaris-arc-members@OpenSolaris.org | opensolaris-arc-interns@OpenSolaris.org | opensolaris-arc-interest@OpenSolaris.org | M7) Create (as Public/Committed) | opensolaris-arc-members@OpenSolaris.org | opensolaris-arc-interns@OpenSolaris.org | opensolaris-arc-licensees@OpenSolaris.org | opensolaris-arc-chair@OpenSolaris.org | Set the mailman ownership to be SAC staff | plus PSARC-Chair | Populate the above with the current PSARC | people. | Rename | opensolaris-arc@OpenSolaris.org to | opensolaris-arc-interest@OpenSolaris.org | Create | opensolaris-arc@OpenSolaris.org | as an alias that only redirects incoming | email to psarc-ext@sac (i.e., it is | not a general-subscription alias) (Repeat for psarc-members, psarc-record, etc as required) M8) Repeat for lsarc, wsarc, fwarc, but don't populate their *-interest-ext@sun.com aliases with anything for now. | This implies the creation of a set of "pointer | aliases" such as WSARC@opensolaris.org | M9) Formalize IAM:Exposure: | A case's IAM file may contain an "Exposure" entry to | indicate whether the case and its materials can be exposed | outside of Sun: | | Exposure: [open|closed|manual] | | For cases that do not have an explicit IAM:Exposure line, | their state will default to be "unknown". For | publishing/disclosure purposes, "unknown" cases shall be | treated as if they were "closed". | | It is an error for a case's IAM file to explicitly contain | "Exposure: unknown" | | Cases marked "closed" are marked that way because there is | some explicit reason as to why they can not be exposed. | There should be an IAM:Comment that describes why this case | is closed and what (if any) actions c/would trigger a | change. | | Cases marked "open" imply that everything in the case | directory (with the exception of the "uirb" and "sc" | subdirs) is appropriate for unrestricted disclosure to | external-to-sun communities. | | Cases marked "manual" imply that some details about the | case can be made public; in general, those things are | contained in files that have "opensolaris" in their name. Use cases: Send all closed case email to PSARC-CLOSED@sun.com Send all open case email to opensolaris-arc@opensolaris.org Generate bounce messages when an open/closed mismatch is detected. Normal closed behavior: | To: PSARC-CLOSED@Sun.Com (a closed alias) Subject: 2006/400 (a closed case) | PSARC-CLOSED@Sun.Com -> psarc-closed@sac -> sac-mail-filter-filter -p closed PSARC/2006/400/IAM::Exposure: closed matches the -p closed filter attribute, so send out mail to the usual internal suspects... | Change-Of-Address bounce | | To: psarc@sun.com | Subject: | psarc@sun.com | psarc@sac -> | Generate a change-of-address bounce that | explains the change to open by default | and the use of the new aliases | opensolaris-arc@os.o and psarc-closed@sun Normal open behavior: | To: opensolaris-arc@OpenSolaris.org (an open alias) Subject: 2006/555 (an open case) | opensolaris-arc@OpenSolaris.org -> psarc-ext@sac -> sac-mail-filter-filter -p open Exposure: open matches the -p open filter attribute, so send out mail to the usual internal and external suspects... Mismatch (private discussions on open cases): | To: PSARC-CLOSED@Sun.Com (a closed alias) Subject: 2006/555 (an open case) Exposure: open DOES NOT match the -p closed filter attribute, so bounce the message back to sender with an error. Mismatch (open discussions on closed cases): | To: opensolaris-arc@OpenSolaris.org (an open alias) Subject: 2006/400 (a closed case) Exposure: closed DOES NOT match the -p open filter attribute, but the message itself is non- proprietary. Send a warning message to the sender informing them that, since the case is closed, public discussion is not desirable, but that their message *was* delivered. Send out mail to the usual internal and external suspects. [Option: tag the message with a note saying "public discussion about a private case" to alert recipients to consider what they say?] Crossposting to multiple internal ARCs: To: WSARC@Sun.Com | Cc: PSARC-CLOSED@Sun.Com Subject: 2006/400 (a closed case) Message will get processed by the mail filter twice. The first invocation will log the messageID, process the message, archive the mail and forward it on to any sun-internal IAM:Interest lists; all other filter invocations will see that the messageID has been processed and will only send the message on to the per-ARC specific subscribers (but not re-archive or resend to any IAM:interest aliases). Crossposting to multiple external ARCs: To: WSARC@OpenSolaris.org | Cc: opensolaris-arc@OpenSolaris.org Subject: 2006/550 (an open case) Message will get processed by the mail filter twice. The first invocation will log the messageID, process the message, archive the mail and forward it on to any IAM:Interest lists; all other filter invocations will see that the messageID has been processed and will only send the message on to their per-ARC specific subscribers (but not re-archive or resend to any IAM:interest aliases). Failure modes: Crossposting between open and closed aliases starts conversations that can not be continued, gives incorrect user feedback and segregates the community: To: WSARC@Sun.Com | Cc: opensolaris-arc@OpenSolaris.org Subject: 2006/555 (an open case) The message will generate a bounce back to the sender via the WSARC alias due to the mismatch between a closed alias and an open case. This means that WSARC members will not see this email. The message *will* go to PSARC members (et.al) and psarc-interest-ext@sun as expected because of the Cc to opensolaris-arc@OpenSolaris.org. The bounce message will alert the sender to the fact that their email only went to part of the intended audience. Followups from external people to the "closed ARC alias" will be dropped by netadmin (because of the "no mail from the Internet" alias property). Followups from external people cc'd to the "open ARC alias" will succeed, but only to part of the intended audience. Followups from within Sun will again trigger this failure. There is not much that tools on sac.sfbay can do about this type of "pilot error"; even lifting the "no internet mail" block on the *ARC@sun aliases won't help. Take away: Don't mix open and closed policy aliases. Instead, use either M3 (vastly preferred): Add "WSARC" to PSARC/2006/550's IAM:Interest Send mail to To: opensolaris-arc@OpenSolaris.org Subject: 2006/555 (an open case) or M6: Send mail to To: WSARC@OpenSolaris.org Cc: opensolaris-arc@OpenSolaris.org Subject: 2006/555 (an open case) To: WSARC@Sun.Com Bcc: psarc-ext@sac.sfbay Subject: 2006/555 (an open case) This is similar to the above failure, except that nobody at all will be able to reply. The message will generate a bounce via the WSARC alias, but will go to PSARC members(et.al) and psarc-interest-ext@sun because of the Bcc. Follow ups (to WSARC@sun.com) from outside of Sun will be dropped by netadmin because of its "no mail from the Internet property; follow ups from within Sun to the WSARC alias will generate bounces (M1a, above). Take away: The *@sac aliases (like psarc-ext) are ARC consolidation private interfaces; don't use them. --Boundary_(ID_Wp7frEcSGwm1Uu1PC/gGIg)-- From sacadmin Wed Oct 11 10:39:43 2006 Received: from athyra.sfbay.sun.com (athyra.SFBay.Sun.COM [129.146.228.66]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BHdhZC011106; Wed, 11 Oct 2006 10:39:43 -0700 (PDT) Received: from athyra (localhost [127.0.0.1]) by athyra.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9BHdhY2016129; Wed, 11 Oct 2006 10:39:43 -0700 (PDT) From: Mike Kupfer To: John Plocher cc: James Carlson , Darren J Moffat , Joseph Kowalski , Ed.Gould@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: Message from John Plocher of "Tue, 10 Oct 2006 13:00:06 PDT." <452BFBC6.1020500@Sun.COM> X-Mailer: MH-E 7.94; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Wed, 11 Oct 2006 10:39:43 -0700 Message-ID: <16128.1160588383@athyra> Sender: kupfer@athyra.sfbay.sun.com Status: RO Content-Length: 592 >>>>> "John" == John Plocher writes: >> Currently, on opensolaris.org, you need to subscribe to a list in >> order to post to it. John> This has been changed as a result of the ksh case (so I have been John> told). I think there was a miscommunication here. opensolaris-arc has been modified to accept email from any sun.com address. (This is easily done via the Mailman admin interface.) But the policy of allowing posting to all lists if you're subscribed to any list has not yet been implemented. (This requires changes to Mailman source, apparently.) mike From sacadmin Wed Oct 11 10:48:32 2006 Received: from athyra.sfbay.sun.com (athyra.SFBay.Sun.COM [129.146.228.66]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BHmWLI011239; Wed, 11 Oct 2006 10:48:32 -0700 (PDT) Received: from athyra (localhost [127.0.0.1]) by athyra.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9BHmWLg016177; Wed, 11 Oct 2006 10:48:32 -0700 (PDT) From: Mike Kupfer To: Joseph Kowalski cc: Ed.Gould@sun.com, James.D.Carlson@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: Message from Joseph Kowalski of "Tue, 10 Oct 2006 10:02:14 -1000." <200610102002.k9AK2oMe664376@jurassic.eng.sun.com> X-Mailer: MH-E 7.94; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Wed, 11 Oct 2006 10:48:32 -0700 Message-ID: <16176.1160588912@athyra> Sender: kupfer@athyra.sfbay.sun.com Status: RO Content-Length: 361 >>>>> "jek3" == Joseph Kowalski writes: jek3> I think for a couple of years, we're going to need to provide more jek3> context in our mail. I'd encourage folks to give pointers to specific cases (opinions), when possible. If it's a historical case that hasn't been opened, that will be a big clue that we need to open it. mike From sacadmin Wed Oct 11 11:03:29 2006 Received: from athyra.sfbay.sun.com (athyra.SFBay.Sun.COM [129.146.228.66]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BI3TcW013155; Wed, 11 Oct 2006 11:03:29 -0700 (PDT) Received: from athyra (localhost [127.0.0.1]) by athyra.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9BI3S0q016261; Wed, 11 Oct 2006 11:03:28 -0700 (PDT) From: Mike Kupfer To: James Carlson cc: Joseph Kowalski , Ed.Gould@sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: Message from James Carlson of "Wed, 11 Oct 2006 09:12:06 EDT." <17708.60838.473496.936917@gargle.gargle.HOWL> X-Mailer: MH-E 7.94; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Wed, 11 Oct 2006 11:03:28 -0700 Message-ID: <16260.1160589808@athyra> Sender: kupfer@athyra.sfbay.sun.com Status: RO Content-Length: 1155 >>>>> "Jim" == James Carlson writes: Jim> The central question, then, is whether the ARC's decisions reflect Jim> what's best for Solaris or what's best for Sun. Given that the Jim> effect of such a decision is across the entire community -- future Jim> cases will be reviewed against the requirements set by such a case Jim> -- I don't see how we can reasonably have such a discussion in Jim> private. The whole community must accept the costs of the Jim> decisions made. Jim> The simple result, I think, is that because of Open Solaris, Sun is Jim> no longer in direct and complete control of the direction of Jim> Solaris. That might be a frightening concept, but I think it's Jim> inevitable. There is no Open Solaris without a loss of control. I think this (and the rest of Jim's mail) sums things up very well. As it says in http://www.opensolaris.org/os/about/ Decisions within the project are made independently from those concerning Sun's business. Sun's management controls the business aspects of the Solaris product, but will not exert undue influence within the OpenSolaris community. mike From sacadmin Wed Oct 11 11:24:54 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BIOsv3014409 for ; Wed, 11 Oct 2006 11:24:54 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9BIOox25027; Wed, 11 Oct 2006 12:24:51 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J6Z00A05HTEYQ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Oct 2006 11:24:50 -0700 (PDT) Received: from athyra.sfbay.sun.com ([129.146.228.66]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J6Z00ITEHTEY8A0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 11 Oct 2006 11:24:50 -0700 (PDT) Received: from athyra (localhost [127.0.0.1]) by athyra.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9BIOngi016312; Wed, 11 Oct 2006 11:24:49 -0700 (PDT) Date: Wed, 11 Oct 2006 11:24:48 -0700 From: Mike Kupfer Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: Message from John Plocher "of Wed, 11 Oct 2006 08:44:50 PDT." <452D1172.8000706@Sun.COM> Sender: kupfer@athyra.sfbay.sun.com To: John Plocher Cc: Darren J Moffat , plocher@sac.sfbay.sun.com, psarc@sun.com, arc-chairs@sun.com Message-id: <16311.1160591088@athyra> X-Mailer: MH-E 7.94; nmh 1.0.4; XEmacs 21.4 (patch 18) Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1164 >>>>> "John" == John Plocher writes: John> The current implementation of os.o (run by IT/ops...) makes it John> effectively impossible to add executable infrastructure to the John> site. Yes this is broken, no it isn't being fixed - no $$$$. The entire picture is a little complicated. Part of the infrastructure is run by WPE--the same people who run www.sun.com. This is mostly low-level stuff: power, networking, routers, etc. Service monitoring is done by the same contracting house that www.sun.com uses. WPE used to own more of opensolaris.org, but we (the OpenSolaris core team) took over control of higher-level components so that we could proceed quickly with the support for code repositories. John's right that there are multiple projects competing for limited staffing and contracting dollars. Besides the code repository work (we're close to done with Subversion, but there's still a lot to do for Mercurial), the external interface to Bugster needs quite a bit of work. Still, as Darren suggested, I'd send mail to website-discuss as the first step in getting the necessary mail infrastructure changes made. mike From sacadmin Wed Oct 11 11:26:39 2006 Received: from athyra.sfbay.sun.com (athyra.SFBay.Sun.COM [129.146.228.66]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BIQdSW014484; Wed, 11 Oct 2006 11:26:39 -0700 (PDT) Received: from athyra (localhost [127.0.0.1]) by athyra.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9BIQcin016322; Wed, 11 Oct 2006 11:26:38 -0700 (PDT) From: Mike Kupfer To: Darren J Moffat cc: Alan Coopersmith , Ed Gould , James Carlson , Joseph Kowalski , Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: Message from Darren J Moffat of "Wed, 11 Oct 2006 12:17:29 BST." <452CD2C9.6020302@Sun.COM> X-Mailer: MH-E 7.94; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Wed, 11 Oct 2006 11:26:38 -0700 Message-ID: <16321.1160591198@athyra> Sender: kupfer@athyra.sfbay.sun.com Status: RO Content-Length: 445 >>>>> "Darren" == Darren J Moffat writes: Darren> For example lets say some change to the VM system. How would we Darren> accomodate that for non Sun OpenSolaris distros ? How do Linux Darren> distros do that today ? Answer: Each vendor applies their own Darren> set of kernel patches and the main-line Linus Linux stays the Darren> same. That might be the answer we go for as well. Ugh. I hope we can do better than that. mike From sacadmin Wed Oct 11 14:07:39 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.144]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BL7c0s018831; Wed, 11 Oct 2006 14:07:38 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9BL7WtI120950; Wed, 11 Oct 2006 14:07:37 -0700 (PDT) Message-Id: <200610112107.k9BL7WtI120950@jurassic.eng.sun.com> Date: Wed, 11 Oct 2006 11:06:52 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Joseph.Kowalski@eng.sun.com, james.d.carlson@sun.com Cc: Ed.Gould@sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Y7DsvHG2xZRyO8iUW96/3A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1457 > From: James Carlson ... > Joseph Kowalski writes: > > > From: James Carlson > > ... > > > Do we have a technical means available to extract those closed > > > discussions from the log, so that we can make the proper set available > > > to Open Solaris participants? Is this really a matter of having some > > > human editor go through and separate the bits? > > > > I assumed that the open discussion would go to the open alias, that > > the closed dicussion would go to the closed alias, each would log > > to its own, distinct log file. Isn't the only minor question where > > the closed log for an open case? (.mail? nah,...) > > > > Am I missing something? > > I didn't see that in the proposal. It wasn't. I just thought it was a rather obvious answer. > In any event, I'm still opposed to the idea of having closed > architectural discussions about an open case. Given the risks for > Open Solaris, I don't think it's wise. As I said, Policy should discourage this. I'm just not willing based on "proof by lack of imagination" to not think that having the mechanism is a good thing, even if we don't use it. I've deleted rest of the message, because it gets into what would be or would not be appropriate discussion for a closed discusion associated with an open case. I don't think it matters. I'm not of the belief that I can forsee all such possibilities at this time. - jek3 From sacadmin Wed Oct 11 14:31:10 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BLV9rO019789; Wed, 11 Oct 2006 14:31:10 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9BLXkJd015661; Wed, 11 Oct 2006 17:33:46 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9BLXjOh015658; Wed, 11 Oct 2006 17:33:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17709.25401.551732.74970@gargle.gargle.HOWL> Date: Wed, 11 Oct 2006 17:33:45 -0400 From: James Carlson To: Joseph Kowalski Cc: Ed.Gould@sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <200610112107.k9BL7WtI120950@jurassic.eng.sun.com> References: <200610112107.k9BL7WtI120950@jurassic.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1383 Joseph Kowalski writes: > > In any event, I'm still opposed to the idea of having closed > > architectural discussions about an open case. Given the risks for > > Open Solaris, I don't think it's wise. > > As I said, Policy should discourage this. > > I'm just not willing based on "proof by lack of imagination" to not think > that having the mechanism is a good thing, even if we don't use it. > > I've deleted rest of the message, because it gets into what would be or > would not be appropriate discussion for a closed discusion associated with > an open case. I don't think it matters. I'm not of the belief that I > can forsee all such possibilities at this time. I'm concerned that with a mechanism in place, that'll be temptation enough to use it for inappropriate purposes -- in particular, for discussing issues that, despite our claims to some proprietary interest, still have an effect on the wider community. I could possibly go along grumbling if the mechanism were just very hard to invoke and use, but even at that, I think we're starting off on the wrong foot, and I'd be happier if we decided to burn that bridge when we came to it. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Oct 11 14:36:45 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BLaj1c020184; Wed, 11 Oct 2006 14:36:45 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9BLaehq129238; Wed, 11 Oct 2006 14:36:44 -0700 (PDT) Message-Id: <200610112136.k9BLaehq129238@jurassic.eng.sun.com> Date: Wed, 11 Oct 2006 11:35:59 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: Joseph.Kowalski@eng.sun.com, james.d.carlson@sun.com Cc: Ed.Gould@sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: gkyZIN4b1mTbJXYHHFtMSg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 958 > From: James Carlson ... > I'm concerned that with a mechanism in place, that'll be temptation > enough to use it for inappropriate purposes -- in particular, for > discussing issues that, despite our claims to some proprietary > interest, still have an effect on the wider community. > > I could possibly go along grumbling if the mechanism were just very > hard to invoke and use, but even at that, I think we're starting off > on the wrong foot, and I'd be happier if we decided to burn that > bridge when we came to it. Hard to use? Nah,... Trust the power of peer pressure. All of us will get the messages and can force the "why private" issue. It won't take long for the population to catch on. That said, if people think it should be hard to use, I'm OK with that also. I don't want to "burn the bridge" when we come to it, because if/when we get to that point, we won't have time to properly consider it. - jek3 From sacadmin Wed Oct 11 14:41:40 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BLfeAH020443; Wed, 11 Oct 2006 14:41:40 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9BLiG2u015752; Wed, 11 Oct 2006 17:44:16 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9BLiGMR015749; Wed, 11 Oct 2006 17:44:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17709.26032.29950.791532@gargle.gargle.HOWL> Date: Wed, 11 Oct 2006 17:44:16 -0400 From: James Carlson To: Joseph Kowalski Cc: Ed.Gould@sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-Reply-To: <200610112136.k9BLaehq129238@jurassic.eng.sun.com> References: <200610112136.k9BLaehq129238@jurassic.eng.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 884 Joseph Kowalski writes: > Trust the power of peer pressure. All of us will get the messages and > can force the "why private" issue. It won't take long for the population > to catch on. Frankly, based on the experience we've had so far with our various development mailing lists, I doubt it. Casual mistakes like this are made all the time. > That said, if people think it should be hard to use, I'm OK with that > also. OK. > I don't want to "burn the bridge" when we come to it, because if/when > we get to that point, we won't have time to properly consider it. I'd like to be able to say "the tools don't support it, so please just don't do that." -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Wed Oct 11 15:25:47 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BMPlUX022305; Wed, 11 Oct 2006 15:25:47 -0700 (PDT) Received: from [129.146.11.205] (sr1-umpk-19.SFBay.Sun.COM [129.146.11.205]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9BMPhqE147507; Wed, 11 Oct 2006 15:25:47 -0700 (PDT) Message-ID: <452D6F67.5070304@sun.com> Date: Wed, 11 Oct 2006 15:25:43 -0700 From: John Plocher Reply-To: john.plocher@sun.com Organization: Systems Architecture Council - Tools and Process User-Agent: Mail/News 1.5.0.5 (X11/20060813) MIME-Version: 1.0 To: James Carlson CC: Joseph Kowalski , Ed.Gould@sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] References: <200610112107.k9BL7WtI120950@jurassic.eng.sun.com> <17709.25401.551732.74970@gargle.gargle.HOWL> In-Reply-To: <17709.25401.551732.74970@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 695 > I'm concerned that with a mechanism in place, that'll be temptation > enough to use it for inappropriate purposes -- in particular, for > discussing issues that, despite our claims to some proprietary > interest, still have an effect on the wider community. +1 One sufficient mechanism would be to have such discussions (if needed, on an occasional and infrequent basis) on the psarc-closed@sun alias *without* having the case number in the email Subject: line. Another would to generate an annoying warning when closed discussions are sent to an open case, but still archive the conversation in a mail.closed mailbox. I'm not sure it is worth the effort to do the latter. -John From sacadmin Wed Oct 11 17:34:24 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9C0YOmb025167; Wed, 11 Oct 2006 17:34:24 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9C0YJkB177423; Wed, 11 Oct 2006 17:34:23 -0700 (PDT) Message-Id: <200610120034.k9C0YJkB177423@jurassic.eng.sun.com> Date: Wed, 11 Oct 2006 14:33:38 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] To: James.D.Carlson@sun.com, john.plocher@sun.com Cc: Joseph.Kowalski@eng.Sun.COM, Ed.Gould@sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: qFEoL1flxb1UAgkSlhh2iA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1423 OK. I'm not lying down on the tracks. You just owe me a coffee when the firedrill happens. Actually, the worse (I guess) would be somebody having to manually construct the mail log. - jek3 > Date: Wed, 11 Oct 2006 15:25:43 -0700 > From: John Plocher > User-Agent: Mail/News 1.5.0.5 (X11/20060813) > MIME-Version: 1.0 > To: James Carlson > CC: Joseph Kowalski , Ed.Gould@sun.com, Glynn.Foster@sun.com, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@sun.com > Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] > Content-Transfer-Encoding: 7bit > > > > I'm concerned that with a mechanism in place, that'll be temptation > > enough to use it for inappropriate purposes -- in particular, for > > discussing issues that, despite our claims to some proprietary > > interest, still have an effect on the wider community. > > > +1 > > One sufficient mechanism would be to have such discussions (if needed, > on an occasional and infrequent basis) on the psarc-closed@sun alias > *without* having the case number in the email Subject: line. > > Another would to generate an annoying warning when closed discussions are > sent to an open case, but still archive the conversation in a > mail.closed mailbox. > > I'm not sure it is worth the effort to do the latter. > > -John > From sacadmin Thu Oct 12 03:57:47 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9CAvlcZ005990; Thu, 12 Oct 2006 03:57:47 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k9CAvka6018676; Thu, 12 Oct 2006 03:57:47 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9CAveuu027803; Thu, 12 Oct 2006 11:57:40 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7000501RQB4700@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 12 Oct 2006 11:57:40 +0100 (BST) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7000J9RRS34T10@d1-emea-09.sun.com>; Thu, 12 Oct 2006 11:57:40 +0100 (BST) Date: Thu, 12 Oct 2006 11:57:39 +0100 From: Darren J Moffat Subject: Re: sac changes to support open psarc cases [PSARC/2006/569 Timeout: unknown] In-reply-to: <16128.1160588383@athyra> Sender: Darren.Moffat@Sun.COM To: Mike Kupfer Cc: John Plocher , James Carlson , Joseph Kowalski , Ed.Gould@Sun.COM, plocher@sac.sfbay.sun.com, PSARC@sac.sfbay.sun.com, arc-chairs@Sun.COM Message-id: <452E1FA3.10401@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <16128.1160588383@athyra> User-Agent: Thunderbird 1.5.0.5 (X11/20060912) Status: RO Content-Length: 1078 Mike Kupfer wrote: >>>>>> "John" == John Plocher writes: > >>> Currently, on opensolaris.org, you need to subscribe to a list in >>> order to post to it. > > John> This has been changed as a result of the ksh case (so I have been > John> told). > > I think there was a miscommunication here. opensolaris-arc has been > modified to accept email from any sun.com address. (This is easily done > via the Mailman admin interface.) But the policy of allowing posting to > all lists if you're subscribed to any list has not yet been implemented. > (This requires changes to Mailman source, apparently.) I don't believe it does require source code change. I've proposed before away to do this. It doesn't need to be 100% real time. It can be done by dumping out of the website user database all the email addresses people supplied for their accounts and loading them into the accept list of all the mailing lists. That as far as I know can be scripted. Sure it isn't perfect but it is much better than what we have today. -- Darren J Moffat From John.Plocher@Sun.COM Thu Oct 19 12:30:51 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9JJUpr7017962 for ; Thu, 19 Oct 2006 12:30:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9JJUo209595 for <@sunmail2.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 19 Oct 2006 13:30:51 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7E00L0HE7CDY00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 12:30:48 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7E0072ME7C8QB0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 12:30:48 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9JJUlap019707 for ; Thu, 19 Oct 2006 12:30:47 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7E00K01E6RX800@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 12:30:47 -0700 (PDT) Received: from [129.146.11.154] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7E001JME7ADRMH@d1-sfbay-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 12:30:47 -0700 (PDT) Date: Thu, 19 Oct 2006 12:30:46 -0700 From: John Plocher Subject: Next steps in opening up the ARC process - PSARC 2006/569 - moving PSARC out onto the Open Sender: John.Plocher@Sun.COM To: PSARC-EXT@Sun.COM Reply-to: John.Plocher@Sun.COM Message-id: <4537D266.1030801@sun.com> Organization: Systems Architecture Council - Tools and Process 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 User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 15060 [Note to PSARC - I changed this case's IAM:Exposure to open and am moving the continued discussion out into the community. Note to the external community: please feel free to skim thru the case's mail log for context. See http://www.opensolaris.org/os/community/arc/caselog/2006/569/ - John ] We learned quite a bit from the recent set of ksh related ARC cases: (open == "read-only") and (default == "closed") are unacceptable states for the ARC process as it relates to OpenSolaris. The quicker we move away from these states, the better. (Process followed by Sun Engineers != Process followed by external contributers) is also unacceptable. The prototype of "create a shadow PSARC-EXT that is the open equivalent of a closed PSARC" that we used to run the ksh93 case wasn't working well - the archives and workflow tools used by the ARC process within Sun didn't deal well with the split. I spent considerable time with PSARC and other people who were knowledgeable about the internal ARC infrastructure details, brainstorming proposals focused on the logistics of opening things up. That discussion is reflected in the PSARC/2006/569 "case" (which was run as a "closed" case up to now to keep the focus on internal ARC infrastructure and implementation details, and not because it was in any way unsuitable for a wider audience). This mail opens up that case to the wider community; what follows is the result of that initial effort; please consider what is here as simply a starting point for discussion. While much of what follows is "Consolidation Private" to the "Sun ARC infrastructure Consolidation", M5, M6 and M7 concern changes to Committed email interfaces on OpenSolaris.org. -John Requirements: R1) Transparency The OpenSolaris bound projects going thru the existing ARC process need to be observable by the external members of the OpenSolaris community. This implies that they: R1a) will receive all email relating to the case R1b) will see the same case archives/materials as internal ARC participants R2) Participation External members of the OpenSolaris community must be able to participate as equals in the review of open ARC cases. This implies that they: R2a) can send mail about the case that goes to the entire ARC community Out of scope: R2b) Direct submission of fasttracks and onepagers by members of the external community. R3) Membership We need to be able to support external ARC members, Interns and Fasttrack Licensees. R4) Collaboration Cross-ARC discussions still need to be supported (i.e., joint PSARC/LSARC reviews...) R5) Default should be open PSARC desires that all new cases assigned to it that are bound for inclusion into OpenSolaris be open by default, and that it be an exception for a case to be closed. (Note that there are ARCs in Sun other than PSARC which will make their open/closed decision independently) Constraints: C1) Don't surprise people by delivering mail to external people when it is sent to a Sun-internal alias. (Sun network security policy) C2) Don't expose mail archives that contain "internal" email messages (via C1) without verifying that there is nothing proprietary in them. (This impacts the mirroring of case materials on opensolaris.org and the diligence needed to publish historical cases) C3) Don't subdivide the community when reviewing open cases. Internal PSARC and external Community participants should experience the same behaviors (and face the same obstacles) C4) Internal and External participants should use the same mechanisms (where possible). C5) Don't break the existing workflow management tools used by PSARC members. Scope: In: External and internal developers participating as peers in the review of all OpenSolaris ARC Reviews. This means being able to comment on cases, not just watch as they are reviewed by others. Out: Selection and training of external ARC members, interns and/or licensees Out: Direct external submission of cases or materials In: PSARC focus Out: Other ARCs (but R3 (above) may require more) In: Mechanisms focused on email communication Out: Logistics of ARC meetings, conference calls, etc (these are being handled elsewhere) In: Keeping the "PSARC Archives" on an internal Sun system ("sac" aka Systems Architecture Council server) and mirroring the open content on OpenSolaris.org Out: Moving all of PSARC and its SAC archives/tools off of sac.sfbay and onto opensolaris.org. Proposal: Ditch the current psarc-ext cruft as a failed (but useful) experiment. Move all 3 of the psarc-ext cases (550, 555, 561) back into the psarc case hierarchy. Fix up the projects.db file on sac to reassign them to psarc. New cases will be assigned to PSARC independently of whether or not they were open or closed. Modify the onepager template to ask whether a proposal is open or closed. Ditto for sac_nextcase (an internal tool used to submit fasttracks and requests for self-review). Use the info to initialize the IAM:Exposure database field. (Of course, the default for cases submitted by external community members will be "open") Set up the sac aliases to have the sac mail filter do "bounce mail checks" before sending mail on to real people (psarc members, opensolaris.org subscribers, ...) or bouncing back to the sender. "Bounces" are triggered by several edge cases, including invalid case numbers in Subject: lines and the like. Create a set of aliases on opensolaris.org: opensolaris-arc-member-list@ => The list of PSARC members who are active (as core contributers) to an OpenSolaris community. They are the ones who have the voting rights for open ARC decisions. It may be that, as a transition plan, current PSARC members who are not involved as leaders of opensolaris communities are grandfathered as members. opensolaris-arc-intern-list@ => The list of PSARC interns and Community members who wish to play an active role in "open ARC", but who do not get to vote. opensolaris-arc-interest-list@ => Anyone who wishes to "listen in" and join in the discussions, but who don't get a vote. opensolaris-arc-licensee-list@ => the current list of "sponsors" opensolaris-arc@ => psarc-ext@Sun => The sac mail filter with the "-p=open" flag set, forwarding on to the set of opensolaris-arc-member-list@ opensolaris-arc-intern-list@ opensolaris-arc-interest-list@ as well as IAM:Interest lists on a per-case basis Fix the cross posting and Bcc problems on opensolaris.org (need to be a member of all the aliases you crosspost to, implicit destination requires sac mail filter user to be a member as well...) Detect "intent mismatches": Mail about an open case, but sent to a closed alias should bounce with a "we don't wish to keep secrets" error, closed case mail to an open alias can safely (from an "exposure of proprietary info" perspective) be allowed. We can use the IAM:Exposure field to identify whether a case is open or not; use the sac mail filter and /etc/aliases to tag aliases as open or closed. Formalize the IAM:Exposure keyword usage Make the default for PSARC be OPEN Details: Modify the sac mail filter: M1) Add command line option to specify the Exposure Policy: -p {open,closed} The default is closed. For each case found on the Subject: line: M1a) if any "Exposure: open" and -p closed Do not deliver the mail to anyone. If there is only ONE To: or Cc: address, bounce it back to the sender with a message like the following: "Error: Private conversations are not allowed about open cases. Your email was not delivered to anyone. You addressed your mail to a 'closed' alias, but referred to an 'open' case () on the Subject: line. To Fix: ..." If there are multiple To:/Cc: aliases, bounce with a message like: "Error: Private conversations are not allowed about open cases. Your email was not delivered to , but it was delivered to . You addressed your mail to a 'closed' alias, but referred to an 'open' case () on the Subject: line. To Fix: ..." M1b) "Exposure: open" and -p open Forward to psarc-subscribers Forward to IAM:Interest list Forward to psarc-interest-ext@sun. (see below) M1c) "Exposure: closed/manual and -p closed Forward to psarc-subscribers Forward to any "*@sun.com" on IAM:Interest list. DO NOT forward to non-@sun.com IAM:Interest DO NOT forward to psarc-interest-ext@sun. M1d) "Exposure: closed/manual and -p open [preferred] ALTERNATIVE 1: (same as M1b: open/open) Forward to psarc-subscribers Forward to all IAM:Interest lists Forward to psarc-interest-ext@sun ALTERNATIVE 2: (similar to M1a: mismatch) Do not deliver the mail to anyone, but instead bounce the mail with an "intent error" like the above. M2) log messageIDs and check for duplicates. This needs to be multi-thread/multi-process safe to avoid race conditions. M3) Allow IAM:Interest to contain the name of an ARC to be included in discussions (instead of requiring a hardcoded alias). That is, allow Interest: WSARC, John.PlocheratSundotcom Use this to generate the proper forwarding aliases depending on the case's open/closed state: open => wsarc-subscribers, wsarc-interest-ext@sun closed => wsarc-subscribers ONLY M4) Make the default for PSARC be OPEN: Modify the existing Committed Private PSARC sac mail alias implementation from the existing psarc@: sac-mail-filter psarc-subscribers [for reference, psarc-subscribers is a project private implementation detail, made up of psarc-member-list psarc-intern-list psarc-interest private-psarc-log private-psarc-hypermail arc-interest ] to: o Retire the existing PSARC aliases o psarc: bounce mail with an explanation about the new opensolaris aliases and psarc-closed ADD [-b msgtype] to sac mail filter o Find and replace instances of psarc on IAM:Interest lists o Have people send all psarc mail to opensolaris-arc@os.o instead. o Create a set of PSARC-CLOSED aliases to replace them o Set the mail filter for these closed aliases to -p closed psarc-closed: private-psarc-filter-closed psarc-discuss-closed: psarc-record-closed: psarc-business-closed: psarc-agenda-request-closed: psarc-agenda-announce-closed: psarc-materials-closed: M5) Create a new set of open aliases: (with Committed Stability) psarc-ext: private-psarc-filter-ext psarc-discuss-ext: psarc-record-ext: psarc-business-ext: psarc-agenda-request-ext: psarc-agenda-announce-ext: psarc-materials-ext: M6) Create on SUN.COM: (as "SAC tools consolidation private") psarc-interest-ext@sun.com (via netadmin) Populate with opensolaris-arc-members@OpenSolaris.org opensolaris-arc-interns@OpenSolaris.org opensolaris-arc-interest@OpenSolaris.org Note that this and any per-case IAM:Interest entries are the only outbound connection between the sac mail infrastructure and that on OpenSolaris.org. Repeat M5 and M6 for the other Sun ARCs, but don't populate their *-interest-ext@sun.com aliases with anything for now. M7) Create on OPENSOLARIS.ORG: (as Public/Committed) opensolaris-arc-members@OpenSolaris.org opensolaris-arc-interns@OpenSolaris.org opensolaris-arc-licensees@OpenSolaris.org opensolaris-arc-chair@OpenSolaris.org These are to have a "by invitation only" subscription policy. Set the mailman ownership to be SAC staff plus PSARC-Chair, set them to allow all mail from *@sun.com addresses as well as to allow incoming email from anyone who is a subscriber to any other os.o alias. Rename opensolaris-arc@OpenSolaris.org to opensolaris-arc-interest@OpenSolaris.org Rename the existing opensolaris-arc jive forum and mail archives to match. Create opensolaris-arc@OpenSolaris.org as an alias that only redirects incoming email to psarc-ext@sac (i.e., it is not a general-subscription alias but instead vectors all incoming mail to the above PSARC-EXT@Sun mail filtering chain) In particular, it should o not use any mailman moderation/spam filtering (the automatic sun.com spam filters should take care of it) o not feed into any forum or archiving tools on os.o The end result of this is that inbound ARC case discussion email can go to either "opensolaris-arc@os.o" or "psarc-ext@sun"; both will be treated the same. M8) Formalize IAM:Exposure: (Committed) A case's IAM file may contain an "Exposure" entry to indicate whether the case and its materials can be exposed outside of Sun: Exposure: [open|closed|manual] For historical cases that do not have an explicit IAM:Exposure line, their state will default to be "unknown". For publishing/disclosure purposes, "unknown" cases shall be treated as if they were "closed". It is an error for a case's IAM file to explicitly contain "Exposure: unknown" Cases marked "closed" are marked that way because there is some explicit reason as to why they can not be exposed. There should be an IAM:Comment that describes why this case is closed and what (if any) actions c/would trigger a change. Cases marked "open" imply that *everything* in the case directory (with the exception of the "uirb" and "sc" subdirs) is appropriate for unrestricted disclosure to external-to-sun communities. Cases marked "manual" imply that some details about the case can be made public; in general, those things are contained in files that have "opensolaris" in their name. See "How do I publish/request an existing Sun ARC Case?" http://www.opensolaris.org/os/community/arc/arc-faq/arc-publish-historical-checklist/ From Eric.Lowe@sun.com Thu Oct 19 12:53:33 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9JJrVi7018187 for ; Thu, 19 Oct 2006 12:53:32 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9JJrUHR023479 for <@sunmail2.sfbay.sun.com:PSARC-EXT@sun.com>; Fri, 20 Oct 2006 03:53:31 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7E00007F95FD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 12:53:29 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7E00710F949AC0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 12:53:28 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9JJrSeQ006561 for ; Thu, 19 Oct 2006 13:53:28 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7E00801F12XA00@mail-amer.sun.com> (original mail from Eric.Lowe@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 13:53:28 -0600 (MDT) Received: from [129.153.128.46] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7E009KQF93WLL2@mail-amer.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 13:53:28 -0600 (MDT) Date: Thu, 19 Oct 2006 14:53:30 -0500 From: Eric Lowe Subject: Re: Next steps in opening up the ARC process - PSARC 2006/569 - moving PSARC out onto the Open In-reply-to: <4537D266.1030801@sun.com> Sender: Eric.Lowe@sun.com To: John.Plocher@sun.com Cc: PSARC-EXT@sun.com Message-id: <4537D7BA.3000208@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: <4537D266.1030801@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1638 > R2) Participation > External members of the OpenSolaris community > must be able to participate as equals in the > review of open ARC cases. > This implies that they: ... > Out of scope: > R2b) Direct submission of fasttracks and > onepagers by members of the external community. It isn't clear whether you mean this as a temporary gap filling glue (modulo the tools being fixed/updated/migrated) or whether external contributors will never be able to submit fast tracks. It seems really awkward that a fast track licensee wouldn't be able to submit a fast track? A smart mail filter with sender rules should be able to replace sac_nextcase, for instance, and this would seem a lot more "inclusive". > C4) Internal and External participants should use the > same mechanisms (where possible). Which again seems to conflict with R2b above. > C5) Don't break the existing workflow management tools > used by PSARC members. I was able to teach my six year old dog new tricks, why not ARC members? :) > Scope: > Out: Selection and training of external ARC members, > interns and/or licensees Why have an open list if there is no way to become an external licensee defined? Again this is confusing and seems to be exluding the community from participating fully. I don't see how this can be considered out of scope of opening up the ARC process. If the plan is to address this as a follow-up item you should make this clear, please. It's evident there is a lot of work that went into this proposal, and it is much appreciated. - Eric From John.Plocher@Sun.COM Thu Oct 19 13:41:51 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9JKfpH7019632 for ; Thu, 19 Oct 2006 13:41:51 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9JKfof26735 for <@sunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Thu, 19 Oct 2006 13:41:50 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7E0070BHHQL300@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 14:41:50 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7E003TKHHPUL50@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 14:41:49 -0600 (MDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9JKfnpo002320 for ; Thu, 19 Oct 2006 13:41:49 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7E00G01GNARK00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 13:41:49 -0700 (PDT) Received: from [129.146.11.154] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7E0018KHHDDRCI@d1-sfbay-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 13:41:38 -0700 (PDT) Date: Thu, 19 Oct 2006 13:41:37 -0700 From: John Plocher Subject: Re: Next steps in opening up the ARC process - PSARC 2006/569 - moving PSARC out onto the Open In-reply-to: <4537D7BA.3000208@Sun.COM> Sender: John.Plocher@Sun.COM To: Eric Lowe Cc: PSARC-EXT@Sun.COM Reply-to: John.Plocher@Sun.COM Message-id: <4537E301.6040206@sun.com> Organization: Systems Architecture Council - Tools and Process 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: <4537D266.1030801@sun.com> <4537D7BA.3000208@Sun.COM> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 1568 Eric Lowe wrote: >> R2) Participation >> Out of scope: >> R2b) Direct submission of fasttracks and >> onepagers by members of the external community. > > It isn't clear whether you mean this as a temporary gap filling glue > (modulo the tools being fixed/updated/migrated) or whether external > contributors will never be able to submit fast tracks. This is a temporary gap. In the longer short term (not this project, not this project...) it too will be addressed. >> C5) Don't break the existing workflow management tools >> used by PSARC members. > > I was able to teach my six year old dog new tricks, why not ARC members? :) "Gee, how about them 49ers?" :-) >> Scope: >> Out: Selection and training of external ARC members, >> interns and/or licensees > > Why have an open list if there is no way to become an external licensee > defined? This is a temporary gap. In the longer short term (not this project, not this project...) it too will be addressed. > If the plan is to address this as a > follow-up item you should make this clear, please. What you said. Just not as part of this initial enabling effort. Why not? Because that project is a parallel effort driven by a different project team - "PSARC" instead of "John" - which depends on this infrastructure project being complete. It is difficult to create external members if it isn't possible for them to actually *be* members, and it is considered poor form to hack such support into existence *after* it is needed .... -John From richlowe@richlowe.net Thu Oct 19 13:47:57 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9JKlujc019699 for ; Thu, 19 Oct 2006 13:47:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9JKluL08091; Thu, 19 Oct 2006 13:47:56 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7E00507HRVXM00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Oct 2006 13:47:55 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7E007HCHRU9FE0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 19 Oct 2006 13:47:54 -0700 (PDT) Received: from relay12.sun.com (relay12.sun.com [217.140.40.34] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9JKlm3p015719; Thu, 19 Oct 2006 14:47:53 -0600 (MDT) Received: from mms12es.sun.com ([160.41.223.34] [160.41.223.34]) by relay12.sun.com with ESMTP; Thu, 19 Oct 2006 20:47:47 +0000 (Z) Received: from relay12.sun.com (relay12.sun.com [217.140.40.34]) by mms12es.sun.com with ESMTP; Thu, 19 Oct 2006 20:47:47 +0000 (Z) Received: from rwcrmhc11.comcast.net ([216.148.227.151] [216.148.227.151]) by relay12.sun.com with ESMTP; Thu, 19 Oct 2006 20:47:47 +0000 (Z) Received: from [192.168.1.2] (c-71-203-214-110.hsd1.tn.comcast.net[71.203.214.110]) by comcast.net (rwcrmhc11) with ESMTP id <20061019204745m1100s4hvhe>; Thu, 19 Oct 2006 20:47:45 +0000 Date: Thu, 19 Oct 2006 16:47:43 -0400 From: Richard Lowe Subject: Re: Next steps in opening up the ARC process - PSARC 2006/569 - moving PSARC out onto the Open In-reply-to: <4537D266.1030801@sun.com> To: John.Plocher@sun.com Cc: PSARC-EXT@sun.com Message-id: <4537E46F.1000208@richlowe.net> 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: <4537D266.1030801@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060911) Status: RO Content-Length: 4579 John Plocher wrote: > Requirements: > R1) Transparency > The OpenSolaris bound projects going thru the > existing ARC process need to be observable by > the external members of the OpenSolaris community. > This implies that they: > R1a) will receive all email relating to the case > R1b) will see the same case archives/materials > as internal ARC participants > > R2) Participation > External members of the OpenSolaris community > must be able to participate as equals in the > review of open ARC cases. > This implies that they: > R2a) can send mail about the case that goes to > the entire ARC community > Out of scope: > R2b) Direct submission of fasttracks and > onepagers by members of the external community. I assume a followup case will appear relatively soon to deal with this, also? > R3) Membership > We need to be able to support external ARC members, > Interns and Fasttrack Licensees. Combined with the actual selection of licensees being out of scope, this suggests that the technical means must be there, but procedure that will lead to their actual use is out of scope. Why? > R4) Collaboration > Cross-ARC discussions still need to be supported > (i.e., joint PSARC/LSARC reviews...) > > R5) Default should be open > PSARC desires that all new cases assigned to it that > are bound for inclusion into OpenSolaris be open by > default, and that it be an exception for a case to > be closed. (Note that there are ARCs in Sun other > than PSARC which will make their open/closed > decision independently) Skimming the archive of the original discussion, there was some, but not much, mention of criteria to close a case. An explicit statement that those empowered to do so will resist inappropriate use of such a flag would be nice. > > Proposal: > Ditch the current psarc-ext cruft as a failed (but > useful) experiment. Move all 3 of the psarc-ext cases > (550, 555, 561) back into the psarc case hierarchy. Fix > up the projects.db file on sac to reassign them to > psarc. > > New cases will be assigned to PSARC independently of > whether or not they were open or closed. > > Modify the onepager template to ask whether a proposal > is open or closed. Ditto for sac_nextcase (an internal > tool used to submit fasttracks and requests for > self-review). Use the info to initialize the > IAM:Exposure database field. (Of course, the default > for cases submitted by external community members will > be "open") The rest of this proposal suggests that "open" will be the default for all PSARC cases, not just those submitted by external people. If that's the case, this should be adjusted to mention that fact. > Set up the sac aliases to have the sac mail filter do > "bounce mail checks" before sending mail on to real > people (psarc members, opensolaris.org subscribers, ...) > or bouncing back to the sender. "Bounces" are triggered > by several edge cases, including invalid case numbers in > Subject: lines and the like. > > Create a set of aliases on opensolaris.org: > opensolaris-arc-member-list@ => > The list of PSARC members who are active (as > core contributers) to an OpenSolaris community. > They are the ones who have the voting rights for > open ARC decisions. It may be that, as a > transition plan, current PSARC members who are > not involved as leaders of opensolaris > communities are grandfathered as members. Wouldn't any ARC member have voting rights? (as it has been explained to me previously, this is how things work now). Possibly abridging the list of members able to vote seems like something that should require justification. (or my understanding of what has been explained previously is wrong, in which case feel free to point that out in the style of your choosing) > Details: > > > M7) Create on OPENSOLARIS.ORG: (as Public/Committed) > opensolaris-arc-members@OpenSolaris.org > opensolaris-arc-interns@OpenSolaris.org > opensolaris-arc-licensees@OpenSolaris.org > opensolaris-arc-chair@OpenSolaris.org > > These are to have a "by invitation only" > subscription policy. Will the archives of these be public? Will these be mirrored to jive? -- Rich From John.Plocher@sun.com Thu Oct 19 16:40:50 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9JNendl023350 for ; Thu, 19 Oct 2006 16:40:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9JNeVDE004170 for <@sunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Fri, 20 Oct 2006 00:40:38 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7E00D03PRYQL00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 17:40:46 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7E00BCRPRSGHA0@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 17:40:45 -0600 (MDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9JNeenq023679 for ; Thu, 19 Oct 2006 16:40:40 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7E00401PPSPZ00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 16:40:40 -0700 (PDT) Received: from [129.146.11.154] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7E001IXPRRDR1K@d1-sfbay-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Thu, 19 Oct 2006 16:40:40 -0700 (PDT) Date: Thu, 19 Oct 2006 16:40:39 -0700 From: John Plocher Subject: Re: Next steps in opening up the ARC process - PSARC 2006/569 - moving PSARC out onto the Open In-reply-to: <4537E46F.1000208@richlowe.net> Sender: John.Plocher@sun.com To: Richard Lowe Cc: PSARC-EXT@sun.com Reply-to: John.Plocher@sun.com Message-id: <45380CF7.2070007@sun.com> Organization: Systems Architecture Council - Tools and Process 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: <4537D266.1030801@sun.com> <4537E46F.1000208@richlowe.net> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 4525 Richard Lowe wrote: > John Plocher wrote: >> R2b) Direct submission of fasttracks and >> onepagers by members of the external community. > > I assume a followup case will appear relatively soon to deal with this, > also? Yes - see my previous email. > Skimming the archive of the original discussion, there was some, but not > much, mention of criteria to close a case. An explicit statement that > those empowered to do so will resist inappropriate use of such a flag > would be nice. I will work with PSARC to articulate such a policy. >> self-review). Use the info to initialize the >> IAM:Exposure database field. (Of course, the default >> for cases submitted by external community members will >> be "open") > > The rest of this proposal suggests that "open" will be the default for > all PSARC cases, not just those submitted by external people. > If that's the case, this should be adjusted to mention that fact. This is a left-over from before PSARC decided that it was simpler to make the complete "to open" transition in one step instead of delaying it until after the "ability for external people to submit cases" project was complete. The phrase can be deleted since the default for *ALL* PSARC cases is intended to be open. >> opensolaris-arc-member-list@ => >> The list of PSARC members who are active (as >> core contributers) to an OpenSolaris community. >> They are the ones who have the voting rights for >> open ARC decisions. It may be that, as a >> transition plan, current PSARC members who are >> not involved as leaders of opensolaris >> communities are grandfathered as members. > > Wouldn't any ARC member have voting rights? (as it has been explained to > me previously, this is how things work now). Possibly abridging the > list of members able to vote seems like something that should require > justification. (or my understanding of what has been explained > previously is wrong, in which case feel free to point that out in the > style of your choosing) Sorry this was unclear. What I meant to convey was a mix of the following: In parliamentary terms, this covers seat, voice and vote. Seat covers who is involved in the event. In this venue, it is anyone who desires to participate. Voice says who can talk. In this venue, it is the same as above. Vote deals with how decisions are made. Only ARC members have a vote on ARC decisions. ARC interns, licensees, Project/Community members and arc-interest subscribers do not have a vote. The initial list of ARC members will be seeded from the current PSARC members. Other mechanisms (not this project, not this project (thanks Roland!)) will address how to add others to these lists. There may be a disconnect between this short term seeding and the long term desire to have the ARC made up of all the Core Community leaders - what if a current PSARC member isn't visibly active in one of the OpenSolaris communities? It is OK for now if this issue remains open, but it should be something that we (the extended ARC community) think about. >> M7) Create on OPENSOLARIS.ORG: (as Public/Committed) >> opensolaris-arc-members@OpenSolaris.org >> opensolaris-arc-interns@OpenSolaris.org >> opensolaris-arc-interest@OpenSolaris.org These three are not intended to be used directly by people; they are enrollment rosters that are referred to by other aliases and tools. In effect, we need to be able to identify the participants by their role (to determine who can vote...) In this proposal, mail follows the following path: Sender => opensolaris-arc@os.o => psarc-ext@sun => sac mail filter [Bcc]=> psarc-interest-ext@sun => { opensolaris-arc-members@os.o opensolaris-arc-interns@os.o opensolaris-arc-interest@os.o } Thus it should be sufficient to archive only the arc-interest alias, as the others would all be identical. If the mail archiver supports messageID based dup mail filtering, it would also be OK to dump all of these together into one archive to catch misbehavior. If that archive could be named "opensolaris-arc" without clobbering the above mail processing loop, so much the better. >> opensolaris-arc-licensees@OpenSolaris.org >> opensolaris-arc-chair@OpenSolaris.org These *should* be archived and jive'd - sorry it was not clear in the proposal. -John From John.Plocher@sun.com Mon Oct 23 12:10:52 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9NJApHR009257 for ; Mon, 23 Oct 2006 12:10:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9NJATAb016833; Tue, 24 Oct 2006 03:10:48 +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 <0J7L00N1LRXY0200@nwk-avmta-2.sfbay.sun.com>; Mon, 23 Oct 2006 12:10:46 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7L00IM8RXXMZ40@nwk-avmta-2.sfbay.sun.com>; Mon, 23 Oct 2006 12:10:45 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9NJAibs001701; Mon, 23 Oct 2006 12:10:44 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7L00D01RSKD300@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 23 Oct 2006 12:10:44 -0700 (PDT) Received: from [129.146.11.154] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7L005VNRXV7G9P@d1-sfbay-09.sun.com>; Mon, 23 Oct 2006 12:10:44 -0700 (PDT) Date: Mon, 23 Oct 2006 12:10:43 -0700 From: John Plocher Subject: OpenSolaris ARC community email changes (see PSARC 2006/569) Sender: John.Plocher@sun.com To: Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Reply-to: John.Plocher@sun.com Message-id: <453D13B3.5060409@sun.com> Organization: Systems Architecture Council - Tools and Process 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 User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 4964 [Note that this mail is going out to the extended OpenSolaris ARC community as well as Derek and Stephen] Derek and Stephen, As part of the opening up of PSARC, we would like to move the PSARC aliases out onto OpenSolaris.org. Before we actually make any changes, we would like to brainstorm the best way to do them. What follows is an initial starting point for discussion (see PSARC 2006/569 for additional context): In order to have effective external ARC discussions, I think we need the following: o Fix the cross posting and Bcc problems on opensolaris.org. This is the configuration mess that requires all senders to be a member of all the aliases they crosspost to. In addition, fix the "implicit destination" moderation hell resulting from the sac mail filter Bcc'ing to the opensolaris aliases. o Create a set of ARC aliases on opensolaris.org (details follow): opensolaris-arc@ opensolaris-arc-discuss@ opensolaris-arc-record@ opensolaris-arc-chair@ opensolaris-arc-agenda-request@ opensolaris-arc-agenda-interest@ opensolaris-arc-member-list@ opensolaris-arc-intern-list@ opensolaris-arc-licensee-list@ opensolaris-arc-interest@ o We don't want to archive the base opensolaris-arc alias directly because we want to process the mail on sac first. But we *do* want to make it appear as if the opensolaris-arc alias is the one being archived and mirrored. Based on the sac mail filter's alias usage (see details below), it should be sufficient to archive only the opensolaris-arc-interest alias, as the others (opensolaris-arc-member-list and opensolaris-arc-intern-list) should all be identical. If the mail archiver supports messageID based dup mail filtering, it would also be OK to dump all of them together into one archive to catch any misbehavior. If that archive could be named "opensolaris-arc" without clobbering the above mail filtering, so much the better. -John Details: opensolaris-arc@ No - Open subscription No - Archived No - Mirrored in jive forum Content: psarc-ext@sun.com Use: General ARC review discussion alias for Open ARC Cases. All ARC review related mail will be sent to this alias, which forwards the mail on to psarc-ext@Sun which forwards the mail on to [the sac mail filter] The sac mail filter does a bunch of validation work, archiving and filing, and then sends the mail on (via a Bcc:) to the lists of interested people: opensolaris-arc-member-list@ opensolaris-arc-intern-list@ opensolaris-arc-interest@ as well as per-case IAM:Interest lists opensolaris-arc-member-list@ No - Open subscription No - Archived No - Mirrored in jive forum Content: (by invitation only) the list of PSARC members. Use: Private "membership roster" - not for use as a To: or Cc: for email messages opensolaris-arc-intern-list@ No - Open subscription No - Archived No - Mirrored in jive forum Content: (by invitation only) the list of PSARC interns. Use: Private "membership roster" - not for use as a To: or Cc: for email messages opensolaris-arc-interest@ Yes - Open subscription Yes - Archived as opensolaris-arc Yes - Mirrored in jive forum opensolaris-arc Content: the current subscribers to opensolaris-arc Use: Private "membership roster" - not for use as a To: or Cc: for email messages opensolaris-arc-licensee-list@ No - Open subscription Yes - Archived Yes - Mirrored in jive forum Content: the current list of PSARC licensees. Use: General alias to send messages to everyone who is allowed to sponsor ARC fasttracks. opensolaris-arc-agenda-interest@ Yes - Open subscription Yes - Archived Yes - Mirrored in jive forum Content: Use: Announcements of future ARC agendas (or is this better handled by using opensolaris-arc-announce@ ?) opensolaris-arc-discuss@ No - Open subscription No - Archived (becomes part of opensolaris-arc forum/archive) No - Mirrored in jive forum (see above) Content: psarc-discuss-ext@sac.sfbay.sun.com Use: ARC discussions that don't concern any specific case opensolaris-arc-record@ No - Open subscription No - Archived No - Mirrored in jive forum Content: psarc-record-ext@sac.sfbay.sun.com Use: Causes mail to be archived in case mail archive, but not sent to the people on the ARC aliases. opensolaris-arc-chair@ No - Open subscription Yes - Archived Yes - Mirrored in jive forum Content: psarc-chair@sac.sfbay.sun.com Use: Mail about ARC topics to the ARC Chairperson opensolaris-arc-agenda-request@ No - Open subscription Yes - Archived Yes - Mirrored in jive forum Content: psarc-agends-request-ext@sac.sfbay.sun.com Use: Requests to be scheduled for an ARC review From fielding@gbiv.com Mon Oct 23 13:41:31 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9NKfVl9011434 for ; Mon, 23 Oct 2006 13:41:31 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9NKfTn20152; Mon, 23 Oct 2006 13:41:29 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7L0011NW523V00@brm-avmta-1.central.sun.com>; Mon, 23 Oct 2006 14:41:26 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7L00KH3W4ZQ960@brm-avmta-1.central.sun.com>; Mon, 23 Oct 2006 14:41:23 -0600 (MDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9NKfMUN011275; Mon, 23 Oct 2006 14:41:23 -0600 (MDT) Received: from mms27es.sun.com ([150.143.232.134] [150.143.232.134]) by relay23.sun.com with ESMTP; Mon, 23 Oct 2006 20:41:22 +0000 (Z) Received: from mms23bas.mms.us.syntegra.com (mms23bas.mms.us.syntegra.com [192.12.251.50]) by mms27es.sun.com with ESMTP; Mon, 23 Oct 2006 20:41:19 +0000 (Z) Received: from scorpio.lunarpages.com ([209.200.229.70] [209.200.229.70]) by relay23.sun.com with ESMTP; Mon, 23 Oct 2006 20:40:52 +0000 (Z) Received: from wsip-70-183-62-251.oc.oc.cox.net ([70.183.62.251] helo=[10.2.8.52]) by scorpio.lunarpages.com with esmtpa (Exim 4.52) id 1Gc6ci-0007si-LK; Mon, 23 Oct 2006 13:42:16 -0700 Date: Mon, 23 Oct 2006 13:41:06 -0700 From: "Roy T. Fielding" Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453D13B3.5060409@sun.com> To: John.Plocher@sun.com Cc: Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com X-AntiAbuse: Original Domain - sun.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - gbiv.com X-Source: X-Source-Args: X-Source-Dir: References: <453D13B3.5060409@sun.com> Status: RO Content-Length: 1217 On Oct 23, 2006, at 12:10 PM, John Plocher wrote: > [Note that this mail is going out to the extended OpenSolaris ARC > community as well as Derek and Stephen] > > Derek and Stephen, > > As part of the opening up of PSARC, we would like to move the PSARC > aliases out onto OpenSolaris.org. Before we actually make any > changes, we would like to brainstorm the best way to do them. What > follows is an initial starting point for discussion (see PSARC > 2006/569 for additional context): Hi John, There is no need for any of this complexity. If the ARC is going to be an OpenSolaris Community Group, then it can have one discussion list, one announce list, and one issue tracking system. There is no need for the mail system to track who is, or is not, an ARC member/intern and no need for the discussion to take place across multiple mailing lists. People can say who they are when they vote, and the person collating the voting can determine whether or not the vote is binding. Cases can be requested as issues, resolved in discussion on a single list (with only a single notice sent to the requesting group), and the result announced on the announce list plus recorded under the issue. ....Roy From alan.coopersmith@Sun.COM Mon Oct 23 14:24:34 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9NLOXUa012748 for ; Mon, 23 Oct 2006 14:24:33 -0700 (PDT) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9NLO8gi025947 for <@sunmail2.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 24 Oct 2006 05:24:32 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7L00D0XY4UB400@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 23 Oct 2006 14:24:30 -0700 (PDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7L00BA4Y4TM310@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Mon, 23 Oct 2006 14:24:29 -0700 (PDT) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9NLOSTl001066; Mon, 23 Oct 2006 14:24:29 -0700 (PDT) Date: Mon, 23 Oct 2006 14:24:28 -0700 From: Alan Coopersmith Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453D13B3.5060409@sun.com> To: John.Plocher@Sun.COM Cc: Derek Cicero , Stephen Hahn , PSARC-EXT@Sun.COM Message-id: <453D330C.500@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: <453D13B3.5060409@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060731) Status: RO Content-Length: 512 John Plocher wrote: > Use: > Private "membership roster" - not for > use as a To: or Cc: for email messages Is there any reason beyond "that's the way it's always been" to create separate sub-aliases to be used as membership rosters/member-class-designators instead of just keeping the roster on a web page? If it's not ever going to get mail, why have it be a mailing list? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From John.Plocher@sun.com Mon Oct 23 15:41:09 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9NMf8G6014801 for ; Mon, 23 Oct 2006 15:41:08 -0700 (PDT) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9NMed4P011876; Mon, 23 Oct 2006 23:40:51 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7M00K0P1OGP700@nwk-avmta-1.sfbay.Sun.COM>; Mon, 23 Oct 2006 15:41:04 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7M00BFA1OFLV60@nwk-avmta-1.sfbay.Sun.COM>; Mon, 23 Oct 2006 15:41:03 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9NMf3JH023314; Mon, 23 Oct 2006 15:41:03 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7M00D011KAHL00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Mon, 23 Oct 2006 15:41:03 -0700 (PDT) Received: from [129.146.11.154] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7M005YU1O97GWS@d1-sfbay-09.sun.com>; Mon, 23 Oct 2006 15:41:03 -0700 (PDT) Date: Mon, 23 Oct 2006 15:40:57 -0700 From: John Plocher Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453D330C.500@sun.com> Sender: John.Plocher@sun.com To: Alan Coopersmith Cc: Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Reply-to: John.Plocher@sun.com Message-id: <453D44F9.1080503@sun.com> Organization: Systems Architecture Council - Tools and Process 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: <453D13B3.5060409@sun.com> <453D330C.500@sun.com> User-Agent: Mail/News 1.5.0.5 (X11/20060813) Status: RO Content-Length: 2405 Alan Coopersmith wrote: > Is there any reason beyond "that's the way it's always been" to create > separate sub-aliases to be used as membership > rosters/member-class-designators > instead of just keeping the roster on a web page? It would be much much better if there were a supported structured way to keep such a set of lists; if it existed, we would simply have the email system use it in the course of sending email, and the web pages could automatically include the list on the leaders page. I am making this proposal because such a structured mechanism does not exist and parsing an html page is not a viable option. I would be happy if the result of this discussion was that the OS.o web app was extended to provide such a mechanism. We could redefine the ARC community to be the Review Body itself, instead of a community that is focused on the care and feeding of the ARC process. This would let us try and correlate the community roles with the ARC ones: Community Leader = ARC web support Core Community Member = ARC member Community Member = ARC Intern ?? = ARC Licensee Observer = ARC Interest Community Announcements = ARC Agenda Interest ?? = ARC Agenda Request Mechanism This begs the questions of if/when the opensolaris web/email software will support these roles, and if/when the web observer feature will ever be integrated into the email system. > If it's not ever going to get mail, why have it be a mailing list? These roster lists will get email, just not directly from users. If they _were_ used directly, we would be splitting the community into silos, something we don't really want to do. Members would see one email stream, interns another, and interested observers a third. No thanks! The intent is to have one set of public email aliases that everyone uses: opensolaris-arc@ General case discussions opensolaris-arc-discuss@ Non-case focused discussions opensolaris-arc-record@ Archival without discussion These three could be combined - they are in the proposal because that was "how we always did it". opensolaris-arc-agenda-request@ (I still need to add a few more workflow support aliases (not this project...) like opensolaris-arc-onepager-submission@ and opensolaris-arc-fasttrack-submission@) -John From Darren.Moffat@Sun.COM Tue Oct 24 06:17:01 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9ODH0ee000605 for ; Tue, 24 Oct 2006 06:17:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9ODGuc21780; Tue, 24 Oct 2006 07:16:56 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7N00K1H6863700@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Oct 2006 06:16:54 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7N00GSQ684DH30@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Oct 2006 06:16:53 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9ODGq4b005548; Tue, 24 Oct 2006 14:16:52 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7N008015PCYI00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Tue, 24 Oct 2006 14:16:52 +0100 (BST) Received: from [83.144.24.119] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7N00FWQ67VXV10@d1-emea-09.sun.com>; Tue, 24 Oct 2006 14:16:48 +0100 (BST) Date: Tue, 24 Oct 2006 14:16:36 +0100 From: Darren J Moffat Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453D13B3.5060409@sun.com> Sender: Darren.Moffat@Sun.COM To: John.Plocher@Sun.COM Cc: Derek Cicero , Stephen Hahn , PSARC-EXT@Sun.COM Message-id: <453E1234.7070600@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: <453D13B3.5060409@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1916 John Plocher wrote: > o Create a set of ARC aliases on opensolaris.org (details follow): > > opensolaris-arc@ > opensolaris-arc-discuss@ > opensolaris-arc-record@ > opensolaris-arc-chair@ > opensolaris-arc-agenda-request@ > opensolaris-arc-agenda-interest@ > opensolaris-arc-member-list@ > opensolaris-arc-intern-list@ > opensolaris-arc-licensee-list@ > opensolaris-arc-interest@ Why is this opensolaris-arc ? The opensolaris- is redundant given the @opensolaris.org mail domain IMO. This email structure implies that we no longer wish to distinguish the sub groups of ARC, ie PSARC, LSARC, WSARC, FWARC. Now for OpenSolaris I'd say that most of the time only projects that are reviewed in PSARC and LSARC are really interesting. After all anything reviewed in FWARC should be about hardware or firmware and that is either opensparc or some place else but not OpenSolaris. Similarly even though somethings that WSARC may already be open source (such as Application Server) they aren't really OpenSolaris issues so I don't expect much traffic from WSARC out to OpenSolaris. So with that I mind I think a better name space would be: psarc@opensolaris.org psarc-....@opensolaris.org - if the other thread agrees the sub aliases are actually valuable - I have no strong preference either way on the member/intern/licensee split but the agenda/chair split I think is valuable. Particularly looking forward to the day when the chair of PSARC is not a Sun employee! and we also have: lsarc@opensolaris.org With maybe a need for the equivalent of the current all-arcs and sac-review aliases at some point in the future. For the context of non Sun people on this thread, I have been a WSARC intern, member and one time co-chair. I chaired the now defunct SNARC and "stick my nose into" many PSARC cases as sponsor or contributer. -- Darren J Moffat From richlowe@richlowe.net Tue Oct 24 06:39:16 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9ODdG77001236 for ; Tue, 24 Oct 2006 06:39:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9ODdGj19347; Tue, 24 Oct 2006 06:39:16 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7N00L0T79FOB00@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Oct 2006 06:39:15 -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 <0J7N00GUQ79FD650@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Oct 2006 06:39:15 -0700 (PDT) Received: from relay13.sun.com (relay13.sun.com [217.140.40.54] (may be forged)) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9ODdExx021877; Tue, 24 Oct 2006 07:39:14 -0600 (MDT) Received: from mms11es.sun.com ([160.41.223.14] [160.41.223.14]) by relay13.sun.com with ESMTP; Tue, 24 Oct 2006 13:39:13 +0000 (Z) Received: from relay13.sun.com (relay13.sun.com [217.140.40.54]) by mms11es.sun.com with ESMTP; Tue, 24 Oct 2006 13:39:13 +0000 (Z) Received: from rwcrmhc15.comcast.net ([216.148.227.155] [216.148.227.155]) by relay13.sun.com with ESMTP; Tue, 24 Oct 2006 13:39:13 +0000 (Z) Received: from [192.168.1.2] (c-71-203-214-110.hsd1.tn.comcast.net[71.203.214.110]) by comcast.net (rwcrmhc15) with ESMTP id <20061024133901m15009gfjme>; Tue, 24 Oct 2006 13:39:11 +0000 Date: Tue, 24 Oct 2006 09:39:02 -0400 From: Richard Lowe Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453D13B3.5060409@sun.com> To: John.Plocher@sun.com Cc: Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Message-id: <453E1776.9000308@richlowe.net> 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: <453D13B3.5060409@sun.com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 3349 John Plocher wrote: > [Note that this mail is going out to the extended OpenSolaris ARC > community as well as Derek and Stephen] > > Derek and Stephen, > > As part of the opening up of PSARC, we would like to move the PSARC > aliases out onto OpenSolaris.org. Before we actually make any changes, > we would like to brainstorm the best way to do them. What follows is an > initial starting point for discussion (see PSARC 2006/569 for additional > context): > > In order to have effective external ARC discussions, I think we need the > following: > > o Fix the cross posting and Bcc problems on opensolaris.org. > This is the configuration mess that requires all senders > to be a member of all the aliases they crosspost to. In > addition, fix the "implicit destination" moderation hell > resulting from the sac mail filter Bcc'ing to the > opensolaris aliases. While this applies regardless of what I'm about to say, I feel this would be somewhat limited by ceasing to Cc the related opensolaris project on *all* ARC mail related to them, and merely sending them the initial case mail, with followups set for the related ARC list. Which would also have benefits as far as keeping all the mail on osol-arc. (I thought this had been mentioned in the "How do we change things?" discussion at the end of the the 2006/550 call too, but I could be wrong) > o Create a set of ARC aliases on opensolaris.org (details follow): > > opensolaris-arc@ > opensolaris-arc-discuss@ > opensolaris-arc-record@ > opensolaris-arc-chair@ > opensolaris-arc-agenda-request@ > opensolaris-arc-agenda-interest@ > opensolaris-arc-member-list@ > opensolaris-arc-intern-list@ > opensolaris-arc-licensee-list@ > opensolaris-arc-interest@ > > I generally agree with Darren and Alan here, in that if practical this plethora of aliases should be trimmed down somewhat, and that unless the intent is to call this 'OSARC', the naming of aliases should directly relate to the naming of the entity behind them. > Details: > > opensolaris-arc@ > No - Open subscription > No - Archived > No - Mirrored in jive forum > Content: > psarc-ext@sun.com > Use: > General ARC review discussion alias for > Open ARC Cases. All ARC review related > mail will be sent to this alias, which > forwards the mail on to > > psarc-ext@Sun > > which forwards the mail on to > > [the sac mail filter] > > The sac mail filter does a bunch of validation > work, archiving and filing, and then sends > the mail on (via a Bcc:) to the lists of > interested people: > > opensolaris-arc-member-list@ > opensolaris-arc-intern-list@ > opensolaris-arc-interest@ > as well as > per-case IAM:Interest lists I assume current subscriptions to osol-arc would be migrated to osol-arc-interest, or other more appropriately named alias? I still have concerns that the path mail is taking through this system is far more complex than it needs to be, though given the lack of description of the tools driving it, I could easily be incorrect. "You are in a maze of twisty little aliases, all alike" -- Rich From alan.coopersmith@sun.com Tue Oct 24 08:56:51 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9OFuoXc005788 for ; Tue, 24 Oct 2006 08:56:51 -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 k9OFuZMb018559 for <@sunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Tue, 24 Oct 2006 23:56:49 +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 <0J7N00C0DDMM6A00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 24 Oct 2006 09:56:46 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7N00C34DML4U00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 24 Oct 2006 09:56:45 -0600 (MDT) Received: from [192.168.0.101] (vpn-129-150-23-170.SFBay.Sun.COM [129.150.23.170]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9OFuhje007762; Tue, 24 Oct 2006 08:56:44 -0700 (PDT) Date: Tue, 24 Oct 2006 08:55:39 -0700 From: Alan Coopersmith Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453D44F9.1080503@sun.com> To: John.Plocher@sun.com Cc: Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Message-id: <453E377B.3000403@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: <453D13B3.5060409@sun.com> <453D330C.500@sun.com> <453D44F9.1080503@sun.com> User-Agent: Thunderbird 1.5.0.4 (X11/20060602) Status: RO Content-Length: 964 John Plocher wrote: > It would be much much better if there were a supported structured way to > keep such a set of lists; if it existed, we would simply have the email > system use it in the course of sending email, and the web pages could > automatically include the list on the leaders page. > > I am making this proposal because such a structured mechanism does not > exist and parsing an html page is not a viable option. I would be happy > if the result of this discussion was that the OS.o web app was extended > to provide such a mechanism. So this is a way to force members to receive e-mail in a certain way? Why does the mail system need to distinguish members vs. interns? Why not just have everyone on the same list? Or is the mail list on opensolaris.org going to be the master list of who is in what class of membership? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From John.Plocher@Sun.COM Tue Oct 24 09:45:21 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9OGjLXq007943 for ; Tue, 24 Oct 2006 09:45:21 -0700 (PDT) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9OGjKc25571; Tue, 24 Oct 2006 10:45:20 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7N00I03FVJG400@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Oct 2006 09:45:19 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7N00B4QFVJ8A70@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Oct 2006 09:45:19 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9OGjJFj014401; Tue, 24 Oct 2006 09:45:19 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7N00K01FUYBK00@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Tue, 24 Oct 2006 09:45:19 -0700 (PDT) Received: from [129.146.59.11] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7N00CXNFVJOHHY@d1-sfbay-10.sun.com>; Tue, 24 Oct 2006 09:45:19 -0700 (PDT) Date: Tue, 24 Oct 2006 09:45:13 -0700 From: John Plocher Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453E377B.3000403@sun.com> Sender: John.Plocher@Sun.COM To: Alan Coopersmith Cc: Derek Cicero , Stephen Hahn , PSARC-EXT@Sun.COM Message-id: <453E4319.2090102@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: <453D13B3.5060409@sun.com> <453D330C.500@sun.com> <453D44F9.1080503@sun.com> <453E377B.3000403@sun.com> User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) Status: RO Content-Length: 1932 Alan Coopersmith wrote: > So this is a way to force members to receive e-mail in a certain way? I'm not sure what you are driving at here - AFAICT, there is no difference in mail routing/handling between "all on one big alias" and "a set of smaller aliases that are all referenced by an umbrella one" Even the jive/forum interface (as proposed, don't know yet if it is implementable on OS.O today) maintains the similarity. > Why does the mail system need to distinguish members vs. interns? Why The mail system doesn't, but something does, if only to keep us out of the trap of manually maintaining out of date paper lists of people... The mail system has the benefit of having "list maintenance" tools as well as providing value in exchange for keeping the lists up to date. > not just have everyone on the same list? Or is the mail list on There is a bit of "two birds with one stone" here - from a communication target, members. interns and observers all get the same email stream. Segregating them into roles lets us also manage voting, case assignments, meeting quorums, etc. > opensolaris.org going to be the master list of who is in what class of > membership? > The latter - I'm trying to come up with a system where you subscribe to the mailing list that matches the role you are playing in the community. Or, better, you indicate your role in the community (observer, member, core member...) and the mailing lists are generated automatically from that data. It isn't the mailing list per-se that is interesting here, it is the ability to discern and enumerate people's roles. While we *could* maintain such a list manually inside of Sun, it is not a good long term mechanism. It doesn't scale (someone would have to manually track changes...), it isn't transparent (how does one find out who is on the ARC?), and it gives the impression that the ARC is still a private Sun-Thing. -John From carlsonj@phorcys.east.sun.com Tue Oct 24 10:12:11 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9OHCAQc010953 for ; Tue, 24 Oct 2006 10:12:10 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9OHBL8o008814; Tue, 24 Oct 2006 18:11:51 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7N00E43H42J400@brm-avmta-1.central.sun.com>; Tue, 24 Oct 2006 11:12:02 -0600 (MDT) 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 <0J7N00CV0H414L40@brm-avmta-1.central.sun.com>; Tue, 24 Oct 2006 11:12:01 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9OHEo3m015018; Tue, 24 Oct 2006 13:14:50 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9OHEoNX015015; Tue, 24 Oct 2006 13:14:50 -0400 (EDT) Date: Tue, 24 Oct 2006 13:14:50 -0400 From: James Carlson Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453E4319.2090102@Sun.Com> To: John Plocher Cc: Alan Coopersmith , PSARC-EXT@sun.com, Stephen Hahn , Derek Cicero Message-id: <17726.18954.119707.824844@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: <453D13B3.5060409@sun.com> <453D330C.500@sun.com> <453D44F9.1080503@sun.com> <453E377B.3000403@sun.com> <453E4319.2090102@Sun.Com> Status: RO Content-Length: 1752 John Plocher writes: > > Why does the mail system need to distinguish members vs. interns? Why > The mail system doesn't, but something does, if only to keep us out of > the trap > of manually maintaining out of date paper lists of people... The mail > system > has the benefit of having "list maintenance" tools as well as providing > value > in exchange for keeping the lists up to date. We're not so great at that one, either. A quick script check shows one member on the interest list, 5 interns on the interest list, and 14 licensees there. > > not just have everyone on the same list? Or is the mail list on > > There is a bit of "two birds with one stone" here - from a communication > target, > members. interns and observers all get the same email stream. > Segregating them > into roles lets us also manage voting, case assignments, meeting > quorums, etc. Unless we have some automated mechanism that's tied to these mailing lists that actually implements those rules, or at least plans to put something like that in place, I'm not sure I see the point. > While we *could* maintain such a list manually inside of Sun, it is not > a good > long term mechanism. It doesn't scale (someone would have to manually track > changes...), it isn't transparent (how does one find out who is on the > ARC?), > and it gives the impression that the ARC is still a private Sun-Thing. A list on the community web pages would serve that purpose ... but it sounds like you might have more elaborate plans here. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From derek.cicero@sun.com Tue Oct 24 11:13:27 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9OIDQl2014231 for ; Tue, 24 Oct 2006 11:13:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9OID3qA027936; Tue, 24 Oct 2006 19:13:06 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7N00G0RJY7VN00@brm-avmta-1.central.sun.com>; Tue, 24 Oct 2006 12:13:19 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.224.130]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7N00CSZJY64R80@brm-avmta-1.central.sun.com>; Tue, 24 Oct 2006 12:13:18 -0600 (MDT) Received: from [129.146.229.39] (d-mpk17-229-39.SFBay.Sun.COM [129.146.229.39]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9OIDICO314880; Tue, 24 Oct 2006 11:13:18 -0700 (PDT) Date: Tue, 24 Oct 2006 11:13:11 -0700 From: Derek Cicero Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <17726.18954.119707.824844@gargle.gargle.HOWL> To: James Carlson Cc: John Plocher , Alan Coopersmith , PSARC-EXT@sun.com, Stephen Hahn Message-id: <453E57B7.7020803@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <453D13B3.5060409@sun.com> <453D330C.500@sun.com> <453D44F9.1080503@sun.com> <453E377B.3000403@sun.com> <453E4319.2090102@Sun.Com> <17726.18954.119707.824844@gargle.gargle.HOWL> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) Status: RO Content-Length: 1839 James Carlson wrote: > John Plocher writes: > >>> Why does the mail system need to distinguish members vs. interns? Why >> >> The mail system doesn't, but something does, if only to keep us out of >> the trap >> of manually maintaining out of date paper lists of people... The mail >> system >> has the benefit of having "list maintenance" tools as well as providing >> value >> in exchange for keeping the lists up to date. > > > We're not so great at that one, either. A quick script check shows > one member on the interest list, 5 interns on the interest list, and > 14 licensees there. > >>> not just have everyone on the same list? Or is the mail list on >> >> There is a bit of "two birds with one stone" here - from a communication >> target, >> members. interns and observers all get the same email stream. >> Segregating them >> into roles lets us also manage voting, case assignments, meeting >> quorums, etc. > > > Unless we have some automated mechanism that's tied to these mailing > lists that actually implements those rules, or at least plans to put > something like that in place, I'm not sure I see the point. > >> While we *could* maintain such a list manually inside of Sun, it is not >> a good >> long term mechanism. It doesn't scale (someone would have to manually >> track >> changes...), it isn't transparent (how does one find out who is on the >> ARC?), >> and it gives the impression that the ARC is still a private Sun-Thing. > > > A list on the community web pages would serve that purpose ... but it > sounds like you might have more elaborate plans here. It sounds like there is still some debate as to how this should be implemented. Let me know when we reach consensus and I will create/modify the appropriate lists. Derek -- Derek Cicero Program Manager Solaris Kernel Group, Software Division From Joseph.Kowalski@eng.sun.com Tue Oct 24 19:07:36 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9P27ZUv000251 for ; Tue, 24 Oct 2006 19:07:36 -0700 (PDT) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9P27Uui013603; Wed, 25 Oct 2006 10:07:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7O004015WH2P00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Oct 2006 19:07:29 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.224.130]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7O00CJA5WHZ050@nwk-avmta-1.sfbay.Sun.COM>; Tue, 24 Oct 2006 19:07:29 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9P27M4I437354; Tue, 24 Oct 2006 19:07:27 -0700 (PDT) Date: Tue, 24 Oct 2006 16:07:22 -1000 (HST) From: Joseph Kowalski Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) To: John.Plocher@sun.com, fielding@gbiv.com Cc: derek.cicero@sun.com, stephen.hahn@sun.com, PSARC-EXT@sun.com Reply-to: Joseph Kowalski Message-id: <200610250207.k9P27M4I437354@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: G040Jp2Z2Tz42H+iHWrrng== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2428 Maybe John's collection is too complex, but this proposal is way too simple. In addition to the "discuss" and "announce" groups we **need** the "members and interns only" list as well. Some of the others may be useful. If this seems exclusionary, remember that one of our (existing ARC members) goals is to have non-Sun ARC members within a year. They would also be included on this list. - jek3 > Date: Mon, 23 Oct 2006 13:41:06 -0700 > From: "Roy T. Fielding" > Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) > To: John.Plocher@sun.com > Cc: Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com > MIME-version: 1.0 > Content-transfer-encoding: 7BIT > X-PMX-Version: 5.2.0.264296 > X-PMX-Version: 5.2.0.264296 > X-AntiAbuse: This header was added to track abuse, please include it with any abuse report > X-AntiAbuse: Primary Hostname - scorpio.lunarpages.com > X-AntiAbuse: Original Domain - sun.com > X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] > X-AntiAbuse: Sender Address Domain - gbiv.com > X-Source: > X-Source-Args: > X-Source-Dir: > > On Oct 23, 2006, at 12:10 PM, John Plocher wrote: > > > [Note that this mail is going out to the extended OpenSolaris ARC > > community as well as Derek and Stephen] > > > > Derek and Stephen, > > > > As part of the opening up of PSARC, we would like to move the PSARC > > aliases out onto OpenSolaris.org. Before we actually make any > > changes, we would like to brainstorm the best way to do them. What > > follows is an initial starting point for discussion (see PSARC > > 2006/569 for additional context): > > Hi John, > > There is no need for any of this complexity. If the ARC is going to > be an OpenSolaris Community Group, then it can have one discussion list, > one announce list, and one issue tracking system. There is no need for > the mail system to track who is, or is not, an ARC member/intern and > no need for the discussion to take place across multiple mailing lists. > People can say who they are when they vote, and the person collating > the voting can determine whether or not the vote is binding. > Cases can be requested as issues, resolved in discussion on a single > list (with only a single notice sent to the requesting group), and > the result announced on the announce list plus recorded under the issue. > > ....Roy > From kupfer@athyra.sfbay.sun.com Tue Oct 24 22:02:49 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9P52n1L002502 for ; Tue, 24 Oct 2006 22:02:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9P52mj26610; Tue, 24 Oct 2006 22:02:49 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7O00M05E0OPM00@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Oct 2006 22:02:48 -0700 (PDT) Received: from athyra.sfbay.sun.com ([129.146.228.66]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7O00KGJE0OJNA0@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Oct 2006 22:02:48 -0700 (PDT) Received: from athyra (localhost [127.0.0.1]) by athyra.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9P52muJ027246; Tue, 24 Oct 2006 22:02:48 -0700 (PDT) Date: Tue, 24 Oct 2006 22:02:48 -0700 From: Mike Kupfer Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: Message from John Plocher "of Tue, 24 Oct 2006 09:45:13 PDT." <453E4319.2090102@Sun.Com> Sender: kupfer@athyra.sfbay.sun.com To: John Plocher Cc: Alan Coopersmith , Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Message-id: <27245.1161752568@athyra> X-Mailer: MH-E 7.94; nmh 1.0.4; XEmacs 21.4 (patch 18) Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 439 So I've read through the thread several times. The only way your proposal makes sense to me is if there's an implicit assumption that there will (eventually) be infrastructure on opensolaris.org that can take advantage of having the mailing lists organized by role. Is that the plan? Or do you expect to get value from the role-based lists with the current infrastructure (plus fixes for the cross-posting/bcc/moderation issues)? mike From Alan.Hargreaves@sun.com Wed Oct 25 01:38:38 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9P8cbXT005732 for ; Wed, 25 Oct 2006 01:38:38 -0700 (PDT) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9P8cRuj010383; Wed, 25 Oct 2006 16:38:34 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7O00M01O08Z800@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Oct 2006 01:38:32 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7O00DF4O07T7E0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Oct 2006 01:38:32 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9P8cU0L009145; Wed, 25 Oct 2006 16:38:30 +0800 (SGT) 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 <0J7O00601NV68B00@mail-apac.sun.com> (original mail from Alan.Hargreaves@Sun.COM); Wed, 25 Oct 2006 16:38:30 +0800 (SGT) Received: from [129.158.12.60] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7O0013ONZWI73D@mail-apac.sun.com>; Wed, 25 Oct 2006 16:38:30 +0800 (SGT) Date: Wed, 25 Oct 2006 18:38:01 +1000 From: Alan Hargreaves Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453E1234.7070600@Sun.COM> Sender: Alan.Hargreaves@sun.com To: Darren J Moffat Cc: John.Plocher@sun.com, Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Message-id: <453F2269.30808@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: <453D13B3.5060409@sun.com> <453E1234.7070600@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060926) Status: RO Content-Length: 2422 I have been going to gather my thoughts and write about this, but Darren has put my concerns much more succinctly. the opensolaris prefix is certainly redundant, and using "arc" precludes having the other arcs join in. I think what he suggests is very sensible. alan. Darren J Moffat wrote: > John Plocher wrote: >> o Create a set of ARC aliases on opensolaris.org (details follow): >> >> opensolaris-arc@ >> opensolaris-arc-discuss@ >> opensolaris-arc-record@ >> opensolaris-arc-chair@ >> opensolaris-arc-agenda-request@ >> opensolaris-arc-agenda-interest@ >> opensolaris-arc-member-list@ >> opensolaris-arc-intern-list@ >> opensolaris-arc-licensee-list@ >> opensolaris-arc-interest@ > > Why is this opensolaris-arc ? > > The opensolaris- is redundant given the @opensolaris.org mail domain IMO. > > This email structure implies that we no longer wish to distinguish the > sub groups of ARC, ie PSARC, LSARC, WSARC, FWARC. Now for OpenSolaris > I'd say that most of the time only projects that are reviewed in PSARC > and LSARC are really interesting. After all anything reviewed in FWARC > should be about hardware or firmware and that is either opensparc or > some place else but not OpenSolaris. Similarly even though somethings > that WSARC may already be open source (such as Application Server) they > aren't really OpenSolaris issues so I don't expect much traffic from > WSARC out to OpenSolaris. > > So with that I mind I think a better name space would be: > > psarc@opensolaris.org > psarc-....@opensolaris.org - if the other thread agrees the sub aliases > are actually valuable - I have no strong preference either way on the > member/intern/licensee split but the agenda/chair split I think is > valuable. Particularly looking forward to the day when the chair of > PSARC is not a Sun employee! > > and we also have: > > lsarc@opensolaris.org > > With maybe a need for the equivalent of the current all-arcs and > sac-review aliases at some point in the future. > > > For the context of non Sun people on this thread, I have been a WSARC > intern, member and one time co-chair. I chaired the now defunct SNARC > and "stick my nose into" many PSARC cases as sponsor or contributer. > -- Alan Hargreaves - http://blogs.sun.com/tpenta Staff Engineer (Kernel/VOSJEC/Performance) Systems Technical Support Centre Sun Microsystems From carlsonj@phorcys.east.sun.com Wed Oct 25 04:56:03 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PBu3B0008404 for ; Wed, 25 Oct 2006 04:56:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9PBtxj09082; Wed, 25 Oct 2006 04:55:59 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7O00A05X5BRE00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Oct 2006 04:55:59 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7O002N7X5A3S50@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Oct 2006 04:55:58 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9PBwkZc018433; Wed, 25 Oct 2006 07:58:46 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9PBwkWc018430; Wed, 25 Oct 2006 07:58:46 -0400 (EDT) Date: Wed, 25 Oct 2006 07:58:46 -0400 From: James Carlson Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <200610250207.k9P27M4I437354@jurassic.eng.sun.com> To: Joseph Kowalski Cc: John.Plocher@sun.com, fielding@gbiv.com, PSARC-EXT@sun.com, stephen.hahn@sun.com Message-id: <17727.20854.445584.208888@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: <200610250207.k9P27M4I437354@jurassic.eng.sun.com> Status: RO Content-Length: 1024 Joseph Kowalski writes: > Maybe John's collection is too complex, but this proposal is way too simple. > In addition to the "discuss" and "announce" groups we **need** the "members > and interns only" list as well. Some of the others may be useful. We certainly need the lists ... what's not clear to some commenting on this thread is which ones need to be actual, separate mailing lists on opensolaris.org. > If this seems exclusionary, remember that one of our (existing ARC members) > goals is to have non-Sun ARC members within a year. They would also be > included on this list. Sure; I don't think that was the concern. Maybe the problem is with the dividing line between documented interfaces (the lists that will be used ordinarily) and with those that are mere implementation details. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From richlowe@richlowe.net Wed Oct 25 05:35:29 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PCZSMJ008716 for ; Wed, 25 Oct 2006 05:35:29 -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 k9PCZD6K005813; Wed, 25 Oct 2006 20:35:21 +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 <0J7O00L1QYYTCG00@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 06:35:17 -0600 (MDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7O00I24YYSQ650@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 06:35:17 -0600 (MDT) Received: from relay11.sun.com (relay11.sun.com [217.140.40.14] (may be forged)) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9PCZGJ9015742; Wed, 25 Oct 2006 05:35:16 -0700 (PDT) Received: from mms13es.sun.com ([160.41.223.54] [160.41.223.54]) by relay11.sun.com with ESMTP; Wed, 25 Oct 2006 12:35:15 +0000 (Z) Received: from relay12.sun.com (relay12.sun.com [217.140.40.34]) by mms13es.sun.com with ESMTP; Wed, 25 Oct 2006 12:35:14 +0000 (Z) Received: from rwcrmhc11.comcast.net ([216.148.227.151] [216.148.227.151]) by relay12.sun.com with ESMTP; Wed, 25 Oct 2006 12:30:27 +0000 (Z) Received: from [192.168.1.2] (c-71-203-214-110.hsd1.tn.comcast.net[71.203.214.110]) by comcast.net (rwcrmhc11) with ESMTP id <20061025122926m1100ruou5e>; Wed, 25 Oct 2006 12:29:26 +0000 Date: Wed, 25 Oct 2006 08:29:24 -0400 From: Richard Lowe Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <17727.20854.445584.208888@gargle.gargle.HOWL> To: James Carlson Cc: Joseph Kowalski , John.Plocher@sun.com, stephen.hahn@sun.com, PSARC-EXT@sun.com Message-id: <453F58A4.7040701@richlowe.net> 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: <200610250207.k9P27M4I437354@jurassic.eng.sun.com> <17727.20854.445584.208888@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 852 James Carlson wrote: > Joseph Kowalski writes: >> Maybe John's collection is too complex, but this proposal is way too simple. >> In addition to the "discuss" and "announce" groups we **need** the "members >> and interns only" list as well. Some of the others may be useful. > > We certainly need the lists ... what's not clear to some commenting on > this thread is which ones need to be actual, separate mailing lists on > opensolaris.org. > Part of this is that I don't know of any explanation as to what these lists would exist for, the descriptions in this thread are rather terse, and identical for many of the lists. I've been piecing it together from the arc community and prior conversation, but I'm still not certain I have utility as an alias v. utility as a poor-man's directory service fully separated and understood. -- Rich From John.Plocher@sun.com Wed Oct 25 09:38:45 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PGch8s012555 for ; Wed, 25 Oct 2006 09:38:44 -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 k9PGcceP014742; Thu, 26 Oct 2006 00:38:41 +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 <0J7P00801A8D4200@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 10:38:37 -0600 (MDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7P0035ZA8CAVB0@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 10:38:37 -0600 (MDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9PGcaiG017859; Wed, 25 Oct 2006 09:38:36 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7P00F01A7VI200@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Wed, 25 Oct 2006 09:38:36 -0700 (PDT) Received: from [129.146.59.11] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7P00D7VA8CCB43@d1-sfbay-10.sun.com>; Wed, 25 Oct 2006 09:38:36 -0700 (PDT) Date: Wed, 25 Oct 2006 09:38:29 -0700 From: John Plocher Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453F2269.30808@Sun.COM> Sender: John.Plocher@sun.com To: Alan Hargreaves Cc: Darren J Moffat , Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Message-id: <453F9305.1000407@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: <453D13B3.5060409@sun.com> <453E1234.7070600@Sun.COM> <453F2269.30808@Sun.COM> User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) Status: RO Content-Length: 1860 > the opensolaris prefix is certainly redundant +1 > This email structure implies that we no longer wish to distinguish the sub groups of ARC, > ie PSARC, LSARC, WSARC, FWARC. Within the openSOLARIS community, I expect that to be more-or-less true. Except for some of the desktop stuff, the communities that LSARC focuses on are only marginally related to ON - in many cases the only connection is that most of them run on Solaris. WSARC has ties that bind them to the Java world - J2SE, J2EE/Honeydew, the JCP process, Java.Net, etc - I would not expect those communities to pick up shop and migrate over to opensolaris.org. If you ask yourself why we have multiple ARCS, you will find that it has more to do with alignment with communities than it does with anything else. If there is a lot of work being done in , it only makes sense for the experts in to get together and manage the architectural evolution of . Even though we are biased against "product focused" ARCS (an oxymoron considering the systems focus of the ARC process) as well as "project focused" rubber-stamp ARCs, the synergy between the intent of the ARC and community self-governance makes this a good model. This implies (to me, at least) that this effort is not aimed at inventing a generic "openARC.org". Nor am I blindly advocating that "Sun's existing ARCs" are the answer for all of Sun's external/open-source efforts. Instead, I am promoting a locally grown architecture focused sub-community that meets the needs of the larger OpenSolaris effort. I am happy to work on other projects that will meet the needs of the other communities that might be served by OpenLSARC and/or OpenWSARC, but that (IMHO) is not this effort, even though those future efforts will certainly be based on what we learn and do here. -John From alan.coopersmith@sun.com Wed Oct 25 09:46:33 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PGkVCk012655 for ; Wed, 25 Oct 2006 09:46:32 -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 k9PGk2tv019403 for <@sunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Thu, 26 Oct 2006 00:46:31 +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 <0J7P00815ALFFT00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 25 Oct 2006 10:46:27 -0600 (MDT) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7P0038BALCB4B0@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 25 Oct 2006 10:46:24 -0600 (MDT) Received: from [192.168.0.101] (vpn-129-150-23-170.SFBay.Sun.COM [129.150.23.170]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9PGkIvd001443; Wed, 25 Oct 2006 09:46:19 -0700 (PDT) Date: Wed, 25 Oct 2006 09:45:14 -0700 From: Alan Coopersmith Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453F9305.1000407@Sun.Com> To: John Plocher Cc: Alan Hargreaves , Darren J Moffat , Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Message-id: <453F949A.2010408@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: <453D13B3.5060409@sun.com> <453E1234.7070600@Sun.COM> <453F2269.30808@Sun.COM> <453F9305.1000407@Sun.Com> User-Agent: Thunderbird 1.5.0.4 (X11/20060602) Status: RO Content-Length: 514 John Plocher wrote: > > This email structure implies that we no longer wish to distinguish > the sub groups of ARC, > > ie PSARC, LSARC, WSARC, FWARC. > > Within the openSOLARIS community, I expect that to be more-or-less > true. Except for > some of the desktop stuff, the communities that LSARC focuses on are > only marginally > related to ON But OpenSolaris is not just...oh I give up. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From richlowe@richlowe.net Wed Oct 25 09:50:05 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PGo4m0012682 for ; Wed, 25 Oct 2006 09:50:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9PGnw620430; Wed, 25 Oct 2006 09:49:59 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7P00803ARAJO00@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 10:49:58 -0600 (MDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7P003N3ARAATB0@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 10:49:58 -0600 (MDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9PGnvXr025039; Wed, 25 Oct 2006 09:49:57 -0700 (PDT) Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay23.sun.com with ESMTP; Wed, 25 Oct 2006 16:49:57 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms24es.sun.com with ESMTP; Wed, 25 Oct 2006 16:49:52 +0000 (Z) Received: from rwcrmhc13.comcast.net ([216.148.227.153] [216.148.227.153]) by relay22.sun.com with ESMTP; Wed, 25 Oct 2006 16:48:25 +0000 (Z) Received: from [192.168.1.2] (c-71-203-214-110.hsd1.tn.comcast.net[71.203.214.110]) by comcast.net (rwcrmhc13) with ESMTP id <20061025164803m1300m2rlse>; Wed, 25 Oct 2006 16:48:14 +0000 Date: Wed, 25 Oct 2006 12:48:02 -0400 From: Richard Lowe Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453F9305.1000407@Sun.Com> To: John Plocher Cc: Alan Hargreaves , Stephen Hahn , PSARC-EXT@sun.com Message-id: <453F9542.1080904@richlowe.net> 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: <453D13B3.5060409@sun.com> <453E1234.7070600@Sun.COM> <453F2269.30808@Sun.COM> <453F9305.1000407@Sun.Com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 2412 John Plocher wrote: > > the opensolaris prefix is certainly redundant > > +1 > > > This email structure implies that we no longer wish to distinguish > the sub groups of ARC, > > ie PSARC, LSARC, WSARC, FWARC. > > Within the openSOLARIS community, I expect that to be more-or-less > true. Except for > some of the desktop stuff, the communities that LSARC focuses on are > only marginally > related to ON - in many cases the only connection is that most of them > run on Solaris. WSARC has ties that bind them to the Java world - J2SE, > J2EE/Honeydew, the JCP > process, Java.Net, etc - I would not expect those communities to pick up > shop and migrate > over to opensolaris.org. OpenSolaris is not only ON. There are existing consolidations, one of them even with it's primary development environment on opensolaris.org, whose cases tend to go through LSARC (JDS). While I think I can agree that the other ARCs don't belong here, the reasoning that says "Everything we need is in PSARC" is not accurate, unless the intent is for JDS and X to start using PSARC exclusively. > If you ask yourself why we have multiple ARCS, you will find that it has > more to do with > alignment with communities than it does with anything else. If there is > a lot of work being > done in , it only makes sense for the experts in to > get together and > manage the architectural evolution of . Even though we are biased > against "product > focused" ARCS (an oxymoron considering the systems focus of the ARC > process) as well > as "project focused" rubber-stamp ARCs, the synergy between the intent > of the ARC and > community self-governance makes this a good model. > > This implies (to me, at least) that this effort is not aimed at > inventing a generic "openARC.org". Nor am I blindly advocating that > "Sun's existing ARCs" are the answer for all of Sun's > external/open-source efforts. Instead, I am promoting a locally grown > architecture focused > sub-community that meets the needs of the larger OpenSolaris effort. > I'm not sure if I'm understanding this correctly. Does this suggest that this effort would form an 'OSARC' (for want of a better acronym), that anything opensolaris-related would go through? At that point, you're going to have to define "opensolaris related", and I suspect that may be difficult to do accurately. -- Rich From carlsonj@phorcys.east.sun.com Wed Oct 25 09:54:15 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PGsExo013101 for ; Wed, 25 Oct 2006 09:54:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9PGrnjF027675; Wed, 25 Oct 2006 17:53:52 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7P00A0HAY6LR00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Oct 2006 09:54:06 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7P002A6AY40C80@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Oct 2006 09:54:04 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9PGurte020026; Wed, 25 Oct 2006 12:56:53 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9PGurDm020023; Wed, 25 Oct 2006 12:56:53 -0400 (EDT) Date: Wed, 25 Oct 2006 12:56:53 -0400 From: James Carlson Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453F9305.1000407@Sun.Com> To: John Plocher Cc: Alan Hargreaves , Stephen Hahn , PSARC-EXT@sun.com Message-id: <17727.38741.128831.18933@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: <453D13B3.5060409@sun.com> <453E1234.7070600@Sun.COM> <453F2269.30808@Sun.COM> <453F9305.1000407@Sun.Com> Status: RO Content-Length: 1172 John Plocher writes: > > This email structure implies that we no longer wish to distinguish > the sub groups of ARC, > > ie PSARC, LSARC, WSARC, FWARC. > > Within the openSOLARIS community, I expect that to be more-or-less > true. Except for > some of the desktop stuff, the communities that LSARC focuses on are > only marginally > related to ON - in many cases the only connection is that most of them > run on Solaris. Open Solaris, though, is not just ON. Many other consolidations are there now, and more will be there in the future. For the same reason we have a separate PSARC and LSARC (at least), we likely will need similar structures on openSOLARIS.org. But you raise an interesting point. PSARC is intentionally not focussed on just one product, and having an ARC that does focus on a single product (even if that product is "Open Solaris") sounds like a bit of a syntax error. Are we giving up something important here? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Joseph.Kowalski@eng.sun.com Wed Oct 25 14:10:43 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PLAh1K020378 for ; Wed, 25 Oct 2006 14:10:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9PLAb611822; Wed, 25 Oct 2006 14:10:37 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7P00J05MTN1P00@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 15:10:35 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.104.45]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7P00A8JMTN2QD0@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 15:10:35 -0600 (MDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9PLATb0772177; Wed, 25 Oct 2006 14:10:34 -0700 (PDT) Date: Wed, 25 Oct 2006 11:10:26 -1000 (HST) From: Joseph Kowalski Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) To: Alan.Hargreaves@sun.com, John.Plocher@sun.com Cc: Darren.Moffat@sun.com, derek.cicero@sun.com, stephen.hahn@sun.com, PSARC-EXT@sun.com Reply-to: Joseph Kowalski Message-id: <200610252110.k9PLATb0772177@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: 8Rjpz25m1Uc1GRMLLyDwEA== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1252 > From: John Plocher ... > > This email structure implies that we no longer wish to distinguish > the sub groups of ARC, > > ie PSARC, LSARC, WSARC, FWARC. > > Within the openSOLARIS community, I expect that to be more-or-less > true. Except for > some of the desktop stuff, the communities that LSARC focuses on are > only marginally > related to ON - in many cases the only connection is that most of them > run on Solaris. > WSARC has ties that bind them to the Java world - J2SE, J2EE/Honeydew, > the JCP > process, Java.Net, etc - I would not expect those communities to pick up > shop and migrate > over to opensolaris.org. I generally agree, but I'm not convinced that a 98% solution is enough. Walk me through how the following senario would be handled... We have the JDS Gnome and Firefox source out on OpenSolaris. For the most part, serious development of these subsystems are done at gnome.org and mozilla.org. However, it is quite possible that a OpenSolaris contributor would propose a change requiring ARC review to the Solaris specific parts of these (say an RBAC interface issue with Gnome). What happens when this change which would normally be reviewed by LSARC is submitted? - jek3 From John.Plocher@sun.com Wed Oct 25 15:55:04 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PMt3dd024233 for ; Wed, 25 Oct 2006 15:55:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9PMseOF001277; Wed, 25 Oct 2006 23:54:45 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7P00E01RNODA00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Oct 2006 15:55:00 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7P00D6QRNNZ400@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Oct 2006 15:54:59 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9PMsxVk012010; Wed, 25 Oct 2006 15:54:59 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7P00701RKLX800@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Wed, 25 Oct 2006 15:54:59 -0700 (PDT) Received: from [129.146.59.11] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7P0052HRNM7GFL@d1-sfbay-09.sun.com>; Wed, 25 Oct 2006 15:54:58 -0700 (PDT) Date: Wed, 25 Oct 2006 15:54:51 -0700 From: John Plocher Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453F949A.2010408@sun.com> Sender: John.Plocher@sun.com To: Alan Coopersmith Cc: Alan Hargreaves , Darren J Moffat , Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Message-id: <453FEB3B.1000205@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-15 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <453D13B3.5060409@sun.com> <453E1234.7070600@Sun.COM> <453F2269.30808@Sun.COM> <453F9305.1000407@Sun.Com> <453F949A.2010408@sun.com> User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) Status: RO Content-Length: 4450 [Remember, this all is simply my opinion; if I am off base, oblivious or otherwise being more thick headed than usual, feel free to whap me up 'side the head and tell me to get with the program....] Alan Coopersmith wrote: > But OpenSolaris is not just...oh I give up. Sorry about hitting your "OpenSolaris is more than just ON" hot button... The OpenSolaris.org community was created to be a home for Solaris. Solaris is just one of many things that Sun is open sourcing, and it is distinct from OpenFirmware, OpenSPARC, OpenJava and the others. I don't think anyone is suggesting that OpenSolaris.Org become a single uber-community for all of these disparate efforts. I'm certainly not! On the other hand, OpenSolaris is becoming home for more consolidations than just ON - JDS, SFW and the admin /install all quickly come to mind. The question on the table is how to best manage the architectural invention and evolution that is happening in all parts of our extended set of communities. Within Sun we have self-organized into several ARCs for various specialization, organizational and load balancing reasons; those reasons may or may not be valid "out here". So far, we have been experimenting with PSARC, and have determined that it needs to split into two parts - the traditional Sun-internal closed PSARC and the new OpenSolaris ARC being discussed here. The next question that comes up is Do we wish to have more than one ARC community in OpenSolaris? If not, we should call it something like "the OpenSolaris ARC" or OSARC or just plain ARC, and staff it with ALL the core community members. This is my preferred direction, but it presumes that OpenSolaris won't become another SourceForge collection of unrelated projects. If we do want multiple ARCs, we need to figure out how we will differentiate between them. Rhetorically, would it make sense correlate specific consolidations or Communities to specific ARCs? Does it make sense to have a "Zones ARC" and/or a "JDS ARC"? If we did this, what kind of relationship would/should there be between the "JDS ARC" and the Gnome Community development processes? Creating an OpenSolaris presence for the other "Sun ARCS" has its own problems. I get confused when I try to follow the implications to their logical conclusions: If we were to create a WSARC@opensolaris.org, wouldn't we also have to create another WSARC sub-community for J2ee@java.com (where a major WSARC constituency lives), another @Java.Net, another @JCP.org, ... ? How would a WSARC member deal with this complexity? If LSARC were to become the JDS ARC, what would/should happen to the rest of the traditional LSARC caseload: Explorer, SunVTS, Woodstock, the open source database stuff, NetBeans, the compilers, SunMC, Cacao, etc? Mostly because I don't have good answers for these questions, I'd rather not divide the OpenSolaris architecture effort into factions at the beginning - there isn't the volume of participation (either at the case or membership levels) to warrant it yet. And if the need does arise, we can address it then. Rich Lowe wrote: > I'm not sure if I'm understanding this correctly. Does this suggest that this effort > would form an 'OSARC' (for want of a better acronym), that anything > opensolaris-related would go through? At that point, you're going to have > to define "opensolaris related" I think/hope so. A metric I'd suggest is that if it is hosted on OpenSolaris.Org, it goes thru the OpenSolaris ARC. It doesn't matter much if the project is aimed at ON, SFW or JDS; if it affects the community, it needs to be reviewed by the community. This probably implies that the current membership of PSARC, LSARC and WSARC needs some restructuring to deal with "OSARC". Joe Kowalski wrote: > What happens when this change which would normally be > reviewed by LSARC is submitted? Answer #1: If we have only one OpenSolaris ARC: The project goes to "OSARC" for review. Hopefully the LSARC members who are also JDS community core members are participating in the operation of OSARC and take a leadership role in the review. Answer #2: If we have many OpenSolaris ARCs: The case is triaged in some as-yet undefined way to send it to the appropriate ARC for JDS things, which is staffed by the aforementioned core community members who are also LSARC members. -John From Glynn.Foster@Sun.COM Wed Oct 25 16:05:11 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PN5BtG024570 for ; Wed, 25 Oct 2006 16:05:11 -0700 (PDT) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9PN5B623335; Wed, 25 Oct 2006 16:05:11 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7P00G01S4MES00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Oct 2006 16:05:10 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7P00305S4LJEB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 25 Oct 2006 16:05:10 -0700 (PDT) Received: from d1-emea-10.sun.com ([192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9PN594s021594; Thu, 26 Oct 2006 00:05:09 +0100 (BST) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7P00901RYMPK00@d1-emea-10.sun.com> (original mail from Glynn.Foster@Sun.COM); Thu, 26 Oct 2006 00:05:09 +0100 (BST) Received: from [129.150.153.11] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7P00FW8S49SZFH@d1-emea-10.sun.com>; Thu, 26 Oct 2006 00:05:09 +0100 (BST) Date: Thu, 26 Oct 2006 12:04:56 +1300 From: Glynn Foster Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453FEB3B.1000205@Sun.Com> Sender: Glynn.Foster@Sun.COM To: John Plocher Cc: Alan Coopersmith , Alan Hargreaves , Darren J Moffat , Derek Cicero , Stephen Hahn , PSARC-EXT@Sun.COM Message-id: <453FED98.2060607@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <453D13B3.5060409@sun.com> <453E1234.7070600@Sun.COM> <453F2269.30808@Sun.COM> <453F9305.1000407@Sun.Com> <453F949A.2010408@sun.com> <453FEB3B.1000205@Sun.Com> User-Agent: Thunderbird 2.0a1 (X11/20060925) Status: RO Content-Length: 814 John Plocher wrote: > Joe Kowalski wrote: > > What happens when this change which would normally be > > reviewed by LSARC is submitted? > > Answer #1: If we have only one OpenSolaris ARC: > The project goes to "OSARC" for review. Hopefully the LSARC members > who are also JDS community core members are participating in the > operation > of OSARC and take a leadership role in the review. I'd like to see this - given that 90% of our development [1] is now on opensolaris.org, I'd very much like any arc review process to be open for people to view too. If that means moving from LSARC to some other entity, I'm all for it. Obviously though, I'd be keen on having existing LSARC members stepping up to that plate too. Glynn [1] We have still a few internal lists which we need to shake out From Joseph.Kowalski@eng.sun.com Wed Oct 25 16:18:35 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PNIZPM024712 for ; Wed, 25 Oct 2006 16:18:35 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9PNISj20623; Wed, 25 Oct 2006 16:18:28 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7P00101SQSIP00@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 17:18:28 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.104.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7P000H1SQR2J20@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 17:18:28 -0600 (MDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9PNIL31850117; Wed, 25 Oct 2006 16:18:26 -0700 (PDT) Date: Wed, 25 Oct 2006 13:18:19 -1000 (HST) From: Joseph Kowalski Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) To: John.Plocher@sun.com, Glynn.Foster@sun.com Cc: Alan.Coopersmith@sun.com, Alan.Hargreaves@sun.com, Darren.Moffat@sun.com, derek.cicero@sun.com, stephen.hahn@sun.com, PSARC-EXT@sun.com Reply-to: Joseph Kowalski Message-id: <200610252318.k9PNIL31850117@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: IguQFOdwVUvt8bB5ut8qcQ== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1139 > From: Glynn Foster ... > John Plocher wrote: > > Joe Kowalski wrote: > > > What happens when this change which would normally be > > > reviewed by LSARC is submitted? > > > > Answer #1: If we have only one OpenSolaris ARC: > > The project goes to "OSARC" for review. Hopefully the LSARC members > > who are also JDS community core members are participating in the > > operation > > of OSARC and take a leadership role in the review. > > I'd like to see this - given that 90% of our development [1] is now on > opensolaris.org, I'd very much like any arc review process to be open for people > to view too. If that means moving from LSARC to some other entity, I'm all for > it. Obviously though, I'd be keen on having existing LSARC members stepping up > to that plate too. > > > Glynn > > [1] We have still a few internal lists which we need to shake out Hummm,... What about we keep the existing *arc aliases and based on the case number we forward the mail from the external alias (opensolaris_arc_discussion_and_flames_only or whatever) to the appropriate internal alias? - jek3 From richlowe@richlowe.net Wed Oct 25 16:38:38 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PNcc6D025337 for ; Wed, 25 Oct 2006 16:38:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9PNcb602713; Wed, 25 Oct 2006 16:38:37 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7P0020DTOBI700@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 17:38:35 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7P000BLTOA2K50@brm-avmta-1.central.sun.com>; Wed, 25 Oct 2006 17:38:34 -0600 (MDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.14] (may be forged)) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9PNcXm8017817; Wed, 25 Oct 2006 17:38:34 -0600 (MDT) Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay21.sun.com with ESMTP; Wed, 25 Oct 2006 23:38:33 +0000 (Z) Received: from relay22.sun.com (relay22.sun.com [192.12.251.34]) by mms24es.sun.com with ESMTP; Wed, 25 Oct 2006 23:32:48 +0000 (Z) Received: from rwcrmhc15.comcast.net ([204.127.192.85] [204.127.192.85]) by relay22.sun.com with ESMTP; Wed, 25 Oct 2006 23:30:33 +0000 (Z) Received: from [192.168.1.2] (c-71-203-214-110.hsd1.tn.comcast.net[71.203.214.110]) by comcast.net (rwcrmhc15) with ESMTP id <20061025233018m1500bppbte>; Wed, 25 Oct 2006 23:30:19 +0000 Date: Wed, 25 Oct 2006 19:30:16 -0400 From: Richard Lowe Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453FEB3B.1000205@Sun.Com> To: John Plocher Cc: Alan Coopersmith , Stephen Hahn , PSARC-EXT@sun.com Message-id: <453FF388.4020701@richlowe.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-15; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <453D13B3.5060409@sun.com> <453E1234.7070600@Sun.COM> <453F2269.30808@Sun.COM> <453F9305.1000407@Sun.Com> <453F949A.2010408@sun.com> <453FEB3B.1000205@Sun.Com> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 4610 John Plocher wrote: > [Remember, this all is simply my opinion; if I am off base, oblivious or > otherwise being more thick headed than usual, feel free to whap me up > 'side the head and tell me to get with the program....] > > Alan Coopersmith wrote: > > But OpenSolaris is not just...oh I give up. > > Sorry about hitting your "OpenSolaris is more than just ON" hot button... > > The OpenSolaris.org community was created to be a home for Solaris. > Solaris is just one of many things that Sun is open sourcing, and it is > distinct from OpenFirmware, OpenSPARC, OpenJava and the others. I > don't think anyone is suggesting that > OpenSolaris.Org become a single uber-community for all of these > disparate efforts. I'm certainly not! No, certainly not. > On the other hand, OpenSolaris is becoming home for more consolidations > than just ON - JDS, SFW and the admin /install all quickly come to > mind. The question on the table is how to best manage the architectural > invention and evolution that is happening in all parts of our extended > set of communities. Yes. > Within Sun we have self-organized into several ARCs for various > specialization, organizational and load balancing reasons; those > reasons may or may not be valid "out here". > So far, we have been experimenting with PSARC, and have determined that > it needs to split into two parts - the traditional Sun-internal closed > PSARC and the new OpenSolaris ARC being discussed here. With, one would hope, use of the internal side being exceptionally rare in practice. > The next question that comes up is > > Do we wish to have more than one ARC community in OpenSolaris? > > If not, we should call it something like "the OpenSolaris ARC" or OSARC > or just plain ARC, and staff it with ALL the core community members. > This is my preferred direction, but it presumes that OpenSolaris won't > become another SourceForge collection of unrelated projects. I have a couple of concerns here. Specialization still applies, I think. Someone with appropriate experience and knowledge to be a member of a PSARC-like entity may not be appropriate in an LSARC-like entity, for instance (talking membership here, not merely taking part in discussion...). How would this interact with historical differences between the bodies? (think the different ways Evolving is now spelled, depending on your venue, and any other such things that I don't know about) > If we do want multiple ARCs, we need to figure out how we will > differentiate between them. Rhetorically, would it make sense correlate > specific consolidations or Communities to specific ARCs? Does it make > sense to have a "Zones ARC" and/or a "JDS ARC"? If we did this, what > kind of relationship would/should there be between the "JDS ARC" and the > Gnome Community development processes? Certainly not to the degree of "Zones ARC...". I could perhaps understand Desktop v. OS v. ..., however. (for all practical purposes, that would be the PSARC v. LSARC split, in so far as it meets opensolaris) > Creating an OpenSolaris presence for the other "Sun ARCS" has its own > problems. I get confused when I try to follow the implications to their > logical conclusions: If we were to create a WSARC@opensolaris.org, > wouldn't we also have to create another WSARC sub-community for > J2ee@java.com (where a major WSARC constituency lives), another > @Java.Net, another @JCP.org, ... ? How would a WSARC member deal > with this complexity? If LSARC were to become the JDS ARC, what > would/should happen to the rest of the traditional LSARC caseload: > Explorer, SunVTS, Woodstock, the open source database stuff, NetBeans, > the compilers, SunMC, Cacao, etc? If LSARC were purely moved in part outside, I assume these would be closed cases at LSARC, just as a JDS case would be an open case at LSARC. > Mostly because I don't have good answers for these questions, I'd rather > not divide the OpenSolaris architecture effort into factions at the > beginning - there isn't the volume of participation (either at the case > or membership levels) to warrant it yet. And if the need does arise, we > can address it then. My hope is that uses of the open infrastructure immediately grows to equal that handled by PSARC, plus the sub-set of cases handled by LSARC that are opensolaris related. The question in my mind, in part, is "How likely is it that splitting things up will again be desirable, and if that happens how painful would it be?" I'm not sure I have answers, however. -- Rich From Glynn.Foster@Sun.COM Wed Oct 25 16:39:06 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9PNd4cq025359 for ; Wed, 25 Oct 2006 16:39:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9PNd1Os001259; Thu, 26 Oct 2006 07:39:01 +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 <0J7P00I01TP03K00@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Oct 2006 16:39:00 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7P00DZCTOZZ210@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Oct 2006 16:39:00 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119] (may be forged)) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9PNcwP1029806; Thu, 26 Oct 2006 00:38:58 +0100 (BST) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7P00701TMYUR00@d1-emea-09.sun.com> (original mail from Glynn.Foster@Sun.COM); Thu, 26 Oct 2006 00:38:58 +0100 (BST) Received: from [129.150.153.11] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7P00JMQTOQN65G@d1-emea-09.sun.com>; Thu, 26 Oct 2006 00:38:58 +0100 (BST) Date: Thu, 26 Oct 2006 12:38:48 +1300 From: Glynn Foster Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <200610252318.k9PNIL31850117@jurassic.eng.sun.com> Sender: Glynn.Foster@Sun.COM To: Joseph Kowalski Cc: John.Plocher@Sun.COM, Alan.Coopersmith@Sun.COM, Alan.Hargreaves@Sun.COM, Darren.Moffat@Sun.COM, Derek.Cicero@Sun.COM, stephen.hahn@Sun.COM, PSARC-EXT@Sun.COM Message-id: <453FF588.8060409@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200610252318.k9PNIL31850117@jurassic.eng.sun.com> User-Agent: Thunderbird 2.0a1 (X11/20060925) Status: RO Content-Length: 1322 Joseph Kowalski wrote: >> From: Glynn Foster >> I'd like to see this - given that 90% of our development [1] is now on >> opensolaris.org, I'd very much like any arc review process to be open for > people >> to view too. If that means moving from LSARC to some other entity, I'm all for >> it. Obviously though, I'd be keen on having existing LSARC members stepping up >> to that plate too. >> >> >> Glynn >> >> [1] We have still a few internal lists which we need to shake out Just trying to encourage the developers to use the open lists, plus also things like CTeams and what not that are probably a little way down the priority order. > What about we keep the existing *arc aliases and based on the > case number we forward the mail from the external alias > (opensolaris_arc_discussion_and_flames_only or whatever) > to the appropriate internal alias? Sounds ugly and slow - would be nicer to encourage people just to use the opensolaris.org lists directly. Doesn't feel like a big step [1] [1] Man, someone *really* needs to encourage some one to fund an OpenSolaris tour of a few engineers around the various Sun offices, tell them what's going on and how they need to change their current development processes and communication if we're going to do this effectively From kupfer@athyra.sfbay.sun.com Wed Oct 25 21:02:53 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9Q42qlg029456 for ; Wed, 25 Oct 2006 21:02:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9Q42Sen028435; Thu, 26 Oct 2006 05:02:29 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7Q00G015WJT400@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Oct 2006 21:02:43 -0700 (PDT) Received: from athyra.sfbay.sun.com ([129.146.228.66]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7Q00DGV5WJYPB0@nwk-avmta-2.sfbay.sun.com>; Wed, 25 Oct 2006 21:02:43 -0700 (PDT) Received: from athyra (localhost [127.0.0.1]) by athyra.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9Q42hUM000394; Wed, 25 Oct 2006 21:02:43 -0700 (PDT) Date: Wed, 25 Oct 2006 21:02:42 -0700 From: Mike Kupfer Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: Message from John Plocher "of Wed, 25 Oct 2006 15:54:51 PDT." <453FEB3B.1000205@Sun.Com> Sender: kupfer@athyra.sfbay.sun.com To: John Plocher Cc: Alan Coopersmith , Alan Hargreaves , Darren J Moffat , Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Message-id: <393.1161835362@athyra> X-Mailer: MH-E 7.94; nmh 1.0.4; XEmacs 21.4 (patch 18) Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 2348 >>>>> "John" == John Plocher writes: John> If LSARC were to become the JDS ARC, what would/should happen to John> the rest of the traditional LSARC caseload: Explorer, SunVTS, John> Woodstock, the open source database stuff, NetBeans, the John> compilers, SunMC, Cacao, etc? Unless things have changed since I sat on LSARC (1997-1999), LSARC's domain is mostly a grab bag of things that weren't a natural fit for some other ARC.[1] Restructuring the current set of ARCs (as you suggest later in your email) makes sense to me. jek3> What happens when this change which would normally be reviewed by jek3> LSARC is submitted? John> Answer #1: If we have only one OpenSolaris ARC: The project goes John> to "OSARC" for review. Hopefully the LSARC members who are also John> JDS community core members are participating in the operation of John> OSARC and take a leadership role in the review. One of the concerns about being on an ARC is the time commitment.[2] In the past, I've suggested that this could be remedied by letting members only pay attention to some subset of the cases that come before the ARC. This idea didn't get much traction. The thinking was that we were better served by having the same set of people review all the cases over a certain period of time. It gives more consistent decisions and better institutional memory than having one set of people review the cases one week, and a somewhat different set of people review the cases the next week. With that in mind, how would things work in a single OpenSolaris ARC? Would members still be expected to participate in all cases? Also, I'm a little concerned about the rationale that if a single committee doesn't work, we can reorganize into multiple committees later. How long would it take to implement such a reorganization? Would we have sufficient warning, or would it end up being a firedrill? The reason I ask is that AFAIK, the historical pattern for PSARC is that case load goes up significantly as various release deadlines approach. So I think we can assume that the case load for the OpenSolaris ARC(s) *will* go up; our planning should take that into account. mike [1] "LSARC reviews everything *else*!" --Dean Stanton (I think) [2] During my tenure, the nominal commitment was 20%, but realistically it was closer to 40-50%. From sacadmin Thu Oct 26 12:43:45 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9QJhjSM019533 for ; Thu, 26 Oct 2006 12:43:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9QJhij15981 for <@sunmail1brm.central.sun.com:wsarc@sun.com>; Thu, 26 Oct 2006 12:43:44 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7R00C0BDGVK500@brm-avmta-1.central.sun.com> for wsarc@sun.com (ORCPT wsarc@sun.com); Thu, 26 Oct 2006 13:43:43 -0600 (MDT) Received: from jurassic.eng.sun.com ([129.146.104.45]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7R006L8DGUW0B0@brm-avmta-1.central.sun.com> for wsarc@sun.com (ORCPT wsarc@sun.com); Thu, 26 Oct 2006 13:43:42 -0600 (MDT) Received: from donald3 (donald3.SFBay.Sun.COM [129.146.226.220]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9QJhgwb302630 for ; Thu, 26 Oct 2006 12:43:42 -0700 (PDT) Date: Thu, 26 Oct 2006 12:43:42 -0700 (PDT) From: Margot Miller Subject: OpenSolaris ARC community email changes (see PSARC 2006/569) To: wsarc@sun.com Reply-to: Margot Miller Message-id: <200610261943.k9QJhgwb302630@jurassic.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: rIGJNu3vRV1EPPbamN5vYg== X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 5549 Just to give you an idea of the issues PSARC is facing with OpenSolaris.org. ------------- Begin Forwarded Message ------------- Date: Mon, 23 Oct 2006 12:10:43 -0700 From: John Plocher Subject: OpenSolaris ARC community email changes (see PSARC 2006/569) To: Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com MIME-version: 1.0 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-PMX-Version: 5.2.0.264296 User-Agent: Mail/News 1.5.0.5 (X11/20060813) [Note that this mail is going out to the extended OpenSolaris ARC community as well as Derek and Stephen] Derek and Stephen, As part of the opening up of PSARC, we would like to move the PSARC aliases out onto OpenSolaris.org. Before we actually make any changes, we would like to brainstorm the best way to do them. What follows is an initial starting point for discussion (see PSARC 2006/569 for additional context): In order to have effective external ARC discussions, I think we need the following: o Fix the cross posting and Bcc problems on opensolaris.org. This is the configuration mess that requires all senders to be a member of all the aliases they crosspost to. In addition, fix the "implicit destination" moderation hell resulting from the sac mail filter Bcc'ing to the opensolaris aliases. o Create a set of ARC aliases on opensolaris.org (details follow): opensolaris-arc@ opensolaris-arc-discuss@ opensolaris-arc-record@ opensolaris-arc-chair@ opensolaris-arc-agenda-request@ opensolaris-arc-agenda-interest@ opensolaris-arc-member-list@ opensolaris-arc-intern-list@ opensolaris-arc-licensee-list@ opensolaris-arc-interest@ o We don't want to archive the base opensolaris-arc alias directly because we want to process the mail on sac first. But we *do* want to make it appear as if the opensolaris-arc alias is the one being archived and mirrored. Based on the sac mail filter's alias usage (see details below), it should be sufficient to archive only the opensolaris-arc-interest alias, as the others (opensolaris-arc-member-list and opensolaris-arc-intern-list) should all be identical. If the mail archiver supports messageID based dup mail filtering, it would also be OK to dump all of them together into one archive to catch any misbehavior. If that archive could be named "opensolaris-arc" without clobbering the above mail filtering, so much the better. -John Details: opensolaris-arc@ No - Open subscription No - Archived No - Mirrored in jive forum Content: psarc-ext@sun.com Use: General ARC review discussion alias for Open ARC Cases. All ARC review related mail will be sent to this alias, which forwards the mail on to psarc-ext@Sun which forwards the mail on to [the sac mail filter] The sac mail filter does a bunch of validation work, archiving and filing, and then sends the mail on (via a Bcc:) to the lists of interested people: opensolaris-arc-member-list@ opensolaris-arc-intern-list@ opensolaris-arc-interest@ as well as per-case IAM:Interest lists opensolaris-arc-member-list@ No - Open subscription No - Archived No - Mirrored in jive forum Content: (by invitation only) the list of PSARC members. Use: Private "membership roster" - not for use as a To: or Cc: for email messages opensolaris-arc-intern-list@ No - Open subscription No - Archived No - Mirrored in jive forum Content: (by invitation only) the list of PSARC interns. Use: Private "membership roster" - not for use as a To: or Cc: for email messages opensolaris-arc-interest@ Yes - Open subscription Yes - Archived as opensolaris-arc Yes - Mirrored in jive forum opensolaris-arc Content: the current subscribers to opensolaris-arc Use: Private "membership roster" - not for use as a To: or Cc: for email messages opensolaris-arc-licensee-list@ No - Open subscription Yes - Archived Yes - Mirrored in jive forum Content: the current list of PSARC licensees. Use: General alias to send messages to everyone who is allowed to sponsor ARC fasttracks. opensolaris-arc-agenda-interest@ Yes - Open subscription Yes - Archived Yes - Mirrored in jive forum Content: Use: Announcements of future ARC agendas (or is this better handled by using opensolaris-arc-announce@ ?) opensolaris-arc-discuss@ No - Open subscription No - Archived (becomes part of opensolaris-arc forum/archive) No - Mirrored in jive forum (see above) Content: psarc-discuss-ext@sac.sfbay.sun.com Use: ARC discussions that don't concern any specific case opensolaris-arc-record@ No - Open subscription No - Archived No - Mirrored in jive forum Content: psarc-record-ext@sac.sfbay.sun.com Use: Causes mail to be archived in case mail archive, but not sent to the people on the ARC aliases. opensolaris-arc-chair@ No - Open subscription Yes - Archived Yes - Mirrored in jive forum Content: psarc-chair@sac.sfbay.sun.com Use: Mail about ARC topics to the ARC Chairperson opensolaris-arc-agenda-request@ No - Open subscription Yes - Archived Yes - Mirrored in jive forum Content: psarc-agends-request-ext@sac.sfbay.sun.com Use: Requests to be scheduled for an ARC review ------------- End Forwarded Message ------------- From Alan.Coopersmith@sun.com Tue Oct 31 18:19:27 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA12JQGV022947 for ; Tue, 31 Oct 2006 18:19:26 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id kA12JIK0001026; Wed, 1 Nov 2006 02:19:23 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 <0J8100I0354ATP00@nwk-avmta-2.sfbay.sun.com>; Tue, 31 Oct 2006 18:19:22 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J81003J5549I080@nwk-avmta-2.sfbay.sun.com>; Tue, 31 Oct 2006 18:19:22 -0800 (PST) Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kA12JKri023151; Tue, 31 Oct 2006 19:19:21 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J8100E014BWM700@mail-amer.sun.com> (original mail from Alan.Coopersmith@Sun.COM); Tue, 31 Oct 2006 19:19:20 -0700 (MST) Received: from [192.9.61.232] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J81004F2547FFS5@mail-amer.sun.com>; Tue, 31 Oct 2006 19:19:20 -0700 (MST) Date: Tue, 31 Oct 2006 18:19:19 -0800 From: Alan Coopersmith Subject: Re: OpenSolaris ARC community email changes (see PSARC 2006/569) In-reply-to: <453E4319.2090102@Sun.Com> Sender: Alan.Coopersmith@sun.com To: John Plocher Cc: Derek Cicero , Stephen Hahn , PSARC-EXT@sun.com Message-id: <45480427.2070704@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <453D13B3.5060409@sun.com> <453D330C.500@sun.com> <453D44F9.1080503@sun.com> <453E377B.3000403@sun.com> <453E4319.2090102@Sun.Com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050512) Status: RO Content-Length: 1290 John Plocher wrote: > Alan Coopersmith wrote: > >> So this is a way to force members to receive e-mail in a certain way? > > > I'm not sure what you are driving at here - AFAICT, there is no difference > in mail routing/handling between "all on one big alias" and "a set of > smaller > aliases that are all referenced by an umbrella one" Even the jive/forum > interface > (as proposed, don't know yet if it is implementable on OS.O today) > maintains > the similarity. I was thinking more in terms of mandating that if I'm a member of OpenSolarisARC, this seems to mandate that I must get the OpenSolarisARC e-mail at alan.coopersmith@sun.com, and not my gmail account or home domain. > It isn't the mailing > list per-se that is interesting here, it is the ability to discern and > enumerate people's roles. Are you assuming non-Sun ARC members will have e-mail addresses like ours which will reveal their identity? To someone trying to find out who the ARC members are, how would knowing that nrubsig@gisburn.org (I know that's not the e-mail address he uses, but he could) is subscribed to arc-members help them figure out that Roland Mainz is an ARC member? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering