On Fri, Mar 16, 2007 at 03:28:56PM -0400, Stefan Teleman wrote: > Whatever the reasons the Apache developers had to break ABI, they must have > considered them to be valid, and justified. The fact is that the Apache > developers own the Apache code, and can do whatever they want with it, and > with their ABI. "Whatever they want" includes breaking it.
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. > 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. That's unacceptable. Solaris customers (and customers of other 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. By making a promise of commitment to an interface, Sun (at least) is on the hook to those customers. 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. If we can rev the software without breaking that commitment, great; if we can't, then we can't rev it. We already have a vehicle for delivering 'pass-through' software, with no commitment of any kind on our part. That vehicle is the Companion. > > Or, can you provide overwhelming justification for doing so now? > > 1. Performance is orders of magnitude better with mpm-worker than > mpm-prefork. > 2. LAMP offers both mpm-prefork and mpm-worker, we do not. 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? Neither of these justifies breaking compatibility. Examples of valid reasons might be that it was never actually possible to use the interface (perhaps it was always delivered with a bug that caused any caller to any of the functions to immediately crash), or that we're certain for whatever reason that it has no consumers. Put another way, why not Volatile? By moving to Uncommitted, you're asserting that there will never be any similar changes worth breaking compatibility in a patch. 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? 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. If that's the case, you might as well go all the way so at least we won't have to do this again when someone decides that Sun, for business reasons (namely, that we never bothered releasing S11 because we've already backported every worthwhile feature into the 27 S10 updates), really needs a better SAMP stack in S10U28? > This is a valid point: Apache 2.0 and Apache 2.2 *could* coexist, by > installing Apache 2.2.4 in /usr/apache2.2, and leaving Apache 2.0.x where > it is right now (in /usr/apache2). However this will create additional > complexity for those other applications which depend on APR (example: > Subversion), and which will now have two choices as to which APR Interface > to bind to. It is unclear to me which of the two is the lesser of the evils: > > - overwrite /usr/apache2 with 2.2.4 and break ABI, but have only one APR > Interface to bind to > - have both /usr/apache2 and /usr/apache2.2 and create the possibility of > application <X> binding to /usr/apache2, application <Y> binding to > /usr/apache2.2 and application <Z> binding to both <X> and <Y>. 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. 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? > >Sounds like this Solaris experiment my web hosting company conducted > >was a waste of time, then. I guess I'll just go back to Red Hat. > > Which company is that ? URL please. 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). -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
