10G link properties [PSARC/2009/206 Self Review]

[Garrett D'Amore]

James Carlson wrote:
> Peter Memishian writes:
>   
>>  > By "release taxonomy," I'm guessing that you're referring to the
>>  > release binding for OpenSolaris.  Do we actually have a release
>>  > binding for it yet?  Is it a major release?  What does "uname -r" say?
>>
>> This is a serious rathole, but it's obvious we are making some changes for
>> OpenSolaris that are incompatible with Solaris 10.  An obvious example in
>> this space was removal of implicit VLANs; removing dladm link properties
>> is certainly no more extreme than that.
>>     
>
> We didn't review that change with a Major release binding -- 2006/357
> has a "Minor" release binding.  We accepted it as a reasonable thing
> to do, given the fact that it was possible to adopt (and recommend)
> the new "create-vlan" style before upgrading, and provided that there
> was an upgrade mechanism that handled the transition properly (which
> the project team provided).
>
> I think my question stands.  We don't know what the release binding
> for OpenSolaris is supposed to be, and it seems precipitous to approve
> or assume random changes are acceptable for "Major" release binding,
> because it's a one-way trap.
>
>   
Well, that's true for other parts of OpenSolaris too.  IPS anyone?

There is still a lot that's just unknown about the way OpenSolaris is 
release engineered ... too much of it is not in sync with the rest of 
the way things are done.  (The separate defect tracking system is just 
one example...)

That said, I'd prefer to try to avoid breakage unless there is some 
compelling need.  Breaking link properties may be a small enough change 
that it could be done in the context of a minor release.

But its all *moot* at this point.  We have at hand a specific proposal, 
which is a straight-forward extension of already delivered 
architecture.   It should have been automatic/self-review.

We don't have any other specific proposal to change the link properties 
or link management.  I'm sure that the submitter and I would probably be 
happy to entertain alternate proposals for the future -- *in the context 
of a different case*.

Put another way, if you want to change the way link management is done, 
make submit a new case with a specific proposal.  Please don't penalize 
this submitter/case for following already established architecture when 
there is no clear alternative.

    -- Garrett