Solution Deployment Descriptor Face to Face

1
Solution Deployment Descriptor Face to Face

• November 14-16

2
Welcome

• Thanks to Macrovision and Rob Ross for Hosting
  this meeting

3
Agenda

• Monday 12noon-5PM PT
• Introductions
• Logistics Rob Ross
• Summarize where we are - Chair
• Discuss Process to move forward - Chair
• Discuss Software Lifecycle and how this applies
  to SDD Randy George
• Review Requirements Categories Christine Draper
• Tuesday 9AM-5PM PT
• Present Brief Overview of related standards
  groups Tom Studwell
• Review Detailed Requirements, Identify Obvious
  cases
• Accept In-scope requirements
• Accept Out-of-Scope requirements
• Discuss controversial requirements

4
Logistics

• Network
• Dinner
• Bathrooms
• Etc

5
Where we are

• We have begun a specification document complete
  with Glossary -)
• We have collected 210 Use Cases, from 8 different
  companies/committees, which are potential
  candidates ways in which SDD may be used.
• We have collected lifecycle descriptions that
  define all the possible places where SDD may be
  relevant
• What we need to do
• We need to agree on a process to arrive at
  requirements
• We need to agree on how the SDD would be used in
  the lifecycles
• We need to resolve Requirements categories
  established in Use Cases and begin to determine
  which are in scope and out of scope

6
Proposed Process

• Use Cases are useful but insufficient
• Lifecycles will help us
• round out requirements and
• establish in-scope/out-of-scope criteria
• Review Lifecycles and determine which aspects
  affect creation of vs use of SDD
• Review Requirements Categories to see if they
  match Use Cases and Lifecycle Usage
• Agree on what categories are in and out of scope
  for SDD
• Discuss and resolve the uncertain cases.

7
Notes, 11/14/2005
8
Notes Process Discussion

• Desired end result of face-to-face is a
  nearly-final set of in-scope requirements against
  which proposals can be made
• Well take advantage of face-to-face exposure to
  debate the appropriateness of ambiguous use cases

9
Notes Lifecycle Discussion for Scope Criteria

• Randys hypothesis at some point in the life
  cycle, deployment meta-data is frozen
• Extra meta-data may be provided later on to add
  refinement or for other purposes
• A rule of thumb might be if something is changed
  or provided after a CD is burned (or could be
  burned), it doesnt apply to SDD
• If a piece of info is mutable, probably doesnt
  belong in a static deployment descriptor
• Some examples from Randy
• Licensing entitlement doesnt involve changes
  to the software package but is provided after
  the package is delivered
• Debra except for certain cases, for example GPL
  code which is immutable and viral.
• Integrators should be able to know if 3rd party
  software is GPL-covered
• Readme file if its just FYI, not important
• The Features of a package these are applicable,
  since they are critical info to deployers and
  integrators
• Localization user-facing display information
  some degree of this is applicable as it relates
  to deployment
• Arts comment in question of this approach
• All of this is really dependent upon our
  definition of the verbs used in this lifecycle
  e.g. Install, Configure, Deploy
• Suggested starting criteria for including
  information in our meta-data
• Is it relevant to deploying, aggregating, or
  maintaining the software?
• Is it defined by the producer or integrator (and
  communicated to the deployer/maintainer)?
• Does it pertain to the nature of the software?
  In other words, could it sensibly be bundled with
  the software or is it provided at a different
  time or through a different channel?
• We should factor in the degree to which this info
  applies to deployment

10
Notes Lifecycle Discussion for Scope Criteria
(contd)

• Keisuke asked to what degree bare metal
  installation is in scope
• The group felt disk image deployment was
  generally in scope
• Debra pointed out the need to bake-in and
  automate specific deployment details, especially
  for internal enterprise deployment
• Does the SDD become immutable once installation
  takes place, does it become modified to indicate
  what actually happened?
• Can the SDD change once you install it?
• The group felt that this should be possible,
  although theres some debate about the extent
• Art pointed out that our use cases define a
  system, of which the schema were defining is a
  subset
• For each use case we should identify the roles of
  the producer consumer and identify how the
  schema needs to serve them

11
Notes Requirements Categories

• Agreed-upon process
• Discuss the nature of the initial categories
  agree theyre in scope
