Slashdot Mirror
Debian Package Maintainer Steps Down, Complaining About 'Old Infrastructure' (stapelberg.ch)
Michael Stapelberg, maintains "a bunch" of Debian packages and services, and says the free software Linux distro "has been in my life for well over 10 years at this point."
Today he released a 2,255-word essay explaining why he's "winding down" his involvement in Debian to a minimum, citing numerous complaints including Debian's complicated build stack, waits of up to seven hours before package uploads can be installed, leading to "asynchronous" feedback -- and Debian's lack of tooling for large changes.
The closest to "sending out a change for review" is to open a bug report with an attached patch... Culturally, reviews and reactions are slow. There are no deadlines. I literally sometimes get emails notifying me that a patch I sent out a few years ago (!!) is now merged. This turns projects from a small number of weeks into many years, which is a huge demotivator for me.
Interestingly enough, you can see artifacts of the slow online activity manifest itself in the offline culture as well: I don't want to be discussing systemd's merits 10 years after I first heard about it.
Lastly, changes can easily be slowed down significantly by holdouts who refuse to collaborate. My canonical example for this is rsync, whose maintainer refused my patches to make the package use debhelper purely out of personal preference. Granting so much personal freedom to individual maintainers prevents us as a project from raising the abstraction level for building Debian packages, which in turn makes tooling harder.
There's also several complaints about old infrastructure -- for example, "I dread interacting with the Debian bug tracker. debbugs is a piece of software (from 1994) which is only used by Debian and the GNU project these days." Stapelberg also complains that the "painful" experience of developing using Debian "leaves a lot to be desired," and adds that "It baffles me that in 2019, we still don't have a conveniently browsable threaded archive of mailing list discussions."
"My frustration level ultimately exceeded the threshold," Stapelberg writes in the essay, adding "I hope this post inspires someone, ideally a group of people, to improve the developer experience within Debian." He'll soon transition packages to be team-maintained "where it makes sense," but also "orphan packages where I am the sole maintainer... For all intents and purposes, please treat me as permanently on vacation..."
"I will try to keep up best-effort maintenance of the manpages.debian.org service and the codesearch.debian.net service, but any help would be much appreciated."
Today he released a 2,255-word essay explaining why he's "winding down" his involvement in Debian to a minimum, citing numerous complaints including Debian's complicated build stack, waits of up to seven hours before package uploads can be installed, leading to "asynchronous" feedback -- and Debian's lack of tooling for large changes.
The closest to "sending out a change for review" is to open a bug report with an attached patch... Culturally, reviews and reactions are slow. There are no deadlines. I literally sometimes get emails notifying me that a patch I sent out a few years ago (!!) is now merged. This turns projects from a small number of weeks into many years, which is a huge demotivator for me.
Interestingly enough, you can see artifacts of the slow online activity manifest itself in the offline culture as well: I don't want to be discussing systemd's merits 10 years after I first heard about it.
Lastly, changes can easily be slowed down significantly by holdouts who refuse to collaborate. My canonical example for this is rsync, whose maintainer refused my patches to make the package use debhelper purely out of personal preference. Granting so much personal freedom to individual maintainers prevents us as a project from raising the abstraction level for building Debian packages, which in turn makes tooling harder.
There's also several complaints about old infrastructure -- for example, "I dread interacting with the Debian bug tracker. debbugs is a piece of software (from 1994) which is only used by Debian and the GNU project these days." Stapelberg also complains that the "painful" experience of developing using Debian "leaves a lot to be desired," and adds that "It baffles me that in 2019, we still don't have a conveniently browsable threaded archive of mailing list discussions."
"My frustration level ultimately exceeded the threshold," Stapelberg writes in the essay, adding "I hope this post inspires someone, ideally a group of people, to improve the developer experience within Debian." He'll soon transition packages to be team-maintained "where it makes sense," but also "orphan packages where I am the sole maintainer... For all intents and purposes, please treat me as permanently on vacation..."
"I will try to keep up best-effort maintenance of the manpages.debian.org service and the codesearch.debian.net service, but any help would be much appreciated."
I read the article, and he did touch on the endemic issue I've run into of "that patch didn't come from us, so it's rejected (or ignored)".
The problem is not the infrastructure, but rather the people who build/maintain that infrastructure.
Folks, the generation who built the FOSS on which we rely has itself become old. Maintainers of key components are now literally old people, who lack passion, and who get irritated by any change; they aren't interested in improvements, and would rather you just bugger off. The best of these people have been in authority positions for so long that their minds have become corrupted; they actually think that their positions entitle them to being gatekeepers, and centralized services such as GitHub have given them a real sense of moral correctness in quashing or even disappearing dissent or mild negativity with the touch of a button.
Time for a youthful revolution.
Snap doesn't fucking work if your home directory is in a non standard location. Say /home/blah.corp/mylogin. I couldn't even get gnome calculator to run because of snap. Oh and the program itself is nearly two megabytes in size. Xcalc does the exact same functions and its not even 40 kilobytes!
Only the State obtains its revenue by coercion. - Murray Rothbard
I can fully appreciate why someone who uses tooling to get stuff done, and has already taken the time to learn and understand that tooling, really doesn't need to be wasting their time to switch to something else that does the same thing.
:D
But, the flip side is, some of this stuff is so arcane.
I can't speak as an even vaguely "good" developer, because I'm not. But what little tinkering I've done with various Debian packages, it's been sodding hard work. Typically, something I'm doing isn't quite what I should be doing... e.g. I've downloaded the source packages and tried recompiling, except I'm doing it under Raspbian and some of their packages aren't quite in sync (e.g. debhelper is slightly older).
So then, because things are not working as per the instructions I'm looking at on how to build Debian packages, I'm faced with _trying_ to grok what is being done.
Now, this is in large part because I'm not an experienced *nix user or C programmer. So for example, whilst I broadly know what make does and what a makefile is (the person who decided that using a space or a tab in the wrong place would break things really should suffer in the next life however), the syntax is pretty hateful and I don't want to have to try to understand the whole thing. Plus, this is Debian, so it's probably generated by some other tool and to try to read and understand it will take me a huge amount of time alone.
Plus there's absolutely loads of other bits of tooling all glued together somehow. Any time I've looked at it, it's just a bunch of rabbit holes I go down, leading to another, and then to another, before eventually I have to call it quits because I can't invest the time, for what is typically some minor issue that I might hope to be able to fix.
I know the above is a bit unfocused and ranty... and I would understand if people wrote it off as being down to my lack of understanding. My concern is that if newbies want to jump in and contribute, the barrier to entry is very very steep, and as a result, it's likely people won't bother.
A few months ago I encountered a problem with file / libmagic (or something) where a file beginning with "80" would report as being mime-type "application/zlib"... in my case, I had a text file that happened to start with "80" and should've been reported as "text/plain".
Turns out this only happened in Debian Jessie and not Stretch. And reporting involved using the Debian reporting tool... and I dunno, it just all looked too much like hard work. And I knew I'd be updating to Stretch soon anyway and I could work around the immediate problem so... I didn't bother.
Anyway... thank you (anyone) for listening!
Recently the period for nominations to fill the Debian Project Leader position expired and not a single Debian developer has stepped forward to nominate themselves to take the reigns of the project. According to Debian constitution, the period for nominations will be extended one week until a developer finally throws their hat into the ring though it may not occur before the current DPL's term is up.
One thing I love about my current job is that everyone takes this rule almost 100% seriously. You are almost forbidden to do anything while you have a review pending on you.
The reasons are fairly obvious -- reviews are a blocking operation. Sure, the developer can go work on something else, but if he's got a chain of dependencies to work through, things get hairy if he gets too far ahead of the reviewers.
Other benefits are more subtle. First, it encourages everyone to carefully pre-review, because they know that sending it up will interrupt everyone and they don't want to do so trivially. The second major benefit is that the longer things are pending, the greater the chances of merge conflicts, and even with the best of tools, 3-way merging is the enemy.
Of course, we aren't robots. And a huge change may take a week to read. But it's a good general default rule that you shouldn't be writing code or investigating bug reports if you've got a patch waiting on you.
Security nightmare. OpenBSD, ok, but freebsd? hell no.