* Stephen Hahn <[EMAIL PROTECTED]> [2008-10-30 01:37]: > Good question. First off, any fix will be available at zero cost in > dev/ (but accompanied by other change) or at non-zero cost in the > support/ repositories on pkg.sun.com. The boundary around my made-up > term of "super-critical" is still fuzzy; the team that has > historically managed the production of patches is still examining what > they can do with image packaging that they couldn't easily do with > patches (and vice-versa, I suppose). It would probably be helpful to > get more examples, and what people's expectations around either > outcome for that example would be. > > For instance, if there were a data loss bug in OpenOffice, and > OpenOffice issued a 3.0.3 release, I would expect that to be in > release/ eventually. If "eventually" meant by the next release of > OpenSolaris which of your computing uses for 2008.11 would become > unjustifiable? If it instead meant within 7 days of the version > availability, how would that set of uses change? Another option--that > you could choose to send to Glynn or me privately--is to identify what > should be different about a support/ repository at some price versus > what's available at zero cost... > > Thoughts on your telnet or Firefox or other examples, in contrast to > OpenOffice?
Disclaimer: I am a student with no budget, I have used FreeBSD for several years and am currently mostly a Linux user. My definition of critical bugs includes those which are security relevant or lead to data corruptioni. Taking your "super critical bugs" category into account I would distinguish four categories of updates: "super critical bugfixes", critical bugfix updates, non-critical bugfix updates, and support updates. Here are some more examples for possible bugs/issues sorted into above mentioned categories: "super critical bugs": * a remotely exploitable bug in the SSH daemon critical bugs: * security issue in Firefox * ZFS data corruption * OpenOffice corrupting documents non-critical bugs: * a functionality bug in the JDK * Firefox font display issues support issues: * a customer escalating a minor bug in the DHCP daemon * a customer requesting a backport of a new major Firefox release from the dev/ branch Based on that I can imagine three different scenarios: Scenario 1: * release/ getting only "super-critical" fixes between releases * support/ receiving everything else Scenario 2: * release/ receiving all critical fixes in a timely manner between releases * support/ receiving non-critical fixes and support updates Scenario 3: * release/ receiving all critical fixes in a timely manner between releases * an additional, freely accessible updates/ repository providing non-critical fixes * support/ only for requested custom fixes and backports Scenario 1 resembles the old SXDE model and what we currently have but with the option of a support contract. If for example an OpenOffice data corruption bug were found, a user could either upgrade to dev/ and put up with potential regressions and new bugs, hope for the best and wait for a new release or buy a support contract. IMHO this scenario would be an impediment to a wider adoption of OpenSolaris in a non-corporate environment (students, hackers, independent webdevelopers), especially among current Linux users as it is inferior to what current Linux distributions offer for free, think Ubuntu, OpenSUSE, CentOS, Fedora. This might however provide strongest incentives to buy a support contract for those who are willing or able to pay and might generate the biggest revenue in the short term. Scenario 3 is pretty much like Ubuntu where all bugfixes are free and only support costs money. This will probably support building the largest possible userbase, incentives for current Linux users are an update policy comparable to Linux distributions and the additional benefit of features only available on Opensolaris such as DTrace, ZFS, IPS etc. Such a model might generate lower revenue in the short term but provide more long term benefits, e.g. student users might become decision-makers in companies, hackers might become kernel developers or package maintainers, a larger userbase means better testing of future Solaris releases etc. Scenario 2 seems to be a compromise between Scenario 1 and 3, receiving only critical bugfixes for free is comparable to certain Linux distributions like Debian or CentOS and could help to enlarge the current userbase while compared to Scenario 3 additional incentives for buying a support contract are retained. Speaking for myself, I have toyed with SXDE since it became available and I have followed Project Indiana from the beginning, however I do not use it as my main OS because the costs of the instability when using the development version and the lack of critical bugfixes for the 2008.05 release outweigh the benefits for me. I'm not willing to spend money on a support contract (even if I had the money) as I don't need commercial support. Scenario 2 or 3 are what I expected when Project Indiana started and would likely make me switch. I could imagine that non-corporate users might think similarly and not be willing to wait for a new OpenSolaris release until a recently discovered data-loss bug in OpenOffice or a security hole in Firefox is fixed. It all boils down to what Sun's revenue model and strategy for OpenSolaris is (broadening user base, aiming at long term benefits vs. generating revenue in the short-term, see above) and who its target audience is, both is not entirely clear to me. -- Guido Berhoerster _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
