On Fri, Oct 03, 2003 at 02:48:33PM -0400, Bryan J. Smith wrote: > Quoting "Michael K. Johnson" <johnsonm@xxxxxxxxxx>: > > 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 Fedora. 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 visible. Hmm. 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. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/