Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Debian Open Source

Debian Package Maintainer Steps Down, Complaining About 'Old Infrastructure' (stapelberg.ch) 176

Posted by EditorDavid from the permanent-vacations dept.
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."
This discussion has been archived. No new comments can be posted.

Debian Package Maintainer Steps Down, Complaining About 'Old Infrastructure' More

Debian Package Maintainer Steps Down, Complaining About 'Old Infrastructure'

Comments Filter:

  • "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?

    • Re: email client (Score:1)

      by Anonymous Coward

      Sure, go do it. For free.

    • I think that was the point. He used to use gmane which does give a threaded interface, but gmane is not maintained reliably as it once was.

      So, it's a question of someone finding the will to do it, I guess.

      • He used to use gmane which does give a threaded interface, but gmane is not maintained reliably as it once was.

        That's like saying Atlantis is not maintained reliably as it once was. Visited gmane.org recently?

  • Package Tools are the worse (Score:5, Informative)

    by Phillip2 ( 203612 ) on Sunday March 10, 2019 @06:13PM (#58249472)

    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.

    • Not to mention that the Debian packaging tools are already pretty good, so there's little reason to change what works.

      • Re:Package Tools are the worse (Score:5, Interesting)

        by Zaiff Urgulbunger ( 591514 ) on Sunday March 10, 2019 @08:07PM (#58249918)
        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.

        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! :D
        • You just described shit software. Debian is obviously trash.

        • You just described something not unique to Debian, but related to any complex technology in any field. If you read a study about genetic research and want to know more about it and start pursuing things, you will find a lot of 'rabbit holes' related to many no doubt extremely complex topics that all related in one way or another to the subject matter.
          If you start working with a modern web framework technology and haven't studied computer science formally and especially a lot of newer developments, you will

          • Re: (Score:2)

            by doom ( 14564 )

            haven't studied computer science formally

            I can't imagine what it is you think the standard computer science curriculum has to do with understanding arbitrary, evolved lash-ups of tools.

            I think pretty much what you need is experience with a few real world messes, so that you won't sweat the fact that nothing seems to make much sense.

        • Re: (Score:2)

          by AmiMoJo ( 196126 )

          People used to joke about DLL Hell on Windows, but traditional Linux packages are pretty brittle too. That's one of the reasons why newer systems bundle everything in a self-sufficient container.

          • Re: (Score:2)

            by doom ( 14564 )

            That's one of the reasons why newer systems bundle everything in a self-sufficient container.

            The main reason is the js kids got burned by less.js and they've concluded that the dependencies on anything is dangerous and you can't trust anything but massive libraries shipped by the FANG.

        • Re: (Score:2)

          by doom ( 14564 )

          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

          On the subject of backwards compatibility-- which I'm generally a big fan of-- the Makefile syntax was quickly understood to be a mistake, but the author had about 10 people using it already, and didn't want to annoy them by changing it.

          I've seen people working on Makefiles who very carefully cut and paste the beginning of the previous line before entering a new one-- the

      • True, and contrary to quite a few other posts here, there is a lot of activity and updating/modernization going on. For example: Debian Continuous Integration [debian.net] which is only a few years old.

        I think the disgruntled maintainer should consider running for the Debian Project Leader [debian.org] position which is open right now and advocate for changes he wants.

  • Petty fiefdoms are always going to be a problem (Score:5, Interesting)

    by Kalrand ( 177637 ) on Sunday March 10, 2019 @06:14PM (#58249478)

    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)".

    • This seems to be a problem of the wrong form of code ownership. Currently Debian seems to use strong code ownership with no guarantee that the code owners ("maintainers") have to be available. There are plenty of other models [martinfowler.com] and the project probably has to find a way to change to one of them. The biggest problem is that normally the best person to fix software is a person who actually has the problem and is an expert in the languages and modules being used. In the rare case when such a person is availa

      • I can assure you that it is not just Debian that takes this approach. This story is getting a bit old, and perhaps things have changed, but I submitted a patch to kernel.org for a deadlock in the kernel with USB HID devices back in 2.10 and this simple (one line patch to remove a sleep with a spinlock) never got accepted. Even after I submitted it for 7 kernel versions in a row. Finally someone on the kernel team submitted the exact same patch and it instantly got accepted into the project. And guess ho

    • Re: (Score:3)

      by AmiMoJo ( 196126 )

      I've found that delays or rejections are often due to the maintainer not being able to properly test the patch. Often I'm fixing quite specific bugs or adding support for some unusual use case I have, and the maintainer just doesn't have the resources to test it.

    • Re: (Score:2)

      by Trogre ( 513942 )

      Screw NIH syndrome.

  • the culture of containers (Score:5, Informative)

    by nyet ( 19118 ) on Sunday March 10, 2019 @06:33PM (#58249564) Homepage

    > 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.

    • Re:the culture of containers (Score:5, Interesting)

      by ArchieBunker ( 132337 ) on Sunday March 10, 2019 @07:20PM (#58249742)

      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!

      • Re: (Score:3)

        by nyet ( 19118 )

        Don't even get me started on snap. What a steaming pile of shit.

      • Re: (Score:2)

        by nyet ( 19118 )

        Oh hey look, another unfixed debian bug.

        https://bugs.debian.org/cgi-bi... [debian.org]

      • Xcalc does the exact same functions and its not even 40 kilobytes!

        My 4TB of disk space and 32GB of ram thanks you for your efficiency.

        Seriously though just because it isn't suitable for use in a lite distro on challenged hardware doesn't mean it doesn't have a purpose. Your example uses a nice standard Xcalc, but pick something which has a lot of dependencies and quick development cycle with constantly added features and you're in for a world of hurt if you happen to want to run the latest version without the distro maintainer's "approval".

        Slashdot: Where we are happy wai

    • It isn't a ridiculous attitude, it is basic Law of Identity: I am not you, and you are not me. The upstream software exists for whatever the purposes and preferences of its developers are; the distribution that includes that software is merely a user. Their preferences may or may not be part of the development process, according to the prerogatives of the upstream developer.

      If a volunteer maintainer at a distro feels entitled to dictate changes, maybe they've been volunteering too long and should move on to

      • Re: (Score:2)

        by nyet ( 19118 )

        As I said "Debian devs will drop one by one due to these people."

        Debian will die because of that idiotic attitude, and all that will be left is containers. Wonderful.

    • 500MB applications! YAY!

      And? Not all 500MB is loaded at once, so they don't take massive amounts of RAM, and HDD is cheap. Docker and snap may not be suitable for lite distributions, but having seen Linux systems where aptitude gets so fucking out of control that a format was in order due to the addition of non standard repositories because someone dares not to want to wait for the blessing of a maintainer to run the latest version of some software, I see the point.

      • Re: (Score:2)

        by nyet ( 19118 )

        >so they don't take massive amounts of RAM

        The whole purpose of shared libraries is that multiple applications can mmap the same .text area.

        The reason you don't see large memory usage is only because applications take proportionally orders of magnitude more bss/heap/stack compared with .text than they used to.

        To that extent, fine. Let's ditch shared libraries. But you could do the same by just statically linking all of your binaries.

      • Re: (Score:2)

        by nyet ( 19118 )

        > non standard repositories

        Meaning non-free. Wonderful how far Debian has regressed.

  • dude got busy? (Score:5, Insightful)

    by forgottenusername ( 1495209 ) on Sunday March 10, 2019 @06:34PM (#58249568)

    > 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*

    • "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*"

      More or less my impression.

      * On one hand, quite a lot of good ideas that come from his obvious knowledge of the innards of the project.
      * Then, he seems to be good at what he does, he's ten years older (and more expert) and has his ideas, so there's also quite a bit of what he finds others to be guilty of (my way or the h

    • Re: (Score:2)

      by shess ( 31691 )

      > 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*

      Hmm, well, my experience is that often enough, it isn't so much that people _prefer_ a particular way, they just can't see how to change it. That doesn't mean that any old change which comes along is acceptable - maybe there are 20 people pulling in different incompatible directions.

      I think the more likely problem is that 10 years in, you're no longer working on clear greenfield problems that are easy to move on. A higher proportion of the project's problems are hard problems, you have experience so you'r

  • so long... (Score:4, Insightful)

    by turbidostato ( 878842 ) on Sunday March 10, 2019 @06:39PM (#58249598)

    You were a fruitful Debian Maintainer for a decade long so, with the best of my wishes, Michael...

    ...so long, and thanks for all the fish

  • 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.

  • FreeBSD (Score:5, Insightful)

    by darkain ( 749283 ) on Sunday March 10, 2019 @07:37PM (#58249822) Homepage

    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.

    • The Borg is indeed effective (Score:1)

      by Anonymous Coward

      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.

      • It doesn't need to be creative. BSD isn't in the business of selling shiny iDevices to people. Its a server and workstation OS. Its main goal is to be stable, secure and perform well. If someone else comes up with a creative idea that pans out then it can be implemented once matured. BSD is the opposite of fads. You are't going to find Rust and Snap in BSD.

  • Nobody wants to lead Debian (Score:2, Interesting)

    by Anonymous Coward

    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.

  • Reviews are the highest priority items on queue (Score:4, Interesting)

    by Wrath0fb0b ( 302444 ) on Sunday March 10, 2019 @11:07PM (#58250476)

    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.

    • Re: (Score:2)

      by rossz ( 67331 )

      often followed closely by "and if you don't like it do yourself"

      Which is a damn stupid attitude. Not everyone who uses software is qualified to write code for it. Even a skilled coder might not have the chops for a particular type of software. Take encryption, for example. That's a highly specialized field requiring a highly specialized skill-set.

      • It seems to work for Microsoft and Apple.

      • I think it is more like "and if you don't like it and refuse to pay me anything for fixing it, then do it yourself". If you are one of those highly-skilled developers who knows how to code something that a whole lot of people would benefit from, why are you considered greedy if you want to actually get paid something for your expertise and hard work?

  • 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/ [archlinux.org]

    is a mediawiki instance, which looks much more attractive than Debian's wiki

    -> https://wiki.debian.org/ [debian.org]

    which is a moinmoin wiki instance. I can understand that the motivation of users and developers is higher if they can crea

  • 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.

Slashdot Top Deals

Keep up the good work! But please don't ask me to help.

Close