George Shepherd wrote: >Agree with the fact that it will never be clear cut James. > >But I do believe that "one" key to making the process seem less >adversarial to the community is to make that division. In my mind >that means the ARCs connecting with the Indiana project directly >and "creating" that division and an attendant lightweight process. > >I believe we cannot reasonably expect to scale the ARCs to >handle all the cases which will result from current plans, >and I believe it inevitable that the stated intent to have >both core and non-core Sun repositories will proceed, (or >the opening of Solaris will stall and the community will >wither). >
I applaud your sentiments. The ARC process has not been designed to scale or deal with the volume from the current plans. It was designed for a different purpose. It seems we need to find a screwdriver to go along with our hammer, so we can turn those screws, rather than bang on them until they go in. John, is this a matter that has been discussed by the ARC chairs? Darren >I think it comes down to whether the ARC is proactive in >going after the community, or something has to break first. > >-George > > > > >*>Date: Thu, 20 Mar 2008 17:06:43 -0400 >*>From: James Carlson <james.d.carlson at SUN.COM> >*>Subject: Re: How to waste everyone's time and give the ARC process a bad rep >*>To: George Shepherd <George.Shepherd at SUN.COM> >*>Cc: PSARC-ext at SUN.COM >*>MIME-version: 1.0 >*>Content-transfer-encoding: 7BIT >*>X-PMX-Version: 5.4.1.325704 >*> >*>[Removed case number from subject line to avoid having this whole >*>off-topic discussion ending up in the 'star' case log. (Wasn't there >*>just a "manners" posting on something like this ... ?)] >*> >*>George Shepherd writes: >*>> One thing which WILL help IMO is to get a clear division between >*>> core cases and cases which are for non-core repositories. >*>> That way at least we can keep the most arcane process for the core >*>> and liberalize the the interactions most of the community will >*>> engage in. >*> >*>Getting to that point means first getting agreement that there is such >*>an important and lasting distinction, and that it has architectural >*>review implications. I don't think everyone necessarily agrees with >*>both parts of that. >*> >*>In particular, what is considered "core" does change over time. It >*>wasn't too long ago that windowing systems and even networking were >*>considered "non-core" parts. Some think development tools are >*>"non-core" as well ... while others are just as convinced that they're >*>core features. (Whyohwhy did they have to break /usr/bin/cc?) >*> >*>I suspect it's hard to predict with any certainty how those notions >*>must evolve over time. Worse still, there are various groups -- let's >*>call 'em distributors for lack of a better term -- who think they have >*>some control over what gets deemed "core" and "not-core" in their >*>realm. (I suspect you're assuming a single IPS repository for all >*>consumers, and I think that might not be true ... at least it's not >*>part of the system architecture today.) >*> >*>The implication of all of that is that we can't necessarily just wave >*>our hands at what we (or contributors) designate as non-core parts and >*>hope for the best. I don't know what the right fix is here, but I'm >*>not sure I agree with you that this simple division is it. >*> >*>-- >*>James Carlson, Solaris Networking <james.d.carlson at sun.com> >*>Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 >*>MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 > > >George Shepherd >http://clem.uk/~georges/ >============================================================================== > Solaris Revenue Product Engineering: | SUN Microsystems > Core team -Internet | Guillemont Park > Email: George.Shepherd at Sun.COM | Camberley GU17 9QG > Disclaimer: Less is more, more or less | United Kingdom >============================================================================== > >
