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. 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??? <soap box> I know the industry has this "dot-fobia" right now, but I like it _much_better_ than the whole "service pack" nomenclature. But tag it as you will. ;-ppp </soap box> > There are lots of changes. I think the more interesting questions > would probably be what *hasn't* changed. Yes, NPTL is in. 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. > If I tried to present the new features here I'd miss lots of them, > even in my area of the kernel. Understood. I think NPTL says a lot. > I know that our sales force has the capability to talk about the > features that have been added. As always. ;-ppp 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. > We're not going to avoid deploying new technology in Fedora just > because you want to be able to build Fedora packages on RHEL. :-) No more than you have done with Rawhide in the past, I know. But if I was Red Hat management, I'd have to believe that by seeing 3rd party packages built to my commercial product, I'd sell more commercial product. But they know Which brings me to the culmination of a point I wanted to bring up before. 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 I'm not trying to tell Red Hat what to do. After all, unlike Debian, you have to support what you ship. So that means you're limited in what you can ship. But I think #1 might be in its best interest, from a commercial perspective, to provide a framework for this, to help sell your own RHEL products. Because the problem with #2 is why people prefer Debian, and might not move to Fedora en masse. #2 still means there is no community built around RHEL, which means there is less incentive for the regular user to purchase it (or worse, purchase SuSE Linux Personal/Professional instead). If Red Hat does not consider this a market consideration, then I'd understand (and I'm _not_ deamonizing Red Hat here). But I think other people have hit on it. There needs to be a new "consumer" between the new Fedora "enthusiast" and the RHEL "business" products. So I've suggested that Red Hat consider help supporting a "tag" in Fedora, even if it is a subset, of popular packages for its current RHEL release. That would help Red Hat sell more RHEL WS/ES boxes. I leave it up to Red Hat to decide if the costs of doing such are worth the potential increase in sales of RHEL WS/ES. > If you look historically, the changes have tended to be small and > manageable most of the time. Right. As long as GLibC/GCC doesn't change, most things are accomodated. And given that RHEL release are supposed to be 18 months apart, this is basically what we had with the 3 x 6 month model of X.0 - X.2+. > But let's take a concrete example of a major change. Let's say, for > example, that RPM was changed so that you didn't have to list patches > in one place any apply them in another; that you could say something > like > %patch(foo-1.0-fixblah.patch) -p1 > in the prep section, and RPM wouldn't need a separate > Patch0 foo=1.0-fixblah.patch > line to know that the foo-1.0-fixblah.patch file existed and should > be packaged. > We wouldn't wait until a version of RHEL had that capability to start > to use in in Fedora packages. If you wanted to rebuild the modified > packages, you'd have to modify the spec files. And I understand that. But I also see that preventing people from buying RHEL, because it is no different than what they had before. Now Red Hat could choose to hope that another party picks up that end, or the Fedora community themselves. But given why Fedora now exists, I want to believe Red Hat might consider "unofficially" (i.e. unsupported) maintaining its own "tag sub-set" of the Fedora repositories that easily build on their current version of RHEL. Do you see where I'm coming from, just a recommendation? > fedora-devel-list is where we'll be talking about any such changes. FYI, I promise to avoid posting discussions like the above, unless I'm directly supporting a package myself (not likely anytime soon -- as I'm too busy "cert whoring" until probably mid next year, long story ;-). > 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. > It might work on a technical basis, opportunisticaily, though if > you replace RHEL3 apps with hand-built ones you'll want to check > your SLA wording to see what it does to your support level. The idea here is to _not_ replace anything that RHEL ships. Only _augment_ what is in it. That would make SLA a nightmare for Red Hat, and be self- hindering to support such an effort. Which is why I'm calling it a "tag subset." So if that means you can't run the latest GNOME, or a GNOME app that requires the latest GNOME, that's totally understandable. I think I made that known in the other post. -- Bryan J. Smith, E.I. mailto:b.j.smith@xxxxxxxx http://thebs.org ------------------------------------------------------------------ There is no greater ignorance than the popular American environ- mental movement, which focuses on the most useless details. Be it recycling the world's most renewable resource or refusal to use proven CFC insulation on launch vehicles, no lives will be spared in the further pursuit of, ironically, harming the environment.
