I'd like to run this fast track as soon as is prudent. I've been trying
to cram time in to get it into some semblance of a presentable shape,
but have decided to cut bait and would like to ask for help in crafting
this into something that can run as a fast track.
I'd appreciate any feedback regarding the case one-pager (copied below
and attached). I've also attached as a rough draft a copy of Mark C's
best practice stanza from the trove case minority opinion. It seems to
have much support, and will likely be close to the starting point for
the practice document (it also happens to align roughly with my own
opinion). I do intend to reshape the practice document further over the
weekend into something a bit more verbose. I'd also appreciate any
suggestions regarding scope. I am, for your consideration, scoping and
designing this project at this point. It needs a little thought and
construction before the case is run. ARC early, ARC often.
My intent at this moment is this:
- Happily accept any feedback regarding the fast track text itself. Is
it complete enough?
- Consider thoughtfully any feedback on the best practice document now
- Run this in a more official capacity next week sometime as a 1 week
fast track
- Grow more grays trying to drive as much consensus as I can on the real
deliverables content (i.e. the fast track).
- Expect to approach closure with text reflecting the majority opinion,
regardless of the final practice document content
Current project scope:
- Provide guidance on when to use the taxonomy (i.e. are there escape
clauses?)
- Provide guidance on how to express the taxonomy (i.e. man pages?
native documentation? decision tree?)
- Potentially provide mappings for other community standards (e.g. JCP).
- Stop ignoring the 400lb Gorilla in the corner -- the /contrib repository
I'm perfectly willing to be called insane about the last scope item and
drop it.
Enjoy your holiday weekend!
______________________
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Interface Stability Communication
1.2. Name of Document Author/Supplier:
Author: Mark Martin
1.3 Date of This Document:
22 May, 2009
2. Project Summary
2.1. Project Description:
Recent project cases have highlighted the broadening gap between
the current
ARC stability interfact taxonomy (and the expectations it is
intended to
manage) and the types of projects that are often integrated
today (with
potentially different expectations). This gap can roughly be
described
in the following ways:
- Increasingly, software is ported from a larger FOSS
community. This
community may not currently have any system resembling the Sun
stability
taxonomy, and may not currently express any expectations regarding
stability. These communities may even include internal Sun
projects.
- Where software from a different upstream community does have
stability
expectations clearly expressed, they may not align with the
taxonomy as
used in OpenSolaris.
- The existing taxonomy may be difficult to apply to certain
types of
software, particularly software intended to be used by
developers. E.g.
at what level does an interface stability apply in a Java JAR
project?
Package level? Class?
- Many consumers of these projects may not be familiar with Sun's
stability taxonomy. Developers on web technology stacks may not
even
expect to find an interface stability table in any documentation.
- Upstream communities may not be obliged to adopt any
expectations or
notations applied by OpenSolaris porting efforts.
- OpenSolaris itself has an alternate package delivery vehicle,
which does
solicit contributions from project teams and individuals outside
of Sun
(but ostensibly from within the OpenSolaris community). It is
very likely
that in practice, these packages may have differing levels and
standards
for integration, and very likely do not communicate or set
stability levels.
Currently LSARC does not address this alternate distribution
system, although
arguably the users consuming those packages is a growing
community and is
in alignment with future product development of OpenSolaris at Sun
This project seeks to address some of these concerns by
providing guidance
and a new best practice document to be displayed on OpenSolaris.org.
2.2. Previous relevant ARC cases
LSARC/2009/262 Trove 2.0.4
4. Technical Description
See the case directory for more detail
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
OpenARC
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2009-316-best_practices.txt
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090522/a52499b1/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: onepager.txt
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090522/a52499b1/attachment-0001.txt>
