John Plocher wrote:
> 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.
My only concern here is that IPS itself is not Patch or Micro. So this
case doesn't *itself* have a burden that would require a minor release,
but it has a dependency that does.
I'm happy with Patch or Micro (but not ambiguous "Patch/Micro"),
*provided* that we all understand that this doesn't set a precedent
where someone could use this case's binding to bring along the
dependency with a stricter binding requirement (IPS in this case) as
part of a backport -- at least not without coming back to ARC for a
change in the binding on the dependency.
(Granted, "backporting" IPS seems a bit unlikely to me. My concern is
that a precedent might be set for other less "obvious" cases.)
-- Garrett
>
> -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
>
>
>
>
>
>
>
>
