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."
"It baffles me that in 2019, we still don't have a conveniently browsable threaded archive of mailing list discussions."
Aren't there a lot of clients that can do this? Wouldn't it be rather trivial (less than a week's worth of time) to implement a website using Majordomo or GNU Mailman or even write your own from scratch?
"First they came for the slanderers and i said nothing."
The problem is that fixing tool affects lots and lots of other people. Change the tools, and you break lots of other projects that many not thank you for it, even if it's for long term good. Or, alternatively, some of them use your new versions of tools and some of them do not. Then you have fragmentation.
It's not only debian which has these problems of course. Old mature projects are slow, slow, slow to change.
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)".
> rsync, whose maintainer refused my patches to make the package use debhelper purely out of personal preference
I see this ridiculous attitude in docker, docker-compose, lxd, et al upstream maintainers as well.
They're in the container space because they don't understand packaging (or sane library/API design) so they got crushed by dependency hell. Their response? Run every single app in its own VM with its own copy of every single library under the sun. 500MB applications! YAY!
They refuse to take any packaging related patches.
Debian devs will drop one by one due to these people.
> 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 youth just close bug reports and PRs unilaterally. Not a solution.
The people who unceremoniously close PRs and bug reports as "won't fix" or "stale" are the whiny kids.
Only way I'd come help would be a guarantee we were getting rid of systemd.
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...
Then there's the people who stopped a long time ago and didn't bother announcing it to random people on the World Wide Webz
I've submitted probably close to a hundred debian bug reports over the years. These are project that don't have an upstream or the bug is debian specific. Most of them include patches to fix the issue. I don't think any have been looked at.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
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.
There are thousands of packages that do not require changes other than fixes when bugs are found. Your software does the job it was designed to do without issue. STOP. Your work is done. You have reached the pinnacle. Everywhere else you go will be down hill.
Dependencies and obscure libraries are such a problem now they had to be made into containers because no one else can even begin to compile your shitty code.
If you have problems with these old fogies then start your own branch and quit your bitching.
Only the State obtains its revenue by coercion. - Murray Rothbard
Sort of - if posting to Facebook actually contributed something of value to the world.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
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.
They're just not very creative.
Evolution by variation and selection (even if that variation is mindless) out-competes would-be Intelligent Design every time.
In fact, there is no such thing as Intelligent Design; there are just 2 kinds of design: That which works explicitly with variation and selection and that which tries to thwart it. FreeBSD is nice to work with because it doesn't do anything interesting; it's a well-polished turd.
Professional software isn't immune to this. I've had many many bugs I file and features I request at work languish for an inordinately long time because "we're in the middle of a release push" or "the other project is behind schedule so all resources are behind that" or even organizational infighting.
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.
Is what we so often hear in OSS, often followed closely by "and if you don't like it do yourself"
Now what were hearing, in this instance, is what he wanted didn't scratch someone else's itch and he doesn't like that answer.
Gee, I wonder why?
Never ask for justice. Karma will tend to apply it you just to see if that's what you really want.
This is because many upstream developers don't think it is their responsibility to help package maintainers.
It may not be their responsibility, but it is certainly in their interest to at least provide a few different packaging options *built into* the upstream sources, .deb and .rpm being the most common.
But they've all thrown up their hands and said "it's not my problem", leaving us with the cancer that is snap and docker, then complain that Debian is trash.
Guess what, docker, lxd, and snapd won't even run on debian if you can't even be bothered to make functional docker, docker-compose, snapd, lxd et al debs upstream.
I am wondering since a long time, why the Arch wiki does contain so much more (high-quality) content than the Debian wiki, although the developer and user base of Debian should be much higher.
One reason also here could be infrastructure. The Arch wiki
-> https://wiki.archlinux.org/
is a mediawiki instance, which looks much more attractive than Debian's wiki
-> https://wiki.debian.org/
which is a moinmoin wiki instance. I can understand that the motivation of users and developers is higher if they can create something beautiful.
Are the other reasons for the quality difference?
The thing about projects like Devuan is they are almost wholly reliant on the base project. Devuan dies without Debian.
It's all open source. There's no good reason to continue supporting the software with development and patches. Anyone can fork it.
What you're really saying is any upstart junior programmer with a patch should be able to receive the benefit of putting their code in a project whose name has decades of caché, rather than forking the project and needing to spend the next two decades doing marketing and getting their fork to take over.
Grow up.
You prefer it when some professional support rep lies to you about future releases just to keep you strung on as a customer? Cause THAT's what professional software looks like.
I'll take passionate hobbyist over professional software house any day with most types of software.
To claim it has no merits is ignorant. Setting up daemons on Linux is traditionally so difficult that many programming languages started just providing their own rather than try to get developers to understand initd well enough to write properly secured and managed daemons.
I can't tell you how many times I've seen Amazon Linux go down because no one sets up log rotation properly in the standard system packages. With initd, this is a bespoke per package hunt for how the logs get handled. With systemd, it's trivial and consistent.
This is just one minor example. There are countless others.
Well, the traditional form is "has been laid low".
Currently, if the Debian project somehow fell apart, you'd be right.
Down the road, if people keep migrating to Devuan, it will simply become what Debian was, without systemd.
Privacy begins with
The thing about projects like Devuan is they are almost wholly reliant on the base project. Devuan dies without Debian.
So what you're saying is they need all the help they can get.
Well, if you count install base as success, I'd say systemd has been pretty successful already. It certainly has its issues, but it's largely the expected issues you see with any new system, especially once that system has been foisted onto large numbers of unprepared admins.
The one good idea in Systemd is having a way to manage services and restart them as needed in one place. This eases management and is a good thing. The rest of systemd is a disaster of monolithic code made by someone who has a secret hard on for Microsoft's and Apple's way of doing things. Its fundamentally incompatible with the *nix platform which is why it runs like crap and has a security flaw every week. If they had just stuck to the core idea of being able to manage services then it would be fine. BSD actually did that over 15 years ago.
Might be worth a shot. Most people using it seem to be fairly happy with it.
I am using Calculate Linux, based on Gentoo, now. But Devuan is looking good. I used to love Debian, before the systemd crap.
I see that the maintainer is now very busy. They are contrasting Debian development to what they do in their day job. I don't see anything about bringing up suggestions within the Debian organization. Pointing this resignation letter towards everyone is something that should be the last used effort to invoke changes. Maybe if there were concrete suggestions rather than whining about not liking the results it could get some traction.
Been using it since 3.4 and still through 12. It has its uses.
Fully licensed blockchain psychiatrist
> Many times the package maintainer will actually submit something but when they get the WTF that isn't how we want our software handled from the devs they disappear and never some back.
I've seen this happen as well.
It's all open source. There's no good reason to continue supporting the software with development and patches. Anyone can fork it.
Forking doesn't solve the problem, which is that the place the users go to get the software is antiquated and baroque. If you fork it, now the users have to go somewhere else (or to two places) and you'll wind up only serving a subset of the users. The best solution for the users is for the centralized repository to be efficiently maintained.
What you're really saying is any upstart junior programmer with a patch should be able to receive the benefit of putting their code in a project whose name has decades of cachÃf©, rather than forking the project and needing to spend the next two decades doing marketing and getting their fork to take over.
You're focused on the benefits to the maintainers, but the real issue is the benefits to the users. The project exists to serve the users, not the maintainers. If they can make changes to better serve the users, that benefits everyone.
The tools for creating and maintaining Debian packages are indeed baroque and obscure, and they are also not well-documented. A lot more work could be done by other people if the tools were documented better, and even more could be done if the tools were designed better.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Setting up daemons on Linux is traditionally so difficult that many programming languages started just providing their own rather than try to get developers to understand initd well enough to write properly secured and managed daemons.
Wait, what? This is nonsense. First, there is no initd, it's init. Maybe you got it confused with inetd, which is used for short-running daemons. Managing those has always been easy. And because of the Unix philosophy of (among other things) using small, simple components that do one job and do it well, and more importantly are standards-based, it's easy to swap inetd out for a more secure inetd (typically xinetd.)
I can't tell you how many times I've seen Amazon Linux go down because no one sets up log rotation properly in the standard system packages. With initd, this is a bespoke per package hunt for how the logs get handled. With systemd, it's trivial and consistent.
The whole point of using a distribution is that this only has to get figured out once, by whoever is maintaining the package. That's why it's important for the distribution tools to be convenient. It's a shame if Amazon has failed at that in their distribution, but it's not an indictment of systemd-free Linux, but of Amazon Linux specifically.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
You define best by your own prerogatives- if users want centralization they should not be running Linux. Full stop. The very idea is antithetical to FOSS.
The idea of "FOSS" is that you get software for free. The idea of Free Software is that the user gets software under a license that permits them to make and use modifications. The idea of Open Source is interoperability through source code access. None of these preclude centralization. In fact, software adoption depends on trust. Trust depends on either a web of trust system, or centralization. That's why Linux From Scratch is a niche concept, and virtually all Linux users run a distribution from one of the major centralized sources.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The important people chose it. Like the engineers at RedHat and those working on Debian.
My point was not that systemd fixes the log problem. My point is that on a systemd system, it is trivial to audit and manage all your logging in a way that is consistent and simple. The fact that they integrated something like logging rather than just wrangling STDOUT/STDERR means that one doesn't have to hunt the init script to discover how logging is handled, where it goes, how to configure log rotation, etc.
Configuring logging sounds simple. It should be. But the traditional way of doing it simply does not work. If it did, we wouldn't encounter failure after failure of doing it correctly in the wild.
The idea of FOSS is you build on someone else's work. If you don't like the work they did, don't use it. If you are not qualified to build on their work, hire someone to do it. If you just wanna leach free software, then you're stuck with whatever the devs wanna give you.