Matt thanks for such a nice response. Very informative for every one. You have raised very valid point - this issue of shipping multiple revisions is not just for apache - though it is the focal point in this mail thread. What customers typically want , as you rightly pointed out, a well integrated working SAMP stack. Now, to provide this well integrated SAMP stack, I believe we can do a better job only if we ship a single revision of each components.
Fortunately, with respect to SAMP stack, most of the components has matured over a period of time making us wonder as to why we need to ship multiple revisions. Now, if we had to bundle a component which is very evolving at a rapid pace, then definitely we won't be having this discussion. Please see my response inline for the rest. thanks sriram Matt Ingenthron wrote: > 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.). > Very true. >> 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. > > I am sure, with Indiana, we should be able to provide a similar solution. > 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. > > Going forward, after build 74, with sfw build repository being available ( as a tar ball from sfw-nv community) for download , customers should be able to easily build a specific version of Apache HTTPd. IMO, that is a step in the right direction. >> 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. > > Hmm.. is this a majority community ? that sounds like a great nice to have feature? But to accommodate this , we will need to add version information every where (/etc/apache2/2.2 , /usr/apache/2.2, /var/apache2/2.2 , /var/svc/manifest/network/http/apache22) making our distribution more confusing Instead, if a customer who is interested in 2.4 but not interested in upgrading to a newer version of Indiana release, can download the sfw-nv or webstack source containing Apache 2.4 build it and test it on his zone before deciding to upgrade the system. Yes, I agree - we need to make our SAMP stack more easily buildable at a customer site. If we address that problem, we don't have to get into the trouble of bundling multiple revisions of every components within SAMP stack. >> 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. > > +1 >> 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. > +1. I guess, hopefully we get a consensus one way or the other so that we can close this and move toward implementation. > 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. > > If we are allowd to start fresh, I would simply start with /usr/httpd and be done with /usr/apache and /usr/apache2 . But, that would be a very very big change and would only delay our integration into Nevada thanks sriram
