Hi I understand that we have discussed quite a bit on this topic and what we need is a closure. But, before people can vote and bring this issue of multiple releases to a closure, I would like that we all understand the possible complications that we might be getting into by supporting or providing support for multiple releases of each components in SAMP stack.
Let us say - for nevada build 74, we are shipping Apache 2.2.4 and the appropriate PHP 5.2.3 module for apache. Now, let us assume for Nevada build 90, PHP comes up with a PHP 5.4.2 release . So, at the time of Nevada build 90 release, we will be bundling Apache 2.2.40 and the also the appropriate PHP 5.2.18 and PHP 5.4.2 modules for Apache 2.2 Hmm.. starts getting interested. Now, going further , let us assume - for Nevada build 120, Apache 2.4 is released. Now, at this time, we will need to ship Apache 2.2 , Apache 2.4 and the appropriate PHP 5.2.30, PHP 5.4.10 and even possible PHP 5.6.2 modules for Apache 2.2 and Apache 2.4. If this doesn't sound enough interesting, one can also add the combination of possible multiple releases of MySQL into this equation as well. So the question is - does customer really want this flexibility ? do we have such resources in hand to make a good job of providing this flexibility ? My only fear is - if we do a half hearted job, we risk bringing down the image of OpenSolaris / Indiana. If in case, I am missing something or misunderstood the whole thing, please feel free to correct me. thanks sriram Sriram Natarajan wrote: > 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 > _______________________________________________ > webstack-discuss mailing list > webstack-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/webstack-discuss >
