[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-arc-discuss
Subject:    Re: [arc-discuss] Classifying FOSS (was Re: Integrate Unison into
From:       Torrey McMahon <Torrey.McMahon () Sun ! COM>
Date:       2008-03-31 21:00:07
Message-ID: 47F150D7.1060709 () sun ! com
[Download RAW message or body]

Well...I'd like to think that if the tools were a bit more constrained 
and could provide more info we wouldn't have to deal with as many 
issues. However, the recent cases did have more to do with the process 
itself, imho.

Garrett D'Amore wrote:
> I'm not saying the tools can't be improved.  But you can't possibly 
> blame the tools for the crapfest that has occurred in the recent FOSS 
> cases.  Real humans (such as myself!), with their own own agendas, 
> perceptions, and ideas, are far more to blame.
>
> Once we figure out what problem(s) ARC is supposed to be trying to 
> solve (and possibly limiting the scope of what falls under ARC review, 
> for at least some software), then we can talk about the tools.  Doing 
> it the other way around is putting horse before cart, IMO.
>
>    -- Garrett
>
> Torrey McMahon wrote:
>> I think there are a few issues at play here
>>
>> One, the process is not ideal. I'm sorry but a Sun internal process 
>> that was written years ago before the advent of opensolaris, the huge 
>> amount of change we're introducing all of the time, external vs 
>> internal code, multiple distros spanning different support 
>> timelines.....it doesn't pass the sniff test. Please prove me wrong 
>> but its going to take a bit of effort.
>>
>> Two, even if you remove all of the above and say were were back in 
>> the old days where everything was inside Sun and much more contained 
>> the tools we use to do architecture review are weak. We're stuck in 
>> 1990 with email and text searches for crying out loud. The source 
>> code search engine on opensolaris.org is one example where we could 
>> tie things like interfaces, stability, and actual code together. Or 
>> at least use it if someone changes one of the interfaces it has 
>> referenced. "Oh...you want to change vhci_update_mpapi_data ?" I 
>> wonder who really uses it?
>>
>> http://cvs.opensolaris.org/source/s?refs=vhci_update_mpapi_data
>>
>> ... and yes I know thats probably going a bit down into the details 
>> for architecture review, and closer to code review, but its an 
>> example of where some of the tools should be, imho.
>>
>> Three, I agree with you that we need some separation between "that 
>> which stays stable" and "that which changes quickly". One of my 
>> favorite loaded questions is, "Can someone tell me what Solaris is 
>> these days?" (Outside of the marketing definitions that is...)
>>
>> Garrett D'Amore wrote:
>>> I'm unconvinced that the "tools" are at fault here.
>>>
>>> I think the problem is more related to differing expectations from 
>>> ARC participants.  On one hand there is pressure to ensure that 
>>> (Open)Solaris is an integrated system and that all the pieces play 
>>> well together without major gaps.  (I.e. that each piece contributes 
>>> to some higher level "architectural vision".)  On the other hand, 
>>> there seems to be pressure to integrate as much FOSS as possible, 
>>> with as little change as possible.
>>>
>>> These camps are often diametrically opposed, and several of the 
>>> recent cases I think are the best illustration of that.
>>>
>>> ARC review of the first camp is critical should be required.  ARC 
>>> review of stuff from the second camp may be painful at worst, and is 
>>> probably meaningless at best.
>>>
>>> Hence, I believe that we need a way to separate 
>>> software/repositories so that both camps can be satisfied -- a well 
>>> integrated, architecturally clean core, with a readily accessible 
>>> set of possibly less-well integrated FOSS.  (A cleaner and clearer 
>>> division than we currently have with ON and SFW, for example.)  IMO, 
>>> the division needs to be visible to a system administrator (and 
>>> possibly, but not necessarily, user), as well.
>>>
>>>    -- Garrett
>>>
>>> Torrey McMahon wrote:
>>>> Before anyone asks I pulled off the psarc-ext alias. :)
>>>>
>>>> Outside of the process argument in general I think its clear we 
>>>> need a better set of tools. I made the same argument at arc-chairs 
>>>> years ago before opensoalaris, opensource, the huge set of FOSS was 
>>>> being packaged up, etc.
>>>>
>>>> Joseph Kowalski wrote:
>>>>>
>>>>> Back to the SDF, there weren't supposed to be any documents that 
>>>>> were just for ARC review.  The documents were supposed to just 
>>>>> "fall out" of other requirements.
>>>>>
>>>>> This never quite worked for a number of reasons.  A large one was 
>>>>> that the functional spec was too high level and the design spec 
>>>>> was probably too detailed.
>>>>>
>>>>> Anyway, all that I'm pointing is out the process is *supposed* to 
>>>>> be as light weight as possible and part of that is to accept a 
>>>>> wide range of possible materials.  Maybe this doesn't work 
>>>>> anymore, but I still think the process should be as light of a 
>>>>> weight a process as possible for the submitter.
>>>>>
>>>>> That said, the recent flurries of mail seem to indicate that 
>>>>> "there must be a better way". 
>>>>
>>>>
>>>
>>
>

_______________________________________________
arc-discuss mailing list
arc-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/arc-discuss
[prev in list] [next in list] [prev in thread] [next in thread]