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 -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
