Hi all, Before the conference call this morning, I wanted to get into an email (and more importantly, a diagram) what has been turning over in my head for the last week or so.
From a developer perspective, what we want is the 'stack' in OpenSolaris to be right for them so they can either adopt it with a new application, a 3rd party application (i.e. joomla) or migrate an application to it. That developer will see that grouping of software as a stack, which a 'distro vendor', in this case: us, has gone and done all of the hard work of assembling and testing. That developer will also expect they can get access to up to date software on a reasonably regular basis. They'll also expect that if they put one stack into production, they can keep it that way for a long time. This is all generally in alignment with SXDE, but lesser in alignment with Solaris 10 and may cause issues when we get in to later Solaris releases. Specifically: ---- SXDE 01/08 ---- SXDE 05/08 ---- SXDE 09/08 ---- SXDE 01/09 ---- Apache 2.2 ---- Apache 2.2 ---- Apache 2.4 ---- Apache 2.4 ---- PHP 5.2.4 ---- PHP 5.2.4 ---- PHP 5.3.1 ---- PHP 5.3.1 ---- MySQL 5.0 ---- MySQL 5.1 ---- MySQL 5.1 ---- MySQL 5.2 The challenge here is if an end user were to adopt the stack that had come with SXDE 01/08, and they want a feature in in SXDE 09/08, how can they get there? Can they, at install time, choose that older stack? Can they add it from a network repository (i.e. does new packaging help here)? For SXDE, we could easily see a scenario where we recommend a wholesale upgrade (i.e. the customer would be responsible for synching up all of their modules from Apache 2.2 -> Apache 2.4, PHP 5.2.4 -> PHP 5.3.1, MySQL 5.0 -> 5.1). This is afterall, the fast moving OpenSolaris SFWNV project. Extend that to when a Solaris release is shipped and things are suddenly different. New hardware frequently requires a new OS update. Usually things are compatible either because they don't change that fast in Solaris, or becuase the 3rd party vendor supports a particular update and forward. Since we've included our stack in the WOS, that isn't any longer practical. This means that user can't adopt new hardware (or other new features) without either breaking the install process and pulling packages from an older release forward (assuming they can be made to work), or they'll have to go off on their own. The new package management may help us here, but only if we plan paths appropriately. Shared components (like readline) may be an issue, since there are other components that may depend upon them in other parts of WOS. Any thoughts? - 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