• Deep dive on ambiguous use cases to see if
  theyre in scope
• Deep dive on each category make sure each of
  its requirements belong
• All initial Categories found to be in-scope (at a
  high-levelindividual requirements to be analyzed
  for scope in detail)
• Clarifications made to Christines requirement
  categories
• Solution Lifecycle Management should include
  whats necessary to actually deploy and maintain
  software through its lifecycle
• Requirements on Environment pertains to
  requirements for all lifecycle changes, not just
  initial deployment
• Changes to Envrionment means the promise of
  what the package will do to the environment after
  each lifecycle change
• Solution Variability means the solution is like
  a Class whose variables are set for a particular
  Instance
• Solution Composition includes definition of
  content for one package as well as package
  aggregation
• Solution Content is confusing and should be
  revisited recategorized
• For one, break out requirements for
  interoperability with other formats into a
  separate section
• Important to distinguish package localization
  from packages which deploy application
  localization

12
Notes Review of External Requirements

• 99.1 accessibility requirements
• e.g. should always have a textual stand-in for
  graphical images
• Will be a general requirement the SDD should not
  preclude Accessibility according to Section 508
  standards
• Will be added to a new Compliance to Standards
  section
• 99.2 assistance in decision-making
• We made sure some of these were captured in the
  Variability category
• Will create a new category Decision Support to
  capture the rest
• 99.3 info for progress
• Will discuss when James is present
• 99.6 interactive selection and targeting
• Some pieces need to be able to be referred to by
  a program through a key or ID
• To be added to the Compliance to Standards
  section
• 99.7 environment changes to support changes
• Already seems to be covered under Requirements
  on Environment
• 99.7.1 not a requirement on SDD, but appropriate
  for another standards body
• 99.8 build process
• Authoring of an SDD must not require user
  interaction

13
Notes Review of External Requirements (contd)

• 99.9 development aggregation tooling
• Tooling must be able to analyze requirements
• 99.10 different management environments
• We shouldnt prevent lower or higher levels of
  manageability
• This might be done by specifying different
  levels of SDD
• You could specify which minimum level you require
• For example, deployment of applications to cell
  phones might benefit from SDD packaging but the
  engine might utilize only a small subset of
  information
• 99.11 aggregating readmes
• Readmes and EULAs typically need to percolate up
  to the solution level when components are
  aggregated
• Keisuke pointed out that management tools could
  really use this information?
• Somehow mark certain files in the schema as a
  Readme or EULA
• This meets our criteria for consideration, but
  other issues arise
• is there a reasonable standard way to capture
  this?
• The group agreed that this is good meta-data, but
  it it in scope of the SDD?
• We added requirements for this to the Solution
  Description section will debate
• Is there a more general need for a way to mark
  files that might be viewed before installation
  with meta-tags?
• Incidentally, MSI supports declaration of readme,
  but not EULA
• 99.12 externalized branding
• This refers to the ability to package software in
  an OEMable format

14
11/14/05 TODOs

• Review the use cases assigned to each category in
  Christines document due 11/15/05
• Confirm all use cases in spreadsheet are captured
  somewhere in the Categories document
• Move the requirements in Solution Content
  category to more appropriate categories Toms
  copy has detailed notes
• Update the glossary for integration and
  composition terms
• Submit and analyze requirements for generic
  add-ons. We currently have requirements for
  language packs in particular, but we realized
  today that this may be an instance of a more
  general case for add-ons (e.g. Eclipse plugins,
  ISMP platform packs, etc.)
• Review specific requirements in Solution and
  Packaging Identity determine to what extent
  each will be provided for by the SDDs identity
  information
• Submit and analyze requirements for including in
  a descriptor the version of the standard used to
  create the descriptor
• Discuss Suns External Requirements when James
  Faulkner is present
• 99.3, 99.4, 99.5
• Revisit revert-upon-failure requirements to
  cover
• When a minor piece fails to deploy, dont force a
  revert
• Are there pieces which, once deployed, shouldnt
  be reverted, even if the overall solution fails
  to deploy?

15
Parking Lot

• Define the levels of compliance to the SDD to
  which exploiters can provide implementations
• Possibly in a separate document, possibly include
  in the primer
• Determine extent to which this can be defined by
  this group