xxx

Who?

GitHub: Michael Stapelberg

Project: Debian

Date: 03/10/2019

Why?

We found a number of issues with the ecosystem according to the contributor’s post.

The first of which is regarding the ecosystem’s policy, and more specifically it’s “programmatic embodiment, lintian.”

The team conducting the change (e.g. the C++ team introduces a new hardening flag for all packages) should be able to do their work transparent to me.

Instead, currently, all packages become lint-unclean, all maintainers need to read up on what the new thing is, how it might break, whether/how it affects them, manually run some tests, and finally decide to opt in. This causes a lot of overhead and manually executed mechanical changes across packages.

As a result, you’re reliant on the other projects to accept your packages. This can create some hositility in the community as well, with some maintainers refusing to accept changes.

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.

Ultimately, this leads into a potentially slow development cycle and even mentions how one of their patches took years, finally got merged.

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.

The rest of the issues that the contributor brought up really fall in the same categories as above. Not only is the patch policy difficult and frustrating to our contributor, but so is the decentralized approaches Debian makes.

In practice, non-standard hosting options are used rarely enough to not justify their cost, but frequently enough to be a huge pain when trying to automate changes to packages. Instead of using GitLab’s API to create a merge request, you have to design an entirely different, more complex system, which deals with intermittently (or permanently!) unreachable repositories and abstracts away differences in patch delivery (bug reports, merge requests, pull requests, email, …).

This slow culture seems to be pretty ramparant throughout the community, as the contributor brings up the fact that they’re slow to update infastructure as well, causing long wait times.

Depending on timing, I estimated that you might wait for over 7 hours (!!) before your package is actually installable.

All together, these issues have solidified the thought that the contributor can’t make any of their ideas happen in Debian.