Brown: Fixing a 6-year-old bug in Ubuntu MATE and Xubuntu
Doug Brown documents
the long journey to fixing a bug in the GDebi utility for
installing Debian packages. He first encountered the bug in
Ubuntu MATE 18.04: "at the time I just ignored this
issue. I didn't want to deal with it. I went off to the trusty Linux
terminal and installed Chrome that way instead
".
Two and a half years ago, I committed to doing more open-source contributions in my free time and was finally irritated enough about this problem to look into it. I searched around for more info. Lo and behold, lots of people were also affected and there was already an issue from 2019 on Ubuntu's bug tracker about it.
[...] As is commonly the case in software development, the difficult part of this fix had nothing to do with the code itself. All of my effort was spent figuring out Ubuntu's patch submission processes and advocating for my merge request. Nobody else seemed to be interested in doing the work to actually fix this bug that has been plaguing Ubuntu MATE and Xubuntu, not to mention some Debian users, for over 6 years. After dealing with the long process of getting my merge request approved, I think I'm starting to understand why!
Brown notes that the fix is now packaged for the upcoming Ubuntu 24.10 release, and should be backported to 22.04 and 24.04 eventually.
Posted Jul 10, 2024 19:18 UTC (Wed)
by jond (subscriber, #37669)
[Link] (9 responses)
Posted Jul 10, 2024 19:52 UTC (Wed)
by arraybolt3 (guest, #168272)
[Link] (8 responses)
Posted Jul 11, 2024 12:57 UTC (Thu)
by HenrikH (subscriber, #31152)
[Link] (7 responses)
Case in point: I noticed a performance overhead in curl when it was using OpenSSL and the reason was in OpenSSL. So I crafted a patch and submitted it to OpenSSL, but for the patch to be accepted I now suddenly had to document not only my own new option but all existing options (aka oops these features are undocumented so lets force the new guy to do all the work), ok that was no fun but doable so I did that, then came the next blocker and that was that I now had to write a regression test case and here was the blocker for me because I cannot even begin to understand how the tests in OpenSSL works because they are not written purely in C but uses lots of macro and bash magic (or something, I simply cannot understand it) and to make matters worse the very people that knew how to do this was the ones demanding that it had to be done.
So that patch have been in limbo now for over 2 years. Later I discovered that the very feature I tried to implement had already been attempted to patched several years earlier and it also died for similar reasons.
In a wonderful world we would have expert documentation writers writing the documents, expert coders writing the code and expert QA writing the regression tests, instead every single contributor have to fulfill this entire range of expertise or a fully functional patch will just bitrot for eternity.
Posted Jul 11, 2024 15:03 UTC (Thu)
by WolfWings (subscriber, #56790)
[Link] (1 responses)
Posted Jul 11, 2024 17:53 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
But contributors do need to be aware that "no" is a valid answer. Here are some of the more reasonable "no"s I can think of:
* "No, because it's easier for me to carry the patch myself rather than do all the work you're asking for."
In an ideal world, contributors would avoid saying "no, because I don't feel like it," but ultimately everyone does have the right to decide what to spend their time on. Professional FOSS can be a bit of a mixed bag, because most tech companies do actually want testing etc. to get done, they just don't want to do it themselves. It's a fairly standard free-rider problem. Assuming we don't want government regulation (requiring tech companies to contribute headcount to FOSS they use), the next best option is probably a professional organization that hires developers for the good of the project, and is voluntarily supported by tech companies that rely on it. But you can really only do that for huge projects. We need a better solution for the small projects (better than "some person in Nebraska," at least).
Posted Jul 11, 2024 21:06 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (4 responses)
That's utterly unacceptable, you should have said "good bye" at that point and that you were looking for some SSL alternative. Whether that's true or not; it's about sending a message :-)
We keep hearing about the "poor, underfunded yet critical open-source projects" and about https://xkcd.com/2347/ but there's clearly blame all around: if submitting even a small, drive-by patch is an ordeal then don't come and complain.
At $BIGCORP there are more or more guidelines on how to carefully select open-source dependencies (a Good Thing) and one of them is "well maintained" project. This is not an exact science and hard to define but this would clearly fail that test.
When trying some new open-source project, I always "race" to find some documentation or minor bug in order to submit something small ASAP. This is with the very clear intention of testing the submission process.
Note I'm only referring to that unacceptable request to document _unrelated_ options. Testing is a more complex and more nuanced issue: you do want new changes to have decent test coverage and as an industry we need to fix our "test-free" culture.
> because I cannot even begin to understand how the tests in OpenSSL works because they are not written purely in C but uses lots of macro and bash magic (or something, I simply cannot understand it) and to make matters worse the very people that knew how to do this was the ones demanding that it had to be done.
This one is less a matter of resources and more about priorities. Test code and test frameworks should be treated as almost equal to "product" code. Being short on time and resources is constantly used as an excuse to cut validation corners MORE than other corners. This is wrong but it's definitely not specific to open-source and it hurts all projects the same. All developers should write less product code and more test code.
It's still a bit rich to have (as often) an impenetrable test system very hard to use and then to ask someone brand new to contribute to it! The first step should have been to apologize for the poor test system. Lucky you: you could have been asked to refactor that system :-)
Posted Jul 11, 2024 22:17 UTC (Thu)
by pizza (subscriber, #46)
[Link] (3 responses)
"well maintained" is an euphemism for "make sure someone else is paying for all of the maintenance work"
Posted Jul 12, 2024 8:09 UTC (Fri)
by lutchann (subscriber, #8872)
[Link]
Posted Jul 12, 2024 22:14 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (1 responses)
"Someone": yes. "Someone else": no, not necessarily. Maybe, maybe not. It depends. There's zero rule about that. That's besides the point.
If it's a very small (but still useful) dependency, that maintenance may not even require much money at all.
The purpose of these corporate policies is to avoid https://xkcd.com/2347/ and similar, difficult situations. How it is achieved matters but it is _secondary_. If "someone else" is very rich $BIGCORP2 that has tight control over the entire project, a bad open-source track record and is generally very difficult to work with (patent troll, painful license, other) then the answer could be "well maintained by someone else paying for all the work but... no thanks, too risky anyway". Unusual example but you get the idea.
BTW here's the best, non-comical version of XKCD 2347 I ever found: https://cacm.acm.org/practice/surviving-software-dependen...
https://medium.com/@sdboyer/so-you-want-to-write-a-packag... is also nice. Much longer and much more technical.
Maybe your comment was tongue-in-cheek but it was interesting anyway. Every joke has a grain of truth, it's less funny otherwise :-)
Posted Jul 13, 2024 6:52 UTC (Sat)
by sdalley (subscriber, #18550)
[Link]
Posted Jul 11, 2024 10:47 UTC (Thu)
by ringerc (subscriber, #3071)
[Link] (1 responses)
Posted Jul 16, 2024 9:50 UTC (Tue)
by jengelh (guest, #33263)
[Link]
Is gdebi still necessary?
Is gdebi still necessary?
Is gdebi still necessary?
Is gdebi still necessary?
Is gdebi still necessary?
* "No, because I didn't even write this code, I'm just doing archaeology from our internal repository and found this patch, you can take it or leave it."
* "No, because I don't know how to do any of that work."
* "No, because I've decided that this patch is no longer worth it."
* "No, because my employer won't give me headcount for this sort of work, I've already tried talking to them, and they've insisted that I have to throw patches over the wall with no further work allowed." (This is reasonable on the part of the employee, not the employer.)
Is gdebi still necessary?
Is gdebi still necessary?
Is gdebi still necessary?
Surviving software dependencies
It's pretty good; nice and short.
Surviving software dependencies
Kubernetes
Kubernetes