[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Graphical boot isn't so graphical

On Wed, Jul 23, 2003 at 10:08:35PM -0400, Joe Smith wrote: 
> I sincerely hope that "not fully productized" is not marketing-speak for 
> "let us know if this happens to work".

What I mean by that are goals such as "100% translation guaranteed
into 10 languages," "all applications are fully keyboard navigable,"
"all online help is verified accurate and translated," and this type
of thing.

Some tasks like that a) get linearly more expensive as you add more
packages and b) take a long time, including a long feature
freeze. Thus they are kind of in conflict with the 6-month release
cycle and the desire to offer more packages. There's a tradeoff there.

Now it may well be that when we put an upstream package into RHL that
it will already be 100% keyboard navigable and 100% translated. We
won't break it. And we won't stop work people want to do on these
goals in RHL. The point is just that there's not a long enough freeze
or enough resources to verify/ensure these kinds of goals on the
distribution level, especially once we pile in a lot more packages.

Training/support also fall into this category, as the support
liability and ability to ramp up training/support staff/materials are
affected by package count and release frequency.

Consider errata; with RHL if we had gone to 5 years errata, that would
be 10 releases live at the same time, and with a large number of
packages; a crushing quantity of work. With RHEL, 5 years support is
conceivable due to longer release cycle and smaller package set.

> If I choose to install something off of freshrpms, I don't feel bad if 
> it ain't quite there yet.  I need some reasonable level of functionality 
> in a distribution (or at least some way to distinguish core/dependable 
> from alpha/experimental).  Missing features is one thing; stuff that 
> just doesn't work is another.  I like to choose where I waste my time ;-)
> Surely you wouldn't intentionally dilute the quality of the free (beer) 
> edition just to pump up the value of the 'enterprise' editions?  Well, I 
>   can't say I'd blame you if you did.  Good QA is worth real $$.

The idea is that RHL vs. RHEL is about different
audiences/goals/tradeoffs rather than better/worse. RHL is definitely
intended to be a useful distribution, not a rolling beta, or

Our now-fully-open technical forums should give people good visibility
into how RHL is engineered. If we succeed in building a contributor
community, any contributor will be able to put in bugfixes and we
won't even have the ability to dilute quality if we wanted to.

I do believe in the RHL project, if I didn't I wouldn't be answering
email at 11pm. ;-)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]