[arc-discuss] [ogb-discuss] John's thoughts on how Projects should interact with the ARC community

Tue Jan 29 19:51:48 PST 2008

Shawn.

Some of us came to OpenSolaris because we wanted an open-source  
operating system that still cared about quality, rather than the  
"weekend hack-fest" that the other F/LOSS operating systems have become.

Abandoning ARC for all but the "official Sun Value-Added" Solaris  
would be the greatest tragedy in computing since AT&T sold the rights  
to UNIX.

There are plenty of open-source operating systems where weekend  
hackers can dump their bad code. I'd prefer if Solaris remained the  
bastion of quality in a sea of mediocrity.

On 29-Jan-08, at 7:21 PM, Shawn Walker wrote:

> On Jan 28, 2008 10:19 PM, John Plocher <John.Plocher at sun.com> wrote:
>> [lets take this over to arc-discuss, rather than spamming OGB  
>> mailboxes]
>>
>> Shawn Walker wrote:
>>> To me, this only applies when your "project" has a definitive  
>>> conclusion.
>>>
>>> As an example, my idea for a project that would maintain a "bleeding
>>> (hemorrhaging? :))
>>
>> In my glossary, that isn't a project, it's a consolidation or a  
>> distro.
>>
>> i.e., you aren't doing anything other than providing an integration  
>> point
>> for other people's projects to integrate.
>
> Yet, in current OS.org terminology, it has to be a project since only
> projects get repositories, etc. ;)
>
>> Your bar for entry is really low - anyone can hack and dump stuff  
>> into
>> your source tree without any consideration for the consequences - if
>> this is something you want to spend your energies on, go for it.  I'm
>> not sure I understand how you intend to manage the chaos that will  
>> ensue,
>> but more power to you.
>
> Most open source projects fit this definition and get along just fine.
> As my grandmother says, "Whatever floats your boat."
>
> Remember the intent of this not to have a stable, wonderful, everyone
> wants to use it distribution.
>
> It's a "break me please" distribution where it is used as a raw test
> bed of random bits.
>
>>> While I can agree with that to a certain extent; sometimes you are  
>>> so
>>> uncertain of an idea that you need to formulate it in code (paper
>>> napkin? :)) before you ever present it to someone for that sort of
>>> review.
>>
>> Maybe you and I don't share the same understanding of ARC review. Let
>> me try and articulate my understanding:
>
> Understanding something doesn't mean you agree with the when and how
> of applying it.
>
> That's primarily where I digress.
>
>> In such a world, it is only polite to engage in conversation with
>> all the various stakeholders when you embark on a project to change
>> something.  At a minimum, you will want to let people know that you
>> are interested in a part of the code that they are or have been  
>> working
>> on, because they are the ones you will turn to to get advice,
>> suggestions and support.
>
> Sometimes that is appropriate; other times you'd rather just
> experiment without bothering anyone.
>
>> One of the forums you do those activities in is the ARC community.   
>> By
>> starting a project, you tell the community something about what you
>> intend to do.  The community members who have existing knowledge
>> and interests that overlap your project will be able to find out
>> that you are joining their ranks.
>
> Ah, but if you don't know what you're going to do fully yet, you may
> get questions you don't intend to answer yet.
>
> Blind experimentation can be fun sometimes.
>
>> By coming to the ARC community with questions, you find an audience
>> of community leaders who can help find answers; by discussing your
>> observations, problems and plans with them, you share your expertise
>> with the rest of the community and help educate the rest of us.
>
> The assumption there is that you have grand plans behind what you're
> trying to accomplish.
>
>> At some point in this extended discussion, you and the community
>> leaders will both feel that your plans and proposals are mature  
>> enough
>> for the community to commit to, and you have an ARC commitment  
>> review.
>> This final review usually[*] happens 6 to 18 months after a project
>> starts.
>
> In the grand scheme of things, that's just too much for many open
> source developers.
>
> Many of them are "weekend hackers" who just want to stick their hands
> in some code and make a "finger painted program" :)
>
> The results may not be pretty, but sometimes it's enough to spark
> ideas that can result in a much better one later.
>
>>> I might want to try several architectural approaches to something,  
>>> in
>>> code, before I ever approach a process such as ARC about it.
>>
>> Supposedly in these attempts you interact with other OS.o developers,
>> don't you? (Or are you bound and determined to be a community of one
>> and do all your development thinking in isolation?)  All the ARC  
>> process
>> asks is that when you have those scope and charter discussions that  
>> you
>> consider having them in a context where the existing community  
>> leaders
>> (aka ARC community members) can follow along and participate.
>
> Again, these processes should be encouraged when certain goals are
> present for a project.
>
> However, sometimes the goal is just to "scratch and itch." Quite
> frankly, writing proposals, etc. is far more than you're going to get
> many open source developers to do.
>
> To be honest, going to the degree of effort that is currently required
> for integration feels too much like working for Sun for free.
>
> Most open source developers are used to a patch-by-list developer
> mentality and aren't interested in being indoctrinated in a set of
> software processes.
>
> For those developers that want to be directly involved in the
> integration process or who want to see their changes go back to Sun,
> dealing with these is an understandable necessity.
>
>>> I don't think it's a "failure mode" to wait until you think you're  
>>> ready.
>>
>> It is if you equate "ready" with "already committed myself to a  
>> particular
>> design or implementation", and "interacting with the ARC"  with  
>> "all they
>> do is review final specs and make life hard for developers".
>
> Again, it all depends on your goals. If one of my goals was to
> integrate with ON, for example, I would expect to have to interact
> with the ARC process at some point.
>
> However, if my goals is just to "hack and have fun" -- then it's a
> burden I don't need.
>
>>> The problem with trying to enforce the "process early, process  
>>> often"
>>> approach is that it encourages people to be secretive about their
>>> activities and make it look like they've done what you wanted.
>>
>> Not enforce, but rather design our systems of communication and
>> governance such that involving the community leaders in project
>> development is the expected and natural way of developing stuff.
>>
>> Developing anything without interacting with the core community
>> members who have taken responsibility for that part of OpenSolaris
>> should be viewed by all as an abnormal and undesirable activity.
>
> John, I strongly disagree.
>
> Attempting to codify stringent requirements into our system is only
> going to kill any interest the average open source developer might
> have.
>
> I fully support letting Sun have such roles for integration with their
> "gates"; but forcing those requirements on others is not acceptable.
>
> Labeling such activity "abnormal" or "undesirable" is akin to saying
> that Sun knows best and that no other process is acceptable.
>
>>> Sun's processes are not going to fit every project that the  
>>> community
>>> wants to engage in.
>>
>> Certainly - if all you want is a sandbox to play in, and don't intend
>> to do anything that will ever impact any other source tree in the
>> community, then yes, the ARC process probably can safely be ignored.
>>
>> Sun's ARC process is simply "think before you act", "do things
>> by intent", and "set expectations, then live up to them".  In other
>> words, "be an engineer".
>>
>> I'm not willing to abandon those core principles just because some
>> potential project might not be comfortable with the required
>> discipline.
>
> No one is asking you to abandon those principles when it applies to  
> Sun.
>
> However, when it applies to projects in the Community, the respective
> project or Community Group should be the one setting policies.
>
> -- 
> Shawn Walker, Software and Systems Analyst
> http://binarycrusader.blogspot.com/
>
> "To err is human -- and to blame it on a computer is even more so." -
> Robert Orben
> _______________________________________________
> ogb-discuss mailing list
> ogb-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/ogb-discuss