Finally I've found/made the time to start working on the
arc process for opensolaris.  As a reminder, we have a
focused community project that is chartered to

> define the intended relationship and associated
> interactions between the Architecture Community
> and the other OpenSolaris Community Groups and
> Projects.

Towards that end, I've set up a mercurial repo[1] on os.o,
set up the arc.opensolaris.org website, and cobbled together
a poor excuse for a sandbox[2] for all of us to be able to play
in.

There isn't much there yet - the ruby on rails prototype is
a simplistic "hello world" placeholder[3] - but it /is/ a
beginning.

The next steps I see are to step back and spell out the desired
requirements for the process we want to ultimately implement.
What are the relationships, workflows and process steps?

Quoting again from the Project charter,

> Scope of work (Preliminary)
> 
>     Some of the things that I expect that this project will
>     need to contemplate, address and/or define are:
> 
>        1. For context and understanding:
>              1. How does the Sun ARC system operate today?
>              2. What was the ARC/dev process that was
>                 developed as part of the OS.o community
>                 launch?
>              3. What other development processes are
>                 in use in the community?
>              4. What roles exist in the OS.o community?
>              5. How do they relate to the development and 
>                 ARC processes?
>              6. What workflows exist in the OS.o community 
>                 today?
>              7. How do they relate to the development 
>                 and ARC processes?
>        2. Who should "do" ARC? When and how long?
>        3. Who/what should "be" ARCd? When and how often?
>        4. Who consumes the output of the ARC process?
>              1. What are those artifacts?
>              2. Are ARC decisions binding or merely advisory?
>              3. Who decides? 
>        5. Not all CGs/Projects have the same needs.
>              1. What interactions are expected or desired 
>                 between the Consolidation CGs, the "other"
>                 CGs, Projects, the various Distros, the
>                 Architecture Community and this thing we
>                 call the "ARC"?
>        6. What do the terms "do", "be" and "ARC" mean as used above? 

(I'd add:  7. How can we transition from what we are using now
               to what we are inventing here?)


I'd like to spend some of the time in Santa Cruz coming up with
some of these answers/values, and then see what we can do to reflect
them in this sandbox to see if they actually work.

If, along the way, we end up spilling over into the community structure
(CG & Ps, consolidations, SIGs...), that's OK by me - as long as we don't
try to boil the ocean!

   -John

____
[1] ssh://anon at hg.opensolaris.org/hg/arc-process/arc-prototype
[2] http://arc.opensolaris.org/projects
[3] This is a simple Ruby/Rails(v2) application; it should be easy to
     setup and play with locally as well:
       set up a rails 2.x environment,
       hg clone ssh://anon at hg.opensolaris.org/hg/arc-process/arc-prototype 
arc-prototype
       cd arc-prototype
       edit and configure config/database.yml to match your database,
       rake db:create
       rake db:migrate
       ./script/server -p 3000
     then point your browser at http://localhost:3000 and have fun - I am!

Reply via email to