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

Re: Fedora and the System Administrator -- I'm probably distracting people here, but ...

On Fri, Oct 03, 2003 at 02:48:33PM -0400, Bryan J. Smith wrote:
> Quoting "Michael K. Johnson" <johnsonm redhat com>:
> > First of all: It did not jump to "3.0".  There's no ".0" in it.  Just
> > "Red Hat Enterprise Linux 3" with no decimal or decimal-ish part.
> My ignorance, my apologies.

No problem, just passing on the message.  It's more than just a random
change, though; it's actually indicative of what we're doing, and you
picked up on that fact further down.

> So from a product marketing standpoint, it is just "3".  Will Red Hat maintain 
> an internal/technical designation for revisions at least?  E.g., 3.x???

We do have updates, but the product version doesn't change.  We
refer to update levels internally and externally.

> Okay, that would explain the move to 3.  I just miss those "good old days" when 
> I could could on the major version to stick with the same GLibC/GCC.  I guess 
> that's what we now have in a single 18 month RHEL release, instead of 3 x 6 
> month RHL releases.

Exactly.  What we're really doing is catering to the way that people
who wanted long cycles wanted to use the product in the first place.
You get a few syncronized updates per year, plus security errata,
with a syncronized longer-lifetime platform.  When we had people using,
say, RHL 6.0, RHL 6.1, and RHL 6.2 all with the same gcc and glibc
major version, we had to spread update engineering and QA time over
three platforms with the same technology.  Now, with a single platform
per technology set with consistent updates, we can focus our work and
provide higher-quality results.

> At least you don't send out your sales people and have them tell people that 
> they are "engineers."  That's the #1 reason why even MCSEs dislike Microsoft.

Well, we actually *do* have engineers in our sales group, called "sales
engineers", to whom technical questions can be referred, and who can ask
other engineers when they don't have the answer.  But I don't think that
is what you are talking about.  :-)

> Does Red Hat see either ...
>   1)  Two tags in Fedora -- one for Fedora, one [subset] for RHEL, or
>   2)  Expecting community software projects to release a RHEL version 
> themselves, all while working with Fedora to release one for Fedora

We're not going to explicitly maintain a Fedora Core release that is
compatible with some RHEL version.  We're generally expecting that
community software projects will be most interested in working with

I recognize that this doesn't really answer your question.  I'm
wondering how much of an issue this is; how much we'll see community
projects deployed on RHEL.  It hasn't been a big issue so far; we
haven't been explicitly maintaining compatibility between RHL and
RHEL products in the past and I just haven't been seeing it as a
big issue.

I think we concentrate on this: if it's a community project, we're
thinking open source, and people deploying it outside of the context
of installing a distribution seem to be building from source more
than installing random binaries, and for well-built products, it
really should just build wherever...

> Do you see where I'm coming from, just a recommendation?

Yes, I understand the recommendation.

> > And it's simply not a promise we're making.
> Oh, I guess I should clarify.  I'm not expecting Red Hat promise such.  It's 
> not feasible for Red Hat to do so.
> If there is one thing I _know_ of Red Hat, they make small promises and deliver 
> _more_ than most people expect.  So that's all I'm hoping for here.

I'm glad that our desire to under-promise and over-deliver is


What you really need isn't a distribution, it's a buildroot.  Something
you can chroot into to build packages that would work in that distribution.
No point in having separate OS installations for every case.


 "He that composes himself is wiser than he that composes a book."
 Linux Application Development                     -- Ben Franklin

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