![]() It’s very easy to say “more engineering time should be spent on X”. So, naturally, I’d expect maintenance of Firefox to get more development attention than the maintenance of Thunderbird. Firefox is the primary, default, supported web browser on Ubuntu. But everyone needs a working browser on their desktop. Let’s face it: most users use hosted web-based email nowadays. However, the reality of the world is that resources are limited, and adding resource in one area means taking resource away from somewhere else. 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. Reminder: I’m not speaking for Canonical or for the Desktop Team here. The Canonical desktop team’s priorities are up to them I hope the community would find this reasonable. So as a mentor I would expect a new volunteer to start with smaller tasks and demonstrate commitment and competence that way first. 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. 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. You’d need to ramp up skills and experience on easier tasks first. However, a warning about volunteering: dealing with the complexities of backporting Thunderbird updates is not something I expect newcomers to be able to competently. This means that one way of getting Thunderbird (deb) updates into 18.04 faster is for someone capable to volunteer to deliver them faster. Our community is open, and any responsibility can be carried by any contributor who demonstrates the required capacity and competence. We invite anybody, from any company, to participate in any aspect of the project. The Ubuntu Code of Conduct (in my opinion a misnomer because it’s also effectively a constitution) says: Anyone can work on this, and capable volunteers would be welcome and appreciated.Īs Ian says, Ubuntu is volunteer-driven. No change in policy is required, unless by policy you mean policy on priorities. ![]() If you want it sped up, what’s needed is more highly skilled and experienced developers with more available time. The delay was in getting the details right technically, and that happened because the task was technically difficult to do. When the relevant leaders (myself, amongst others) were asked for the exception, they promptly approved the request. In Ubuntu there was no issue getting Thunderbird approved to be updated in the same way as Firefox in this case. “Update policy” is ambiguous let’s not conflate technical policy with resource allocation. 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. Compared to the difficulty of backporting a deb, making a snap available to users of all releases at once is easy. A Thunderbird snap is already available and is kept up-to-date. This has a big bearing on my third point below.Īmongst other problems, snaps solve this problem of making the latest of something available in an old release. It takes a disproportionately large amount of time and only particularly skilled and experienced developers can do it right. ![]() Dependencies have to be untangled, and putting newer stuff in has to be deconflicted from existing stuff that is there already. Debs are tightly integrated, but this gets in the way when backporting. The way debs work, doing this “backwards” in an older release without disrupting existing unaffected users on that release is really difficult. 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. It’s really difficult to backport Thunderbird as a deb. I’m just making some observations that I hope will be useful to help frame any discussion about this. Note that I don’t speak for Canonical or for the desktop team. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |