James C. McPherson wrote:
> James Carlson wrote:
>> James C. McPherson writes:
>>> Frank Che wrote:
>>>> Requested release binding is patch/micro for OpenSolaris
> True, and I consider the "patch/micro" request to be incorrect
The final binding is a synthesis of the team's desires and the
type of change actually being proposed. The actual changes set
the "low bar", the team's desires can only raise it.
Patch/Micro seems appropriate based on the actual change;
Minor might be more desirable as a way of preventing feature
creep in the Update releases. The former is an ARC call,
the other is a project team one.
-John
<
ARC Tutorial Warning
It is safe to stop reading now :-)
>
What is a "Release Binding"?
In simplistic terms, a project can be thought of as consuming
an existing system, applying some changes to it, and producing
a new version of the system.
The ARC review focuses on those changes; one of the outcomes
of the review is a pronouncement about the magnitude and
impact of those changes. That pronouncement is called the
Release Binding.
At any given time, there are several different releases under
construction:
Solaris10updateX (a patch gate that allows a restricted
set of new features),
OpenSolaris/Nevada (a Minor release) and
(maybe?) OpenSolaris/Indiana (a Major release).
The case's release binding is used to steer a project to
the appropriate integration gate for a Major release, a
Minor one, or a Micro or Patch.
An example:
Assume the baseline existing system was the "zpool" command.
Grunging thru the ARC case archives, we find several cases
that describe zpool's Exported Interfaces; in particular,
they set expectations as to their future evolutionary stability.
Example1:
Another zpool project comes in and says they wish to change
the meaning of an existing command line option such that it
does a completely different thing. Looking at the previous
ZFS ARC cases, we find that the interface stability level
for that option was Committed. Looking at the Interface
Taxonomy, we find, under the heading "Committed":
> Incompatible Change major release (X.0)
Thus, the release binding would need to be Major.
(Committed Interface + Incompatible change = Major binding)
This poses a problem today, since we don't *have* any gates
chartered for a Major Release.
If the project team was expecting Minor or Patch binding,
this would be a good time for an ARC discussion about
living up to expectations - and setting them correctly in
the first place :-)
Example 2:
A project comes in and proposes to add a new flag to zpool.
The change being proposed is a "compatible" change - existing
users of the zpool command won't be impacted by this change.
What is the release binding? From the Interface Taxonomy,
we find:
> A compatible addition is normally permitted in a minor
> (X.Y) release; adding features in a micro (X.Y.Z) release,
> or in patches makes it hard for ISVs to determine when
> they can start depending on the existance of a new feature.
Thus, the release binding is at most Minor, but *could* be
Micro or Patch if sufficient justification were given.
(Compatible feature addition = Minor +/- wiggle room)
This "justification" or "wiggle room" is where the project
team's desires come in, and is why we usually ask them for
their binding suggestion.
Assume the final binding is "Patch", with the justification
that this change is needed in Solaris10UpdateX. This
project would be expected to integrate into S10Ux AND
OpenSolaris so that there would not be any feature
regressions between the two versions. If there also
was a Major gate out there, it would go there as well.
-John
