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."
Maybe give him some money from all the software Debian sells.... oh, yeah
> 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*
The truth is that revolution is always multi-generational.
The initial generation of youthful dissidents really don't know what they're doing, but they talk a lot, and bitch and moan about the way things should be.
Then, another generation comes along which takes a stab at actually doing something, and they fuck up horribly. They create religious cults with codes of conduct, and evangelize new ways of writing their ideas, and behave in impractical ways that makes everyone roll their eyes and think "Nothing will ever change for the better.".
When the dust settles, there appear the ones who will be remembered as "the" revolutionaries. They see not only what needs to be done, but how to do it, and this implies an avoidance of fluff; they are shrewd and practical, and topple the Old Way with what superficially appears to be some kind of divinely inspired ease—they will be regarded as a generation of geniuses. But, there is no ease or acute genius in it; they are the final benefactors of a long, arduous struggle to find the path.
Eventually, they or their disciples, having one the authority, will have their minds slowly corrupted until they themselves become the rotten foundation that must be dismantled and replaced.
You were a fruitful Debian Maintainer for a decade long so, with the best of my wishes, Michael...
It took years to merge a patch (we've all experienced that).
You know why? Because the people who have commit authority have "got busy"; they've aged into people who have aches and pains and mortgages and medical concerns, and retirement worries, and unruly teenagers, and definite preferences for the way things should be done, and a lack of passion for re-evaluating one's views.
The problem is that authority figures keep their positions for too long. If it takes you YEARS to get around to merging a typo fix, then you''re done. You need to hand the project over to some a different person, or re-organize the project into sub-projects with their own maintainers, or (horrors!) actually commit to some kind of dependable, objective, time-based procedural process, or some combination of these and other things.
The problem is that, by definition, old people who are set in their ways cannot allow themselves to draw these conclusions. Hence stagnation. If you get upset when someone points out the fact that it's taking too long to merge a patch, then YOU are the problem; a good, competent maintainer would be ashamed that progress is irritating.
I know it hurts man, but you've uncovered an important lesson for others: Go where you're appreciated; don't work for people who can't see your value.
When bugs are found, they do not get fixed. When you point out that a simple patch hasn't been applied in 8 months, then you get nothing but indignant whining about the nature of volunteer efforts and other older-person, boomer excuses; meanwhile another 8 months go by, at which point you decide it's not worth poking again.
So, you're right. That's exactly what's going to happen. All of these "working" packages are going to be re-written in Rust by pink-haired trannies, and thus the wheel will have been re-invented for the ten-thousandth time.
If there's one thing humans know how to do well, it's waste resources.
As a Debian to FreeBSD convert myself, it sounds like pretty much everything they're looking for is already solved in the FreeBSD ecosystem. It has been absolutely night and day as a user, administrator, and contributor working with FreeBSD compared to any Linux distro. It is so nice having one single ecosystem for the kernel, base OS, and 3rd party software, instead of each being handled by different communities with different objectives overall. if a breaking change needs to occur in the FreeBSD world, the entire kernel/OS/software stack is updated in unison with a new major version release.