Constructing Red Hat Enterprise Linux 4
In April 2004, Red Hat conducted a global company meeting in Raleigh, North Carolina. The entire company was invited. One of the strongest impressions I took from this meeting was how truly worldwide Red Hat is. It seemed as though there were as many non-US team members as US members. In addition to the US, development is conducted in Australia, Canada, Germany, Czech Republic, UK, Japan, India and Brazil.
Not all development is conducted within the offices of Red Hat. Through the worldwide legions of contributors to Fedora we invite broader participation. We actively contribute and draw from a great diversity of community open-source projects. Again, this substantially broadens the circle of participation. In many ways, this inclusive process makes Red Hat feel like a trusted steward of the community, forming a distribution representing the best and brightest technology. This is a privilege we do not take for granted as we know it needs to be continuously earned every day. This makes both Red Hat Enterprise Linux and Fedora truly distributions “by the people, for the people”.
Red Hat Enterprise Linux v.4 is supported in 15 different languages. These translations are all performed as an integral part of the development cycle. Consequently, the translation process doesn't lag the release or introduce forks in the development trees. We have a team of “translation elves” located in Australia who magically do their work at an opposite phase of the clock from headquarters. This results in a nearly real-time translation that tracks development changes. Additionally, there are many contributors to Fedora who are actively involved in internationalization activities.
There are several ways in which Red Hat has improved upon our development methodology over the course of Red Hat Enterprise Linux v.4's construction. Interestingly, the main theme of these improvements has been to stick to core proven Linux open-source development practices. Although we did subscribe to these practices previously, we paid increased focus this time around to the following:
Upstream—doing all our development in an open community manner. We don't sit on our technology for competitive advantage, only to spring it on the world as late as possible.
Customer/user involvement—through a combination of Fedora and increased “early and often” releasing of beta versions through the development cycle, we are able to get huge volumes of invaluable feedback (both good and bad).
Partner involvement—on-site partner developers have augmented our ability to address features, bugs and incremental testing.
Avoiding feature creep—putting a clamp on the introduction of late-breaking features in order to allow stabilization.
We are all extremely grateful for the steady guiding influences of Donald Fischer who did an outstanding job as overall product manager and release manager. He was at once a diplomat, innovator, book-keeper and go-to guy. Hats off to “the Donald”.
Red Hat is truly a restless place to be. It seems that no sooner have we shipped one release, than we are already behind on the next one. This is due to the fact that in addition to new release development, we also support prior releases for a seven-year interval. So, for example, here's the list of releases concurrently in development now:
Fedora Core 4 (FC4).
Red Hat Enterprise Linux v.2.1 Update 7.
Red Hat Enterprise Linux v.3 Update 5.
Red Hat Enterprise Linux v.4 Update 1.
Red Hat Enterprise Linux v.5.
Numerous new technologies in prerelease stages, targeted at various upstream and internal release delivery vehicles.
Never a dull moment, and we wouldn't have it any other way!
Resources for this article: /article/8204.
Tim Burke is the director of Kernel Development at Red Hat. This team is responsible for the core kernel portion of Red Hat Enterprise Linux and Fedora. Prior to becoming a manager, Tim earned an honest living developing Linux high-available cluster solutions and UNIX kernel technology. When not juggling bugs, features and schedules, he enjoys running, rock climbing, bicycling and paintball.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Home Automation with Raspberry Pi
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development