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

List:       opensolaris-arc-discuss
Subject:    Re: [arc-discuss] Delivering one ARC'ed project in multiple
From:       James Carlson <james.d.carlson () sun ! com>
Date:       2009-01-21 19:04:35
Message-ID: 18807.29123.25742.780722 () gargle ! gargle ! HOWL
[Download RAW message or body]

Roland Mainz writes:
> James Carlson wrote:
> > I think the option you're looking for is "fast-track."
> 
> Ok... but that would mean we have the code ready _before_ the ARC case
> (technically that's again the case for ksh93-integration update2 since
> update1 took that long... ;-/ )

No.  The code doesn't need to be ready.  The complete idea of what's
being delivered does need to be there when the case is finally
approved.

The distinction's important on two fronts: you don't have to seek
final approval on your first ARC contact, and the ARC doesn't really
care whether you've got code yet.

> ... and if the ARC case changes or
> rips-out things then we spend again major work to adjust the code.

There's always a balance between scheduling reviews and dealing with
the outcome of the reviews -- whether architectural, design, or other
sorts of reviews.  I agree it can be tough, but I don't agree that
it's as black-and-white as I think you're saying.

> Somehow I hope to get the following ordering:
> 1. Get raw prototype
> 2. ARC case fasttrack
> 3. Do main coding/testing work
> 4. Deliver code if we reach the 90% barrier
> 5. Do more coding work to cover the remaining 10%
> 6. Putback the remaining parts once they are ready

There are multiple different approaches that are viable here.  Here
are two (not necessarily exclusive) that are entirely workable:

  A.  Don't use a fast-track for the initial case, because it offers
      too little ARC interaction to be useful for your purposes.
      Instead, change step (2) to read "ARC case inception" and insert
      step (3.5) reading "ARC case commitment."

      The whole point of a fast-track is that the change is obvious,
      non-controversial, and *well-understood*.  If it fails one of
      those tests, don't despair; just don't use the wrong process for
      the task.

      If changes occur between that new (3.5) and (4), you'll need a
      fast-track to amend the case, but otherwise it fits in the
      documented process nicely.

  B.  At step (2), file a fast-track that covers what you believe
      you'll be able to do.  At step (4), file another fast-track
      amending your previous case to cover the 90% you were actually
      able to do.

      Just because you have an approved fast-track doesn't mean you
      can't ever change things.

In other words, you're still making things too hard on yourself.

> >   a.  If the original case had already been approved, then I'd then
> >       file a fast-track to amend that case, describing what I was
> >       going to deliver separately, the impact of this change, and any
> >       resulting changes.
> 
> That's what we did for ksh93-ingration update1 multiple times and we
> still needed 15 months. Somehow I'd like to get the "unpredictable"
> parts moved to the beginning or having them "disarmed" that they can't
> interfer with the project schedule anymore.

The ARC can't help you with project planning.  But when you discover
that you need to change things we *can* review the changes, and often,
if clearly described, do so fairly quickly.

> > I suspect you're making this much harder than it really needs to be,
> > and that you might be doing so based on an assumption that the ARC
> > can't handle changes.  We're just working peer engineers, not the
> > local zoning board.
> 
> What is a "zoning board" ?

Maybe it's a local term.  Google finds:

  http://en.wikipedia.org/wiki/Zoning

Zoning boards often worry about the height of your roof, the square
footage of your deck, and so on.  Going before a zoning board (as
opposed to a real technical review) is often an experience in
low-level politics at its worst.

-- 
James Carlson, Solaris Networking              <james.d.carlson@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
_______________________________________________
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]