This is the third blog of a series in which we will provide some insight into SUSE Linux Enterprise product development. You will get a first-hand overview of SUSE and SLE products: from what the engineering team do to tackle the challenges coming from the increasing pace of open source projects, to dealing with new requirements from our customers, and partners and dealing also with business-related constraints.
How SUSE builds its Enterprise Linux distribution:
Whether you are a long-term SUSE customer, or a new SUSE customer, a SUSE partner, an openSUSE fan or an open source enthusiast, we hope you will find these blogs interesting, helpful and informative.
It would be great if open source projects in general had support for all desired and dreamt-up features immediately. If there were no bugs, and no known security issues, then we could deploy our systems without being concerned about updates or the risk of potential regressions. In fact, software always has bugs and security issues that must be addressed. In addition, new features and functionality are being continuously developed, enhanced and optimised.
As of today, we are supporting two major versions of SUSE Linux Enterprise: SLE 12 (released on Oct 2014) and SLE 15 (released on 16 Jul 2018).
SUSE R&D usually refers to these “Major Versions” as “Code Streams”. Thanks to our “Common Code Base”, we are not only talking about SUSE Linux Enterprise Server, but also the entire SUSE Linux Enterprise Family, which includes SUSE Linux Enterprise Server (SLES), SUSE Linux Enterprise Server for SAP Applications (SLES4SAP), SUSE Linux Enterprise Desktop (SLED) and “its cousin” SUSE Linux Enterprise Workstation Extension (SLEWE), SUSE Linux Enterprise High Availability (SLEHA), SUSE Linux Enterprise High Performance Computing (SLEHPC), SUSE Linux Enterprise Real Time (SLERT), SUSE Linux Enterprise Point of Server (SLEPOS), which is now called SUSE Manager for Retail.
Currently we have two entire “Code Streams” to develop, release and support (up to 13 years) in parallel, which, as you can imagine, require specific processes and engineering to enable them to be released on time.
As for the “Minor Versions” of SLE, we decided (more than 14 years ago) to use a “Service Pack” Model for our SLE releases. The goal is to offer a predictable release cadence allowing our users to plan accordingly for their updates, but also to schedule our release with collections of maintenance updates and new features alike for a given major version. Back in the old days we promised to release a Service Pack every 12 to 18 months, but since SLE 12 GA (more than 5 years ago) we have decided to simplify and increase the regularity of our cadence by settling on a 12-month release cycle and supports previous service packs for 6 months after the release of the new service pack.
Why? Well, this decision was made based on our customers’ and partners’ feedback and also because of the general increase in the cadence of open source development. For example, just to name a few other open source projects, did you know that there is a upstream Linux Kernel minor version every two months, Mozilla is releasing a new Firefox version every 6 weeks, and GNOME creates a full stable release every 6 months?
Having two major SLE versions available with an annual release cadence for every “Minor Version”, which would normally be called a “Service Pack”, is part of our solution to solving the challenge of keeping up with the pace of open source projects, while at the same time offering choice and clarity to all our enterprise users.
We will discuss the SLE Release Schedule in a dedicated blog post, but before getting too technical, we would like to give you a deeper insight into our Release Management Team, i.e. the people and team behind these release processes.
Enter the Release Manager role inside our SUSE Linux Enterprise Team. Of course to cope with the two major SLE versions and their respective Service Packs, there isn’t just one SLE Release Manager but instead a team of release managers. This team is responsible for the successful delivery of our SLE product family & openSUSE Leap (more on openSUSE in a future dedicated blog post), to refine processes and tools and to drive improvement for growing efficiency in the SLE R&D Department.
Naturally they should create a development schedule, which complies to various stakeholders: Product Management for their First Customer Shipment dates, Quality Assurance for giving enough time for internal testing and of course Engineering for the development time!
And since SUSE is truly a distributed and international workforce, Product Management, Quality Assurance, Partner Management and our Engineering teams are scattered around the globe. More than a third of SUSE employees are working from remote locations, but the biggest offices are in Nuremberg (Germany), Prague (Czech Republic), Beijing (China) and Provo (United States). During the planning phase, release managers are making sure that they take into account public holidays and when people are most likely to take vacation to ensure the most optimal release schedule for development submissions and build testing.
Based on multiple factors like the human aspect, reviewed feature requests planned for the upcoming version, specific products needs and of course the experience gathered from many years of SLE releases, the release managers produce a development schedule.
This schedule will always contain some buffers, especially to include additional pre-releases, if the situation requires it. Like 2 years ago when Meltdown was announced and we needed to adapt.
We will not go further into the duties and tasks of the Release Manager, but for now you know that he/she has the responsibility to define the schedule based on multiple constraints, but he/she will also review every code submission in the product, talk extensively with the Quality Assurance Team for each and every pre-release, talk to multiple Technical Project Managers in charge of specific technologies or architecture, and more.
Next, we will talk about past and present SLE schedules.