The debian model of "stable" (release/) + security + backports vs
testing/unstable (/dev) works wonders for the users, but then again every
repository is available for free -backports not being official IIRC. That way,
firefox-3 goes into stable, firefox-3.0.3 -no matter how minor- goe sthrough
security eventually to stable, firefox 3.1 to unstable, and any security fixes
in 3.1 not being corrected in 3.0 (hypotetical, remember) would get backported
to security again. Also, eventually 3.1 gets to backports, linked against the
libraries and packages in backports instead of those in testing.
However I don't know what would be "monetized" from there. Security, and having
then to choose between paying, n-months outdated and insecure release, or
bleeding edge dev/ ? Backports? (that seems logical, but quite a work for
limited benefits and potentially more support problems). New features only get
to testing/unstable and eventually backports nevertheless... So the user again
would have the option of "tested, if somewhat late, firefox 3.1 in stable" or
"upgrade to /dev/ and be aware of the consequences" if really wanted. Then
again, that only works (for the cheap user) if stable is not *too* outdated.
Perhaps just monnetize the commercial support, and not the repos? Or even have
extra commercial packages, as SuSE used to do - flash, proprietary drivers,
adobe reader, etc. were in separate repos, mainly for distribution license
concerns.
Having restricted security repos is a sure way of hindering "domestic" and
"small office" half-serious usage ("production" workstations and servers not to
be updated every 15 days), as most of those users would rather go to a linux
distribution than pay for the repos or support. Me, at least ;). Also, solaris
patches are freely available to be live-upgraded without paying, so that
wouldn't seem so logical.
I'd guess it really depends on the userbase OS pretends to get, vs its
associated costs. Tough decission (good luck ;).
----- Mensaje original ----
> De: Stephen Hahn <[EMAIL PROTECTED]>
> Para: [email protected]
> Enviado: jueves, 30 de octubre, 2008 1:38:09
> Asunto: Re: [indiana-discuss] Updated pkg.opensolaris.org repository URLs
>
> * Guido Berhoerster [2008-10-30 00:18]:
> > * Stephen Hahn [2008-10-30 00:59]:
> > > There will probably be updates to some of the non-OS products, like
> > > NetBeans or OpenOffice. If there's a super-critical bug fix, we might
> > > distribute this by updating release/.
> >
> > Could you elaborate a bit on the update policy of the
> > release-branch, i.e. what constitutes a "super-critical bug fix"
> > and will be available to those without a support contract (e.g. a
> > remotely exploitable hole in the telnet daemon or a vulnerability
> > in Firefox, a data loss bug in OpenOffice)?
>
> 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?
>
> Thanks
> Stephen
>
> * I need to leave for the day, but I'll be back online tomorrow, if not
> tonight.
>
> --
> [EMAIL PROTECTED] http://blogs.sun.com/sch/
> _______________________________________________
> indiana-discuss mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
