Hi All, I believe now would be a really good time for us to create our first stable branch of OpenIndiana, given the timing of some developments within the project.
Below I've outlined my proposal and I'd love feedback from the community and from OI developers! Obviously as a new project with a small (but growing) developer base, providing support for the whole release isn't feasible - there are literally thousands of packages in the distribution. But we have to start somewhere, so I'm proposing we provide limited support (outlined below) for a set of core packages. ******** * Why? * ******** Prior to the Oracle takeover, Solaris 10 was free to use in production, and for a long time, security updates were provided free of charge. OpenSolaris was also free to use, and updates were available by living on the bleeding /dev edge. People were (mostly) happy. Then Sun hit financial difficulties and discontinued free security updates for Solaris 10. Then Oracle happened, ending the free use of Solaris in production. This has left people wishing to use Solaris technologies on their production servers in a difficult position. They have to pay Oracle, or use distributions that don't provide security updates. Or switch to Linux. There are a great many people who would jump at the chance to use Solaris if there were a production ready version with security and bug fixes provided for free. Indeed, this is what people have come to expect from mainstream UNIX platforms - Linux distributions such as Debian, CentOS, Ubuntu, etc, provide updates free of charge - and this is one of the reasons they have become so popular. We have a real opportunity to capitalise on the situation left by Oracle, to capture server market share away from OpenSolaris, Solaris 10, and give users a migration path other than switching to Linux (which a lot of people are doing). There are a lot of people out there who *really really* want a stable build of OpenIndiana - myself included, and I believe OpenIndiana's best chance of gaining acceptance, market share, and building a thriving development community is by capturing the server market. There is also a risk that if we *don't* do this, we'll become an obscure fringe distribution, like DragonflyBSD. The goal here is to be the *mainstream* accepted de-facto Solaris distribution. Something people talk about and seriously consider using. Solaris contains killer technologies not seen on other platforms; technologies like ZFS, Zones, SMF, DTrace, COMSTAR, Crossbow - I couldn't live without any one of these, and we should capitalise on this while we can. It's also worth keeping in mind that despite warning users that oi_147 and oi_148 were development releases, people are already using it in production environments, myself included, due to a lack of alternatives. The great news is that it has proven to be exceedingly reliable, and I have no hesitation in recommending it for busy workloads. All we need to do is add security updates and critical bug fixes on top and we'll be in a great position. No small feat I grant you, but we can start off small and work our way up. Now is also an opportune time to do this - our next release will be based on Illumos, which has seen rapid development and will involve some integration pain. Some have called for a stable branch after Illumos is integrated, but it could be many months until we have an Illumos dev build suitable for respinning as a stable branch. That's months of lost opportunity. So I say we do it now. /dev builds will continue as normal, the next one will be Illumos based - Desktop users can continue to use our /dev builds, and internet facing servers can use the stable branch. ********************* * What we'd provide * ********************* The release would be aimed for February, and titled "2011.02". It would be based on oi_148. We would only provide the Text Installer and Automated Installer ISOs. We would provide security and critical bug fixes only for: 1. OS/Net (The core OS consolidation) 2. A limited set of server oriented packages that have the greatest usage and attack "surface area". The initial list I can think of includes: - OpenSSL - Sendmail - Perl 5.8.4 - Python 2.6 - Ruby - zip, bzip2, gzip - Apache HTTPD 2.2 - PHP 5.X - MySQL 5.X.X - Postgresql 8.4 - Java - Tomcat - GNU Coreutils - GCC - RSync - ISC BIND - Bash - Curl - wget We should also aim to provide security fixes for any bit of software in the repo that allows an easily exploitable remote access vulnerability or root privilege escalation, although we cannot guarantee to do so as monitoring security updates for over 1000 software packages is unfeasible. An example would be the recent Exim vulnerability on CentOS that allowed remote root access by sending appropriately formatted emails. This area is something where we will depend on users, not OI developers, alerting the project to the issue so that a judgement call can be made on whether we have the resources to fix the issue. Security updates would be provided from 6 months of the release date, or until the next stable release is released. Potentially we have the option as a project of providing commercial support past the 6 month date if enterprises desired this. I feel this could be a good way of generating revenue for the project to fund development if there was a market for it. If external contributors were able and willing to commit patches/fixes beyond the supported list, we'd accept them with open arms, and this could be a great way to extend the contributor list and get more people involved. ****************** * How we'd do it * ****************** 1. We do a re-spin of oi_148 fixing any of the major bugs that we can (Eg things like the Broadcom driver issue introduced in oi_148) 2. This gets pushed into pkg.openindiana.org/stable (or /release - tbc) 3. Security fixes and critical bug fixes for the supported packages get pushed into the repo. People doing an image-update would then receive the latest packages. 4. Security fixes and bug fixes would be backports to the version we currently provide. People should be able to update from oi_148 to 2011.02. And people should be able to update from 2011.02 to oi_150. But people should not be able to downgrade from oi_150 or later to 2010.02. This is the same as the situation was with OpenSolaris releases. To make the above easier to manage, one proposal I have is to match the versions of Apache, PHP, MySQL, Tomcat etc to the same versions shipped in RHEL 6/CentOS 6. This way we can monitor their repositories for security updates against these packages, and share the same backports. This will make life a lot easier for us as a project. The main thing will then be doing rebuilds of the packages involved. I would suggest we keep a set of Zones on infra01.uk.openindiana.org around for doing this, so that doing a rebuild is very easy to do, and well documented. Just a case of logging in, patching the appropriate files, running a build, pushing to a test repo, testing it, and then pushing into the public repo. ********************** * Concluding Remarks * ********************** I believe this is a great opportunity for us and I think it's the right time to do it. Although we're starting on the server only front, there's no reason why we can't at a later date add support for the desktop if sufficient contributors are able to make it happen. I'm confident that with a stable branch, we can really increase our userbase on servers, which will bring commercial opportunities from the enterprise, and accelerate development of our favourite operating system :-) Looking forward to feedback! Cheers, Alasdair. _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
