Volatile binding with an admonishment in the man pages indicating the
compatibility hazards associated would be an agreeable compromise.
(Uncommitted is, IMO, still a higher level of commitment than I'd be
happy with, at least not without some kind of formal plan to ensure
compatibility continuity.)
One of the implications of such a binding (Volatile), is that projects
which build other C++ shared libraries upon this one cannot have a
commitment level higher than Volatile either.
Note that the Volatile commitment level could be *increased* at a future
point in time, if the project team is able to bring a case justifying
such an increase (i.e. address the compatibility concerns) to ARC.
-- Garrett
John Fischer wrote:
> Stefan,
>
> The project being derailed by a committee member means that the case
> can still move forward. However, additional materials must be created
> or a meeting scheduled to discuss the remaining issues. It does not
> mean that the case has been denied. It simply means that the committee
> can not make a decision based upon the discussion and materials. This
> is a procedural issue for us to navigate through the process. It simply
> means that we need a slightly different approach and is out of our
> hands on keeping the "train on the rails".
>
> As Garrett has pointed out there are a couple of different routes that
> the project team can go down. These options being:
>
> 1. modify the case to address the concerns
> 2. schedule a meeting with additional materials addressing
> the concerns
> 3. withdraw the case
>
> It is clear that you do not want to withdraw the case. I agree it
> is necessary for JDS and KDE moving forward. So that is out of the
> question.
>
> It is also clear that making the interfaces Project Private is also
> out of the question as it is needed by various consolidations and
> also would be beneficial to our customers. Lowering the interface
> from Committed to either Volatile or Uncommitted might work as the
> interface could be used internally and customers could us it
> understanding that the interface might change in the future. This
> might also allow the project to move forward.
>
> Alternatively if you want to move forward and keep the interfaces
> Committed then we will need to schedule a meeting with appropriate
> materials. It looks like the materials need to be updated with at
> least stating that the interfaces implement I18N and there might be
> a little bit more to add just to clarify various points. I would also
> expect to see some sort of document describing the transition plans from
> SFW to the DevPro group.
>
> Thanks,
>
> John
>
>
> Stefan Teleman wrote:
>>
>>
>> Garrett D'Amore wrote:
>>
>>>>> I'm saying that this is true *unless* you're willing to step up to
>>>>> the plate to provide the guarantees that would be required, and
>>>>> that I think it would require a full case review in order to fully
>>>>> assess that.
>>>>
>>>> Which guarantees ?
>>>>
>>>> The library guarantees ABI stability within Major Release 4
>>>> boundaries. It also implements an Industry Standard. As such, it is
>>>> suitable for a Committed classification. However, you oppose this
>>>> stability classification. This is one example of a guarantee
>>>> provided by this library, which you oppose.
>>>>
>>>> Where are the specifications for these other guarantees that you
>>>> are seeking ? Where have these constraints -- controlling these
>>>> unspecified guarantees -- been defined ?
>>>>
>>>> You are opposing the guarantees explicitly provided by the library,
>>>> and instead, you seek an unspecified set of other guarantees, for
>>>> which you have not provided constraint definitions.
>>>>
>>>> This fast-track cannot address architectural requirements
>>>> constraints which are:
>>>>
>>>> 1. Outside the scope of the case itself.
>>>> 2. Intangible and/or impossible to define (example: ?void developer
>>>> confusion).
>>>> 3. Based on the introduction of continuously changing requirements,
>>>> or definitions.
>>>
>>> Okay, we have a significant failure to communicate.
>>>
>>> First off, *SOURCE* level commitment is *NOT* the same as binary
>>> commitment.
>>
>> 1. What is the definition of *SOURCE* level commitment ? Please
>> explain, for the record.
>> 2. How does this definition of source level commitment apply to this
>> Case ? Please explain, for the record.
>>
>>> The Standard says *nothing* about binary commitment.
>>
>> Correct. It has already been explained to you why the Standard
>> Committee chose to make that decision.
>>
>> However, the *IMPLEMENTATION* of the library makes a very clear
>> binary compatibility commitment. This commitment has already been
>> stated in the Case Materials.
>>
>>> I understand that the project seeks to provide a conforming
>>> implementation of the Standard -- that says *nothing* about
>>> compatibility of applications or libraries provided here.
>>
>> The ARC Case explicitly states *ALL* the compatibility constraints.
>> The integration provides no applications, only a shared library and
>> associated header files. The assertion that the ARC Case says nothing
>> about compatibility of applications or libraries provided here, is
>> false.
>>
>>> All those other "constraints" are certainly *in scope* if you seek
>>> to create a new binary ABI for C++ programs.
>>
>> I am not, and I have already stated that this Case does not introduce
>> a new C++ ABI. You have made this assertion. This assertion is not
>> supported by the facts.
>>
>>> If you're talking about a new stable base library (instead of the
>>> shipping libC) then this is what you're doing.
>>
>> This is precisely *NOT* what I am doing. Nowhere has this case
>> proposed the introduction of a "new stable base library instead of
>> the shipping libC". The existing libCstd.so will continue to ship.
>> The existing libCrun.so is needed by the Apache Library.
>>
>> The assertion, or inference, that the Apache Library proposed by this
>> Case attempts to replace the existing libCstd.so, is false.
>>
>>> Let's be 100% clear here:
>>>
>>> There are exactly three ways forward for the project team (short of
>>> trying to do something to get me ejected from PSARC):
>>
>> For the record, I am not interested in backroom politics. Maybe I
>> should be.
>>
>>> 1) reduce the scope of what you're supplying to Project or
>>> Consolidation Private
>>>
>>> or
>>>
>>> 2) have your case derailed (voluntarily or otherwise) into a full
>>> case, and deal with the full consequences of creating a new C++ ABI
>>> for Solaris
>>>
>>> or
>>>
>>> 3) withdraw your case altogether.
>>>
>>> My personal preference at this point is #2. Unless you state your
>>> intention to follow course 1 or course 3, please consider your case
>>> derailed. I'm willing to talk off line with you and the compiler
>>> folks to help formulate appropriate materials for a full case.
>>
>> I will not reduce the scope to Project/Consolidation Private, I will
>> not voluntarily derail, nor will I voluntarily withdraw it.
>>
>> --Stefan
>>
