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
"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."
Doesn't systemd resolve these problems?
Then obviously they're not problems and the complainer is a whiny kid.
We'll be seeing everything YOU do on Windows 10, you mean, in your telemetry feed... poor dumb sonofabitch...
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)".
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.
> 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*
I likk yerr fluffy stringy tow cheez
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.
What OS is he moving to, and why is it better?
I'm sticking with Debian, but it would have been interesting to hear his plans and vision for the future.
Wouldn't the obvious thing to use be Launchpad? Outside of it being run by a business which might make some Debian members feel tainted (but they can always take a shower after posting bugs).
You were a fruitful Debian Maintainer for a decade long so, with the best of my wishes, Michael...
N/T
I stopped using it when I was told that a package couldn't be updated because the maintainer was too busy with midterms. I'm like this is supposed to be professional software? I'm going to have to disagree. I just use combination MacOS and AWS for me needs now. Debian is trash.
It's pretty simple, there NEEDS to be time for people to test and validate changes and yes sometimes those changes are politically biased. Get over it. Complaining about patches not being tested automatically is equally silly since a compile doesn't mean jack shit.
I want a fucking distro that is STABLE FIRST, not one based on bleeding edge. Why is it so hard to convince kids that? Debian is a political minefield.
For the record, been involved with UNIX and Linux for over 30 years.
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.
Debian has been long for the downhill since systemd. I'm sick of hearing about it too. That's why my current Linux options are Devuan and Gentoo with OpenRC, and in BSD land, I'm using OpenBSD.
These kids know everything. Funny how "everything" seems to be defined as "windows".
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.
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
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.
I don't want to be discussing systemd's merits 10 years after I first heard about it.
systemd has no merits, so if you attempted to discuss them, idk what that is. systemd was and is an internal revolution destined to fail, as it will become in and of itself a project as large as linux. And we never needed it before, so it is a monumental waste of time and reduction of stability. systemd will continue to break, and break things, forever. Bad ideas are always bad ideas. systemd, other than increasing boot times by dozens of seconds, only hoped to solve problems already solved better, so it is an absurd cog in the linux wheel and a major fuck up that will need to be removed at some point.
Sometimes, everyone needs a break, especially when they aren't being paid.
Every organization has issues. Working with volunteers is like herding cats. Each feels that their contribution is the most important, regardless of whether they
It forces you to pay for its shenanigans regardless of its performance; it literally points a gun at you and says "Do your part, comrade! "
So, I'm confused about your anti-anti-government stance; the real anarchists who want to destroy others' wealth are the people who support taxation. You can have rules or rulers, but not both; a desired rule is this: You cannot steal from other people, especially at the point of a gun; this forbids the existence of your precious government.
Plenty of these endlessly open reports are simple things like typo fixes; there's no excuse for it remaining open for years and years. It takes literally minutes to process such a patch, and when someone points out this fact, you and your ilk just indignantly whine about not being paid or some other old-person crap. And, after that, the typo patch still never gets applied.
You've just admitted it yourself: You are BAD at =======> maintaining <======= this software; you are no longer actually a maintainer; you're faking it. If you don't have time for it, then you are NOT a viable maintainer. What don't you get about this?
Do yourself and everybody else a favor and admit this, audibly, to yourself in the mirror; then, have the humility to ask for help—hand off the work to someone who actually has the passion. Step down. Get out of the way! DIE ALREADY, YOU OLD FUCK!
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.
It's not much better in private enterprise, e.g.:
So, good luck 'n' all, but I wouldn't expect anything to improve in the commercial sector while the Exec Teams are busy squandering all the money on company-funded international flights, hotels and piss-ups for "Strategy Meetings" every year.
Why should rsync get a dependency of debhelper, and make it locked to one distro?
It's been more than a decade since I last maintained Debian packages. It's reassuring to know not much has changed and I could jump back in without huge ramp up.
Debian is about a thousand fiefdoms - as all volunteer projects are. You can't make volunteers do things they disagree with - it's best not to pretend you can. One of the best things as a maintainer is that the central tech committee, since the systemd debacle, has laid low - as they should, especially after such a spectacular failure that has continued to damage the Debian community.
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.
... then sit there quietly.
Oh. You mean the committee has lain low.
ENGLISH MOTHERFUCKER DO YOU SPEAK IT?
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.
Hello Mr. Gates welcome to Slashdot.
I walked away from debian, and linux, back in 2000 or so. I walked away from freebsd around freebsd 9. The retroactively breaking of installed bases through pkgng was the final straw. (pkgng has a bad case of second system effect, but you probably missed the difference.) I used to love freebsd to bits in the freebsd 4 days, but hot damn has it gone to pot.
I have one freebsd 8 box around still, and I can't upgrade it. There really is no good OS and ecosystem to be had at all, currently.
"Youth" are reddit-tards who unapologetically think electron (bundling the whole of Chrome with every "app") is the best thing to happen to software ever.
Fuck the youth. Computers were good while they lasted.
Your reply is a straw man.
There's nothing "highly specialized" about cryptography. Most of it is basic maths; most of the algorithms are readily understandable.
The reason everyone gets cryptography wrong is because the so-called experts tend to be people who enjoy using numbers to make other people feel stupid.
Anyway, this is all irrelevant. There's not a dispute in this thread about such competency; the only competency in question is managerial.
ahhh, you work for Facebook, which doesn't have much income right now.
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?
Yeah, only shitty networking, losing resolution on my big screen, telemetry, all kinds of shit, but no packaging problems woohoo.
Please, folks, try at least once to have a coherent conversation. This is way more serious than it looks.
I've had my own share of fears recently -- and this is certainly worrying news (for someone outside development, that is).
There has been some frailty in Linux development, as I perceive it, regarding the range of options which are visible to end users.
It is not about an opportunity for venting our pet peeves: it may become a grave crisis. It's also about money or particular packages (for example, Systemd). I'll give an example:
There is the 64-bit/32-bit question. Many say 64-bit is way faster than 32; while certainly there are a few use cases requiring 64, benchmarks show the performance difference is not meaningful -- specially when the cost of upgrading from 32 to 64 is considered (you may have or not a 64-bit capable processor and the RAM needed to make a difference happen). Why is that relevant here? There is a discussion about dropping 32-bit support because Debian cannot deal with many scenarios. Actually, right now, it is only about supporting (or not) processors without the SSE2 instruction. This is often described as someone supporting "Pentium 4 or more recent" CPUs, which is ultimately good for Intel. But the 32/64 discussion follows the same pattern.
Some already pulled the plug and many distros simply just offer 64-bit versions, while Firefox recently threw the towel and became SSE2-only.
If you're Debian-based, such things are of interest. I happen to use an excellent Debian-based distribution (Mint) and could switch to LXDE for use in a 1GB RAM computer. For technical reasons, it has to be used here at home. It runs 64-bit, but 32 is a way to squeeze more performance from Firefox, which is lighter than Chrome, but still so heavy it requires a lighter DE than Xfce, my otherwise go-to option.
Can I use a Slackware-based distro? Sure, but my experience has been somewhat mixed: some updates break the i486 character when i586 packages requiring SSE2 are installed. The thing is i586 (and i686, for that matter) are no longer distinctive enough to prove software compatibility with a given CPU. We should have i486, i586, i586-SSE, i586-SSE2 and i686 classes. That is a source of frustration for us end-users.
Can I use Gentoo or Linux from Scratch? More and more that seems the case. It amounts to admitting the distribution concept fails for me. Also, people with lesser CPUs are probably less capable of compiling heavy things (like X, for instance). I could for instance easily upgrade my 1GB RAM computer to 2GB, making it way more useful, but this is not possible for someone distant from big cities or poor enough to be "distant" from that alternative. For that reason, I've been pondering to use JWM for additional savings.
A lot of things are Ubuntu-based and when people want more independence, they become Debian-based -- and that may not be enough, given Stapelberg's observations. Debian looks a safer base than e.g. Slackware and Fedora... I'll admit that's just my personal perception, though. When it is revealed to be less safe than I thought, that is cause for worry.
I know there are maps of distro origins, on what they're based or from what they were forked, but it's my feeling that most distributions come from Debian (directly or via Ubuntu). Maybe there is some statistic (e..g. from Distrowatch) saying what percentage of distributions are based on Debian, Fedora and Slackware...
We are still waiting to have the discussion about systemd for if/when some can find any merits
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.
Your lithium dosage may need some adjustment.
Often, large systems need a good cleaning and brushing out from time to time. The scale of problems alone can trigger the need for change.
And if you cannot initiate these housecleanings, your system has fallen into the bureaucratic trap.
They go around finding interesting developments created by non-Borg entities, and then assimilate their distinctiveness into the collective.
What you're admitting is that FreeBSD is entirely dependent on non-FreeBSD (e.g., Linux) being a thing; FreeBSD is a parasite.
People say "lay" when they mean "lie", and "laid" when they mean "lay".
Consequently, its a widespread phenomenon to say "lay low" when a person means "lie low", or "laid low" when a person means "lay low".
Maybe you're right.