[caiman-discuss] Draft PSARC slides for comment

[Dave Miner]

Jack Schwartz wrote:
> (Resend with proper caiman-discuss address)
> 
> Hi Dave.
> 
> Looks pretty good.  Here are my comments:

Thank you for looking them over.

> 
> Page 5: I don't understand what is meant by "No distractions from
> installing".
> 

The old installer & sysidtool had lots of unnecessary configuration 
tasks mixed into the installation flow.

> I would mention as a principle (goal?) flexibility offered through
> different inter-operational tools for configuring images and installing
> them.  For example, once a system is installed using AI or slim install,
> DC can be used to generate a medium to backup or replicate the system.
> (There's also been discussion of functionality to install common bits on
> multiple systems and then tweek the system-specific things like IP
> addresses, though I'm not sure where that will go -- probably AI?)
> 

I treat seamless integration among the components (which is what I think 
you're trying to say) as a requirement.

Your parenthetical question is the "Replacement for Flash Archives" on 
the "Things to Figure Out" slide.

> Page 13/14:  I assume "H" stands for "half" (as Q1 = quarter 1) with
> "Indiana 1H/2H 2008".  I haven't seen this terminology before, but maybe
> it's just me.
> 

Yes, that's what it means.

> It is clearer to  say CY 2008 or FY 2008 to distinguish calendar vs
> fiscal years, for those who may look back at this doc in the future.  I
> always had to make CY/FY clear in cases I presented to PSARC, even when
> it seemed obvious.
> 

My way to disambiguate is that OpenSolaris doesn't operate on SMI fiscal 
years ;-)  I'll clarify this, I guess.

> This may be totally out of scope, but are "Indiana xH 2008" official
> names?  I suggest Indiana release 1, 2, 3, etc.  Indiana Preview 1 and 2
> had/have clearer names and are just fine.  Of course, the dates will
> need to be explicitly spelled out in the sub-bullets.
> 

These are not release names, they are meant to provide some general idea 
of the time scale when things will be available.  We are explicitly not 
tying them to a particular release of Indiana, as I don't control that 
schedule - it's a train, and someone upstairs might decide to run a 
special that's not on the current schedule.

> While progress on the various pieces is reported, the dates for
> individual pieces are not specified, only "integration to ON as pieces
> ready".  Seems like individual dates are needed since one reason for
> these slides is to give expected timelines.  1/2 a year seems too broad
> a timeline to me.
> 

The reason I've done this is that our primary purpose right now is to 
enable the Indiana releases.  We are not making commitments about dates 
for integrating into Nevada, because the distance between having pieces 
in Indiana (with its intentionally restricted functionality and looser 
stability requirements) and having them ready to integrate into Nevada 
(with its greater functionality, boatloads of stability requirements and 
giant checklists) is non-trivial and we're not scheduling for that at 
the moment.  So, I agree that the ARC may be unsatisfied with my degrees 
of precision, but that's as good as they get for right now.  I've added 
a sub-bullet about this to slide 14, anyway.

> Please let me know if I can help out with PSARC or other process tasks.
> 

You'll get plenty to do when we get to an inception for DC ;-)

Dave