I can’t directly answer the question, but I would like to clarify a few things to make sure that there’s no misunderstanding or mismatched expectations here. Note that I don’t speak for Canonical or for the desktop team. I’m just making some observations that I hope will be useful to help frame any discussion about this.
1. It’s really difficult to backport Thunderbird as a deb.
This particular backport involved backporting a newer nasm and Rust toolchain, dealing with the deprecations of jsunit and enigmail, handling upgrade paths for these, and so forth. The way debs work, doing this “backwards” in an older release without disrupting existing unaffected users on that release is really difficult. Debs are tightly integrated, but this gets in the way when backporting. Dependencies have to be untangled, and putting newer stuff in has to be deconflicted from existing stuff that is there already. It takes a disproportionately large amount of time and only particularly skilled and experienced developers can do it right. This has a big bearing on my third point below.
Amongst other problems, snaps solve this problem of making the latest of something available in an old release. A Thunderbird snap is already available and is kept up-to-date. Compared to the difficulty of backporting a deb, making a snap available to users of all releases at once is easy. If users don’t want to use it, that’s up to them; my point is that what you’re asking for is essentially asking developers to do much more work.
2. “Update policy” is ambiguous; let’s not conflate technical policy with resource allocation.
In Ubuntu there was no issue getting Thunderbird approved to be updated in the same way as Firefox in this case. When the relevant leaders (myself, amongst others) were asked for the exception, they promptly approved the request. The delay was in getting the details right technically, and that happened because the task was technically difficult to do. If you want it sped up, what’s needed is more highly skilled and experienced developers with more available time. No change in policy is required, unless by policy you mean policy on priorities.
3. Anyone can work on this, and capable volunteers would be welcome and appreciated.
As Ian says, Ubuntu is volunteer-driven. The Ubuntu Code of Conduct (in my opinion a misnomer because it’s also effectively a constitution) says:
We invite anybody, from any company, to participate in any aspect of the project. Our community is open, and any responsibility can be carried by any contributor who demonstrates the required capacity and competence.
This means that one way of getting Thunderbird (deb) updates into 18.04 faster is for someone capable to volunteer to deliver them faster.
However, a warning about volunteering: dealing with the complexities of backporting Thunderbird updates is not something I expect newcomers to be able to competently. You’d need to ramp up skills and experience on easier tasks first. That’s a big ask for any volunteer. And from the other side, I don’t expect experienced developers to be prepared to spend their time helping you along diving in to something so complex if you’ve not already got a track record that demonstrates your competence. In my experience, having a new volunteer dive in to something like this never ends well, and only consumes significantly more mentoring time than it would take for the mentor to do it themselves multiple times over. So as a mentor I would expect a new volunteer to start with smaller tasks and demonstrate commitment and competence that way first. I hope the community would find this reasonable.
4. The Canonical desktop team’s priorities are up to them
Reminder: I’m not speaking for Canonical or for the Desktop Team here.
In practice, a lot of the “grunt work” in maintaining a distribution is something that is difficult to find volunteers to do, and this is where Canonical comes in. However, the reality of the world is that resources are limited, and adding resource in one area means taking resource away from somewhere else. Let’s face it: most users use hosted web-based email nowadays. But everyone needs a working browser on their desktop. Firefox is the primary, default, supported web browser on Ubuntu. So, naturally, I’d expect maintenance of Firefox to get more development attention than the maintenance of Thunderbird.
It’s very easy to say “more engineering time should be spent on X”. But only the team responsible, or those funding them, are in a position to be able to determine what they have the capacity to do, and how they arrange their priorities.
(these are the conclusions of my framing of this discussion, not of the discussion itself)
It’s perfectly valid to ask the Canonical desktop team to adjust their priorities. My point, though is that this is what your request comes down to: you’d like the Canonical desktop team to do more of these updates quicker. There’s no other kind of policy adjustment or other type of change relevant here. It’s purely a question of engineering priority. However, this request has to be balanced with:
- Many (most?) Ubuntu users use hosted web-based email and not Thunderbird nowadays.
- As an upstream, Thunderbird don’t maintain stable releases, like Firefox and Chromium but unlike most other software in our ecosystem, which makes backporting Thunderbird to stable releases particularly difficult.
- A promptly updated snap is available, because that’s much easier to do.
- 18.04 isn’t the latest LTS.
- The desktop team clearly has other priorities, too.
Finally, my subjective opinion: it seems to me that in this new world of some upstreams not supporting stable releases but instead shipping rolling releases with regular new dependency requirements, backporting for the life of the LTS is becoming increasingly impractical. For these particular upstreams, we’ll have to resort to the bundling of dependencies in the end. Debs are simply not designed for that; it’s like trying fit a square peg in a round hole. Sooner or later, it’s going to become too impractical to continue this way. What we need is a packaging format that allows the bundling of dependencies. And we have that: snaps. Meanwhile, volunteers who are prepared to suffer the pain to deliver deb backports will be able to continue to do so. In practice, we’ve found that nobody volunteers.
 This isn’t necessarily Ubuntu-specific; an experienced uploading Debian Developer would also be capable.