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
>
