Been biting my tongue on this, but here goes ... Virtually a decade ago, I had a discussion with Alan Cox about betas, releases and other considerations. From then on, as I watched Red Hat, I knew the maintainers were first-hand, not second-hand, on most upstream projects, they know the code quality, they knew the code base, they knew the details I did not. I learned when a shift was made, it was for many reasons, a balance -- code, customers and supportability.
It's happened on core details -- kernel, GCC, GLibC -- as well as other projects. Red Hat is first-hand upstream. Red Hat is customer focused. Red Hat takes the 7+ years of supportability with a committment unlike I have ever seen in any other Linux vendor over the past decade. I've seen some complaints over that time, yet so few who look back and look at the wisdom of Red Hat's moves. Ironically, the biggest complaints turned out to be the greatest moves for the entire Linux community. In fact, many of us had a very recent, good chuckle on another vendor's announcement because it's clear that most of the complaints about Red Hat come down to one thing. The reality of how much Red Hat does upstream, outside of the product, and those other vendors' entire lifecycle at the mercy of Red Hat's continued leadership. GLibC 2 (while still supporting LibC 5 for some time in the previous product). Moving to EGCS, skipping all the GCC 2.8 releases and 2.9 betas, but finally forcing ANSI C++ compliance (while still supporting EGCS for some time in the both the previous and current product, including EGCS on the kernel, instead of the the 2.95 series, which had its issues too) Skipping GCC/LibStdC++ 3.3, backporting to 3.2 and moving forward with 3.4. Skipping Firefox 2.0 (and yes, shipping a 3.0 Beta in an Update). Countless decisions that were easily criticized, yet made every sense if you talked to the maintainers. Heck, Bugzilla entries are often all that are needed. Even when they are embargoed at the time, reading them later, after the embargo has been removed, provides enlightenment. I stopped third and second guessing long ago. I starting talking to those who are first hand. I starting seeing the whys and hows. There's a reason why Red Hat has an ABI compatibility in the Linux world second to none. There's a reason why integration and regression issues, why they still happen from time-to-time, happen far less in Red Hat releases. I staked my professional reputation on Red Hat Enterprise Linux from Day 1 of its release. So I stopped to ask Red Hat. Whether it was askking my sales person for lifecycle and help with planning my integrations, or it was contacting a maintainer for why moves were made or what movers were coming up, I asked. When the release 6 Beta first came out, some people on this were surprised. But many others were not. The same will happen with the release 6 general availability. ;) I know some of you are in non-profits and other areas. But you'd be surprised the type of answers you would receive if you would reach out to Red Hat representatives. I have been assisted by a lot of great people in Red Hat over the past decade, which made all of the difference in not only my professional endeavors, but my professional name. I cannot stress enough how much this is about community. I.e., if you're looking for official dates on a web site because your supervisor requires such, then I don't know what to tell you. But if you explain the model, how Red Hat has -- time and time again -- delivered both upstream and in product, then you should know what to expect. It's important that experienced customers and community relay this to those who are not familiar with Red Hat -- or worse yet -- make assumptions and define Red Hat in ways that it is not. ----- Original Message ---- From: Chris Adams <cmad...@hiwaay.net> Yes, I do understand that. But then I look at the differences between beta1 and beta2 and see some significant version changes (such as Dovecot jumping from 1.2.9 to 2.0beta8 - a beta version in RHEL?), which should not be happening after a beta release. That indicates to me poor project management and the possibility of an even more delayed release (which may cause additional packages to get upgrades, causing more delays, etc.), or a rushed release that is not stable. Now, I'd much prefer to see Dovecot 2.0 in a long-term release like RHEL, but a change like that should have been made before the first beta. What I heard originally was that RHEL 6 was going to be based on Fedora 12, which was released almost a year ago. When the first RHEL 6 beta was released, there were a fair number of packages that looked to be based on Fedora 13 instead, which indicates much less testing time (and throwing away some of the Fedora-based testing, since the package mix was changed). The second beta upgraded some packages to newer versions that appear to be based on the Fedora 14 development tree (F14 will reach beta next week). -- Bryan J Smith Professional, Technical Annoyance ------------------------------------------------------------ "Now if you own an automatic ... sell it! You are totally missing out on the coolest part of driving" -- Johnny O'Connell _______________________________________________ rhelv6-beta-list mailing list rhelv6-beta-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv6-beta-list
