Keith M Wesolowski wrote: > On Fri, Mar 16, 2007 at 03:28:56PM -0400, Stefan Teleman wrote:
> They own their code. They don't own SFW, nor do they own Solaris. > Once you give up control of your own platform you might as well shut > the doors, send everyone home, and divide the cash amongst the > shareholders. See DEC and SGI, to name a couple. I am not convinced that DEC or SGI went under because they kept up-reving Apache. >> This also creates the perception that the ARC submitter for any software >> controlled outside of SMI, and which proposes to export Stable or Committed >> Interface Levels, can predict the future. I am not prepared to assert such >> innate abilities. > > You're asserting that the OpenSolaris community doesn't own SFW, and > that Sun doesn't own Solaris. I have made no such assertions. Please provide a quote. If no such quote can be provided, I would request that we contain the scope and purpose of this exchange to facts. > That's unacceptable. Solaris customers > (and customers of other OpenSolaris-based distribution vendors) Which are these "OpenSolaris-based distribution vendors" ? > rely > on the promises made by those vendors. Indeed, a major reason they do > business with such vendors rather than directly obtaining their > software from Apache and co.is exactly that insulation; it's the > vendors' - and in this case, the community's - responsibility to > shield those customers from arbitrary external breakage. This is not a case of "arbitrary external breakage". This is a case of deliberate breakage in an upgrade. > By making a > promise of commitment to an interface, Sun (at least) is on the hook > to those customers. These customers have asked for Apache 2.2.x upgrades and mpm-worker. > No one is asserting that the Apache Foundation or > anyone else made commitments to those customers. We did, and it's our > responsibility to honour them. As I have already explained in my previous message, these promises should *not* have been made, because they were based on assumptions, hypothesis, inference and guesswork. > If we can rev the software without > breaking that commitment, great; if we can't, then we can't rev it. Are you proposing that Nevada never upgrades Apache to 2.2.x ? Or are you proposing that Solaris/OpenSolaris never attempts to keep pace with the development train of external open source software, and continue to deliver obsolete software, because three years ago we made an incorrect assumption and commitment about someone else's future ABI compatibility, which we now find impossible to honor ? This is a direct quote from http://httpd.apache.org/: [The Apache HTTP Server Project is proud to announce the legacy release of version 2.0.59 of the Apache HTTP Server ("Apache").] Please note the word "legacy". Are you suggesting that the eternal delivery of legacy [Obsolete] software will be the driver to new customer adoption ? Or that it will be the driver for existing customer retention ? If that is indeed your assertion, can you provide one example where the presence of obsolete, legacy, sub-performing and un-upgradeable open source software in Solaris led to a new customer acquisition ? "Sun Sales: We have Apache 2.0.58. It's been labeled legacy by Apache, it uses prefork, it's really slow, and it's subpar to both SUSE's and RedHat's Apache. We haven't changed it in three years, and we never plan to. But you can rest assured that 100 years from now it will be backwards compatible." "New Customer: Great! Where do I sign? Can I tell my friends about it ? I know at least three CIO's who want to downgrade their fast and threaded 2.2.4 mpm-worker on SUSE to your slow and legacy 2.0 prefork." > We already have a vehicle for delivering 'pass-through' software, with > no commitment of any kind on our part. That vehicle is the Companion. The Companion does not deliver Apache. > If the reason for doing this is to obtain mpm-worker, why is it > impossible to do this in the framework of the 2.0 APIs? Because, as I have already explained, mpm-worker and mpm-prefork are incompatible. > Neither of these justifies breaking compatibility. There was no compatibility in the first place. > Put another way, why not Volatile? Because Volatile would allow us to remove Apache, which we do not intend to do. > By moving to Uncommitted, you're > asserting that there will never be any similar changes worth breaking > compatibility in a patch. No, I am not asserting that at all. I am asserting that we will not remove Apache 2.2.x, and that future upgrades to Apache 2.2.x (if delivered) *might* deliver binary incompatible changes. > But what's the difference? The compatibility guarantee of Uncommitted is the > same with respect to > patches as the guarantee of Committed/Stable is with respect to minor > releases; namely, that incompatible changes will not be made. Why is > a performance improvement of "orders of magnitude" justification for > breaking a Committed interface in a minor release but not for breaking > an Uncommitted one in a patch? I have already addressed this question: the APR 2.0 Interface should *NOT* have been classified Stable. It was a mistake and an inaccurate reporting of fact to classify it as Stable. The Interface Taxonomy page at opensolaris.org states: "Committed interfaces are often proposed to be industry standards, as was the case with RPC. Also, interfaces defined and controlled as industry standards are most often treated as Committed interfaces. These are interfaces whose specification is often under the provider's control or which are specified by a clearly versioned document controlled by a well-defined organization. If the interface specification is not under the implementation provider's control, the provider must be willing to fork from the interface specification if required to maintain compatibility. In the case of interface specifications controlled by a standards body, the commitment must be to a clearly identified version of the specification, minimizing the likelihood of an incompatible change (but it can happen through formal spec interpretations). Also, if the interface specification is not under the control of the interface implementation provider, then the controlling body and/or public, versioned document must be be noted in the documentation. This is particularly important for specifications controlled by recognized standards organizations." Is apache.org's APR Interface an Industry Standard ? Was it an Industry Standard when it was classified as Stable in 2004 ? > You seem to be asserting that we don't have any control of our platform and > that the only purpose for > delivering it is to offer the latest and greatest fresh from > apache.org's servers in a user-friendly svr4 package format. I have made no such assertions. Where does this ARC Case propose that the delivery of Apache 2.2 tracks the delivery schedule of the Apache 2.2.x releases at apache.org ? This ARC Case is about the Integration of Apache 2.2.4. It is not about creating a subscription to apache.org's delivery schedules. > A possible way to address this would be to deliver compilation > symlinks only for the most recent library, allowing software linked > against previous libaprs to continue functioning but requiring all > newly-built software to use the new one. No, this is *precisely* the type of overly complex and incomprehensible hack that I am trying to avoid. > In this case you'd also need > to modify the old apxs (and perhaps other scripts and programs) so as > to prevent them from being used to build new modules. Another > question, then: is libapr designed (a la libresolv/libresolv2) such > that multiple versions can coexist in the same address space? No, they cannot coexist, they are API and ABI incompatible and this fact has been clearly explained in the ARC Draft Case. > A hypothetical one - one that actually believes, as Sun and many of us > in this community like to talk up, that interface stability has value > and is a compelling feature in an operating environment (and the > rather old-fashioned idea that a promise is a promise). Here's another old fashioned idea: Don't Make Promises You Cannot Possibly Keep. --Stefan -- Stefan Teleman Sun Microsystems, Inc. Stefan.Teleman at Sun.COM
