Hey there, fellow and future Ubuntu contributors! The Stable Release Update (SRU) process functions effectively and smoothly for me and the entire Server team. We manage numerous uploads, including significant changes by backporting minor releases under additional limitations, without issues. Maybe because of that I often found myself explaining why certain arguments mean nothing - and should mean nothing - to the Ubuntu SRU team. Since I probably explain it too often, let me share some of the philosophies behind the SRU process that I would love to be more widely known. Hopefully this will help you (when submitting an SRU) and the SRU team (when reviewing your SRU) alike.
Disclaimer: I have significant familiarity with the SRU process, though I am not directly a member of the team. This perspective, therefore, comes from a well-informed external viewpoint.
1. The SRU Mindset: S for “Stable”
One common misconception is that the SRU team’s role is to help you fix your problem. In fact, their role is to ensure that the update you propose is not going to regress anyone.
Imagine a group of folks who are more aligned with cosmic stability than with earthly deadlines. That’s the SRU team! They exist to ensure our beloved Ubuntu stays rock-solid throughout updates. The stability of Ubuntu leads to fewer headaches for everyone, and is one reason we are so trusted. Imagine if we didn’t have an SRU team to check for regressions - every “just this one little change, pretty please” would have the capability of destabilizing the ecosystem as a whole.
The SRU team’s principles didn’t change in the decade I’ve been more deeply involved - you can find more about their underlying principles.
2. The SRU Mindset: R for “Release"
Another common misconception is that the SRU team acts as a personal upload service. Actually, releasing and reviewing changes is what they do. Although they have the power to shepherd uploads through, the reality is that there simply aren’t enough of them to fulfill this function.
It also happens that this is a classic four-eyes-principle; the more experienced eyes we can get on something, the more likely it is that regressions will be caught in time. This is why there needs to be an experienced enough developer sponsoring the upload, and then for it to be independently reviewed and processed by the SRU team.
The SRU team themselves live by this principle! Uploads done by an SRU team member are SRU-processed by a different SRU team member. Look for the patch pilot program if you need help to be sponsored.
If you are now curious - the team has written up in detail what is expected of the different roles.
3. The SRU Mindset: U for “Ubuntu"
The SRU team’s power and mission is delegated by the Ubuntu project – not Canonical, nor any other company.
Picture this scenario: You burst into the (non-existent) SRU headquarters and declare, “I need to get this SRU through! I have a contract deadline!”
The SRU team will politely nod… and then continue their stability-focused review of the upload queue. Why? Because a single update can affect millions of users, they cannot rush an SRU through just because your contract deadline is breathing down your neck.
The best way to avoid such pressure cooker situations is to ensure you thoroughly and methodically prepare your changes in a timely manner. Trying to exert pressure will not accelerate the process.
4. But… Why all the rules?
You might be thinking, “Why all the rules and constraints? It seems like a bit much.”
Well, imagine you’re renovating a house. You wouldn’t just exchange components randomly, would you? No, you’d have a blueprint, safety codes, and inspections. The same goes for Ubuntu SRUs. The rules are there to make sure the house (your operating system) doesn’t fall down.
Each rule has a purpose: preventing regressions, ensuring quality, and maintaining long-term stability.
The team has nicely written up the reasoning for the rules. If you are in doubt, or just want to learn more about why the rules are the way they are, I recommend having a look:
- Why to aim for “Minimal changes”
- Why it needs “Real world impact”
- Why the Process should be public
- Why the need for detailed test plans
- Why we fix interim releases
5. Does that mean I can do nothing?
Oh no - you can!
Let’s be honest, I hear a lot of complaints from those who have been frustrated at their SRU being rejected or delayed. But for myself, my team and over the many years I’ve seen: If you align to the underlying principles, the SRU process is a smooth ride.
We had the benefit of having an SRU member be the core of the team that we built up, so the SRU philosophy bled into all our processes and the mindset we have. I truly believe that we think better of the SRU process because we rarely ask for things that are unacceptable, and even if we do, we would provide the arguments and confidence that is needed.
But that approach isn’t limited to a chosen few. Everyone can create a well-prepared SRU which will get accepted easily. I’ve seen many other Ubuntu contributors learn the rules and adapt - and since then, they have a good time. Let me add a shout out to Support Engineering which, to my perception, have done great in that regard over the last decade. To do the same, you need to understand the SRU team’s principles and prepare your change in a way that makes it likely to be acceptable. Skipping the painful back and forth not only resolves your case more quickly - it also helps everyone else, because the SRU team will be able to handle your case more efficiently and thereby also be able to move to the next case faster.
Andreas gave a nice talk about how to prepare the perfect SRU in the Ubuntu summit 2023 in Riga. It is actually the opposite - a nice set of stories that show what can go wrong, and that you want to avoid repeating. I recommend making this mandatory education for you and your team before starting to contribute SRUs.
Let’s keep Ubuntu stable and fun at the same time!
Happy coding and enjoy your day, everyone!