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."
> When I joined Debian, I was still studying, i.e. I had luxurious
> amounts of spare time. Now, over 5 years of full time work later, my
> day job taught me a lot, both about what works in large software
> engineering projects and how I personally like my computer systems. I
> am very conscious of how I spend the little spare time that I have
> these days
Yes he has many good, useful and interesting points. The fact that his life has changed and can no longer dedicate the same amount of time, effort and energy as he could when he was a student with fewer responsibilities is the key non-sensationalist takeaway imo.
> 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.
Hardly a new problem. People have been complaining about this for a very long time. Part of what spawned Ubuntu. These really large, old projects with huge user install bases tend to be very resistant to change for good reason.
He has some valid points but also much of what he expresses is personal preference. Things that bug him others really prefer. Who can say which is right / how things should change? *shrug*
Only way I'd come help would be a guarantee we were getting rid of systemd.
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!