Hi Sriram, Sriram Natarajan wrote: > Stefan Teleman wrote: > >> >> >>> This does assume 2.2 interfaces are Uncommitted. They could be made >>> Volatile in which case the above issue is not an issue as far as >>> stability contracts (of course it still results in an annoyed user). >>> But there has been reclutance in using Volatile. >>> >>> >> This was precisely the assumption made when Apache 2.0.x was first >> integrated in >> Solaris: that Minor/Micro Apache releases will stay binary compatible. >> >> Turned out not to be the case. >> >> >> > With respect to open source components, we can never really claim binary > compatibility as we don't control what goes into the release. Now the > question is - does the customer really want that level of compatibility > that we are used to provide in Solaris world ? Is there any customer > data to suggest us going this route ? >
I would suggest that there are two communities we're trying to address with this project. One is the community already using Solaris/OpenSolaris, one is the community who may consider using it. The former are the traditional users, largely concerned with stability and prefer nothing ever change (until they want the latest release). In fact, many of them still run Solaris 8. The latter community, which is probably the one we want to address most with this project, is quite clearly telling us we need to be mostly up to date with what the upstream projects are shipping. They understand that Ruby/Rails, PHP and Apache httpd don't come from Sun directly. They don't expect the OpenSolaris project to mask the differences between libfoo 2.4.5 and libfoo 2.5.2. In fact, I'm sure we could find evidence to the contrary, but generally speaking, if this community finds issues between their apps on top of these libs, report it, and we find it's because of a change in the upstream and suggest a change to their app, they'll be satisfied with that answer. Further, they expect that when they install a stack, it all works together, it's a release with reasonably recent features, and it has all of the common modules to run common apps (i.e. Drupal, MediaWiki, etc.). > My point of argument / concern is when other HTTPd distributors have > successfully managed with shipping a single HTTPd distribution, how we > are different ? > Have they? There's a bit of a bifurcation out there from my perspective. On the one hand there are a number of distributors who have multiple major releases that each have a different single version. These releases tend to be used when other software specifies that release. Other distributors may have a primary release that's part of the base OS with network package repositories where one can obtain other 'popular' versions of the software already packaged for the OS. The major difference here is that it is non-trivial to build performant, correct binaries (Apache is fairly well behaved, other parts of the 'stack' aren't) on OpenSolaris. This is sometimes even more complicated with the Studio cc included with Solaris Express Developer Edition, because a web search right now isn't likely to find you the magic incantation you need, or the community that knows what it is-- so people give up and go use something else. Why is that a problem? In my experience with end users, if the version that came with the OS they've installed for one reason or another, they can just download, ./configure, make, make install and have something that works. It's getting better, but generally speaking, that may fail with SNV. (this, by the way, is also why I argue we need to make it easy to share the build process and build flags, in case someone needs to go off down their own trail-- we won't "support" them, but we should make it easy for them to leverage this project's work) Even if it did download/compile straight away, the packaging of the "stack" in the OS is something that is expected by pretty much everyone. > If the same file layout is going to be integrated into Solaris 10 Update > 5, yes I agree that we need to be very conservative. But, right now , > our focus being Indiana and with its release model, does it really > warrant to ship multiple minor releases. > If there's a way to make it not too confusing, I could clearly see how one could want multiple releases installed on the same OS instance. Take for instance multiple zones, one using 2.4 and another using 2.2, and both have a shared /usr from a global zone. Or, perhaps an end user finds through the Indiana network repository they can get version 2.4, so they do and then they want to keep the app running on the system with one version, while they test it with another. > If customers really worry about binary incompatibility with minor > releases of Apache HTTPd , then why Ubuntu or other distributions not > following this convention ? > Personally, I think discussing this with Apache is the wrong area to be focusing on (though I know it's your primary area of concern). The Apache project is likely more stable than some of the other components. It also has had, effectively, one really popular older release, followed by slow adoption of the next major release, followed by steady adoption of the next minor release. If we're to come up with a general solution for the stack (I assume we are, but maybe I'm wrong), we can't have this discussion only around Apache. > Without any customer data to back up this claim one way or the other, my > suggestion is that we take the simplest approach with clearly mentioning > that these binaries are not meant to be compatible between releases. > > Now, again, as I mentioned earlier, if there is enough consensus in the > community to ship multiple releases, then let us do it. Looks like, at > this point, that is where we are heading. > I think I agree with both of these, but with the first paragraph, why are we concerned with whatever definition on forward compatibility *we* put on the software? We need to state we're tracking what the upstream communities are shipping, trying to follow their recommendations and trying to make it easy for users to get the stuff they need. The community around that component defines it's stability/interfaces, and we track what they do. There may be a minority of people who ask us to try to do something else, but I don't think we could possibly consider that in our current scope, right? We need to be approachable though, so we need to make sure whatever layout we end up with is not confusing (personally, I'd argue /usr/apache and /usr/apache2 is confusing, though that's what we have) and, probably more importantly, makes it easy for the end user to start-up a working stack to either develop upon or run a common app upon. Hope that helps, - Matt -- Matt Ingenthron - Web Infrastructure Solutions Architect Sun Microsystems, Inc. - Global Systems Practice http://blogs.sun.com/mingenthron/ email: matt.ingenthron at sun.com Phone: 310-242-6439
