Keith M Wesolowski wrote:
> On Sun, Jan 27, 2008 at 04:08:28PM -0800, Ben Rockwood wrote:
>
>
>> To get at the heart of the issue I think we have to assert the nature of
>> the OpenSolaris community... is it:
>>
>> A) An external representation of Sun development expressly to facilitate
>> contribution up-stream to the internal gates. That is, putting code back
>> into Nevada (or appropriate gate) itself.
>>
>> or,
>>
>> B) An community that provides an eco-system to promote open source
>> development related to any and all representations, internal or
>> external, of the source code that is forms the basis of what is known as
>> "Solaris"; of which up-stream integration is only a small portion thereof.
>>
>
> You've lost me here; I don't know what option (B) means at all.
> What's a "representation"? What's "open source development related to
> [them]" that doesn't involve integration?
>
Representations, meaning a binary distribution in part or whole.
Indiana is a representation, Nexenta is a representation, SFW packages
are representations... any form which makes it into end users hands. I
might make modifications to FMA that aren't accepted for integration and
thus distributed as a patch, thats a representation.
> Are you really asking whether the underlying code (the thing that I've
> taken to calling Consix) is something developed privately by SMI and
> occasionally disgorged for other uses? Your option (A) implies that
> the open development effort is somehow the tip of some giant iceberg,
> the vast majority of which is still somehow private to SMI ("internal
> gates"). In a true open development effort, that's not the case.
>
> In my experience, people who refer to themselves as downstream usually
> aren't doing anything interesting and don't add much value. So I'd
> naturally want to understand what you consider to be "up-stream" of
> whatever it is you think we are (I say "are" rather than "would be"
> because you've used this terminology in both of your suggested
> alternatives). Because if we're defined that way, the first thing
> I'll want to know is how I can get involved with the real work being
> done there instead of whatever nonsense is happening here. Is your
> answer "contact SMI HR"? Fine with me but less than satisfying in
> general.
>
"Downstream development" would be any development done without regard
for integration acceptance. You code and contribute to the community,
if it makes it into Nevada so be it, if not, so what.
>> I think we're banging our heads against the wall because we want to make
>> upstream integration easier... and I think the reality is that it never
>> will be. Thus, the answer is, imho, to facilitate and encourage
>> development without the implied expectation of integration.
>>
>
> It is true that there will never be hordes of people capable of making
> real contributions to most of Consix, and it is also true that there
> must always be some more or less rigorous process in place to
> constrain integrations to it. It is less clear to me why we should
> abandon any effort to make Consix itself openly developed. Could you
> elaborate, please
What many seem to want is to move the internal gates out of Sun into a
public space where eventually non-SMI developers can get commit access.
I'm not certain it'll ever happen quite that way, and if we even get
close its going to be 2+ years away.
The trend is to train external developers to the SMI development
methodology (code review, ARC, C-Team, etc) such that eventually non-SMI
engineers will be just as qualified to utilize the development process
as trained internal engineers. The difference then is that external
engineers are unpaid but have the ability to work on what they choose
rather than what their manager tells them to. Thats beyond what most
external developers want to deal with and is extremely frustrating. Am
I wrong in this?
benr.
