Why am I curtailing my work on Debian
- Transfer
From the translator: this text - in a personal blog post translation Michael Shtapelberga (Michael Stapelberg) prominent open source-developer ( profile GitHub ), which made a significant contribution to the development of Debian.
This post was difficult to write from an emotional point of view, but I did not limit myself to “a short letter, because I did not have time.” Please, before reading this text, keep in mind that I am writing it with the best intentions and do not set myself the goal of demotivating or belittling the contribution of one of the developers. Rather, I want to explain why my level of frustration exceeded all acceptable values.
Debian has been a part of my life for 10 years.
A few weeks ago, at a Debian meeting in Zurich, I met with my old friends whom I had not seen for many years. When I was already riding my bike home, it dawned on me that all the topics we had discussed somehow came down to what we discussed with them last time. We discussed the merits of systemd, which once again attracted the attention of the open source community, touched on the topic of processes in Debian. The culmination was the discussion of democracy as such and the corresponding theoretical and practical errors. But, in fact, this is a purely Swiss topic.
This is not a review of the past mitap, I just want to explain what made me think about my current attitude towards Debian and whether it suits me.
So, I made a decision that I had to make a long time ago: I am curtailing my participation in the development of Debian.
What does it mean?
In the coming weeks, the following will happen:
- I will pass the important packages to the maintained command;
- I will remove myself from Uploaders packages that contain other maintainers;
- the packages in which I was the only escort would become orphans.
I will try to continue to support the page manpages.debian.org and service codesearch.debian.net , but highly appreciate any help in this area.
If you have any questions or any tasks, consider that I am on indefinite vacation. I will try to take part in some administrative issues (for example, the transfer of permits) and tasks addressed personally to me, but only if it does not take much time.
Why?
When I joined Debian, I was still studying, that is, I had a lot of free time. Now, after five years of full time, I have learned a lot - both in terms of how and what works in large software development projects, and in terms of understanding my personal preferences in computer systems. Now I am clearly aware of what I spend that small part of my free time on and what I have left at the end of the day.
Each of the following sections will focus on things that hurt me as a developer. This list is given in random order. Some of these problems affect each other, for example - if the system changes were carried out better, we would have a chance that the packages would be easier to handle by the machine.
Debian Change Process
Over the past few years, my current team has been working on various reorganizations throughout the code base (affecting thousands of projects), so we have received many valuable lessons on how to make these changes efficiently. It annoys me that Debian works in almost every way in almost the opposite way. I appreciate the fact that each project is different, but I think that many of the points listed below apply to Debian as a whole.
At Debian, package development is headed in the right direction using a document called the Debian Policy, or its software version , Lintian .
Despite the fact that lint is very convenient for getting a quick direct or local / autonomous feedback, it is even better not to require such a tool at all. For example, the C ++ command, which introduces a new security flag for all packages, should be able to make its work transparent for me as well ( judging by the GitHub profile, Go's main language is Michael, approx. Trans. ).
Instead, now all the packages are being done “dirty” (orig. - lint-unclean): all the attendants should read what this new thing is, how it can break, whether it affects their work in general, and if so, how. Then you need to manually run some tests and, finally, discard the changes. All this is a multitude of overhead and manual mechanical operations between packages.
In the Debian ModelThe decision to roll out the news rests with the accompanying packages, and not with the developers. At my main job, we found that it is more efficient to do the opposite: if the written change affects a significant part of users, then it is the developers who must decide on the need for its implementation. This approach makes the development of the project more efficient and reduces time and labor costs. Of course, there are exceptions, for example, in large areas where language chips are used, which should be taken care of by the respective owner-curators, but the important thing is that by default everything should be different than it is now.
Debian lacks tools for major changes: software is difficult to work with fragmented packages and repositories (more on this in the section below). The closest event to the default “sending changes to the review” is the process of opening a bug report with a patch attached to it. It seemed to me that the existing process of accepting a bug fix was too complicated, and I started working on a merge bot, but only Guido and nobody else showed interest in it ( apparently, the author talks about Guido agx Gunter , another Debian developer, - approx .
To put it literaryly, the reaction to the push and, accordingly, the receipt of feedback are slow. There are simply no deadlines. Sometimes I get emails notifying me that the patch I sent several years ago (!!!) was finally contained. This stretches the weekly projects for many years, which for me is a powerful demotivator.
It is curious to note, but the practice of tortoise online activity is also projected on offline culture, and I do not want to discuss the advantages of systemd 10 years after I first heard about it.
And finally, any changes can be stalled by those who disagree, who ultimately refuse to cooperate. My canonical example of this situation is rsync. The curator refused my patches, which add debhelper support to the package, solely from their own beliefs.
Granting such a degree of personal freedom to individual maintainers prevents all of us project participants from raising the level of abstraction of the Debian build, which, in turn, complicates the development tools.
What would it all look like in an ideal world?
- As a project, we must strive for unification. After all, unification does not exclude experiments; it simply changes the current compromise between simpler experiments and more complex automation into a compromise between more complex experiments and simpler automation.
- Our development culture should move away from the paradigm “this package is my business, how dare you touch it”, a common sense of ownership, in which any participant can easily make or verify changes, even without involving specific curators who are accompanying them.
To understand what successful large changes (patches) may look like, I recommend that you read my colleague Hiram Wright ’s presentation “Large-scale Changes at Google: Lessons Learned from Five-Year Mass Migrations” .
Fragmented workflow and infrastructure
Debian typically prefers decentralized approaches over centralized ones. For example, separate packages are stored in separate repositories, and each repository can use any SCM (usually git and svn) or not at all. Plus, each repository can be hosted on any site. Of course, the content of each repository also varies slightly from team to team, and even within the team.
In practice, non-standard hosting options are rarely used, since they do not justify their cost, but often enough to cause great pain when trying to automate the process of making changes to packages. So instead of using the GitLab API to create merge requests, you need to develop a completely different, more complex system that works with periodically (or constantly!) Inaccessible repositories, abstracts the differences in delivered patches (error reports, merge requests , extraction requests) and so on and so forth ...
Radically different development processes are not just a problem of wasting time. I participated in long conversations about various git development processes during the time of DebConf 13 and I realized that similar discussions were held then.
Personally, I can’t keep in mind enough details about the various development methodologies. Every time I touch a package that doesn’t work like mine, I get very upset because I have to re-examine aspects of its work.
I noticed a similar fragmentation of the workflow in my own Go packaging team and tried to fix it by making suggestions for changes to workflow , but I couldn't implement them. The lack of effective automation and the low rate of change in the tools, despite my willingness to spend my own time and energy, killed any motivation.
Deprecated Infrastructure: Download Packages
When you want to make a package available in Debian, you upload GPG-signed files via anonymous FTP. There are several types of tasks (the queue daemon, unchecked, dinstall, and others) that run on a fixed schedule (for example, dinstall runs at 01:52 UTC, 07:52 UTC, 13:52 UTC, and 19:52 UTC).
I calculated that depending on the time of day, you can wait more than 7 hours (!!!) before your package is installed.
But the worst part for me is that feedback is asynchronous with respect to loading. I like to do something, end it and move on to the next assignment. The current setup requires a long wait and, in fact, an expensive switch between tasks without good technical reasons. You may notice that a few minutes do not really matter, but when all the time in a day that I can spend on Debian is measured in minutes, it is of great importance for perceiving my own performance and satisfaction from the work done.
The last message I can find about speeding up this process is a post by George Ganneff Jaspert from 2008.
What would it all look like in an ideal world?
- Anonymous FTP would be replaced by a web service that accepts my package and returns in its response an official decision to accept or reject it.
- For received packages, there is a page displaying the build status and the time when the package will be available through a network of mirrors.
- Packages should be available within minutes of completion of the assembly.
Deprecated Infrastructure: Bug Tracker
I am afraid to interact with the Debian bug tracker. Debbugs is a piece of code straight from 1994 that is currently only used by Debian and the GNU project.
Debbugs processes are based on the use of e-mail, that is, they are asynchronous and cumbersome. Despite the fact that it works on the fastest machines that we have on the Debian project (well, they told me when this topic was last raised), its web interface loads extremely slowly.
Notably, the web interface on bugs.debian.org is read-only. Setting up an email workspace for reportbug (1) or manually working with attachments is a pretty serious challenge.
For some reason I don’t understand, every interaction with debbugs leads to the creation oflots of conversations .
Besides the technical implementation, I also can’t remember in any way the various ways in which Debian uses pseudo generation packages for errors and processes. I need them too rarely for me to finally put it all in my head and remember exactly how they function and are used, but I occasionally encounter them, so this variety is annoying.
What would it all look like in an ideal world?
- Debian will switch from a non-standard way of tracking bugs to (any) already settled.
- Debian automates these processes. The main interface should be more convenient (for example, a web form).
Deprecated Infrastructure: Email Correspondence Archives
I am confused by the fact that in 2019 we still do not have a convenient tool for viewing archived discussion threads in the mail. As widely as in Debian, Email and conversations are no longer used anywhere, so it's even somewhat ironic. Using Gmane seemed to solve this problem, but its availability over the past few years has been, to put it mildly, abrupt (now, at the time of writing this post, it does not work at all).
I tried to create a multi-threaded archive, but our sheet masters were not impressed and refused to support the project.
It's hard for machines to work with Debian
Although it is obvious that you can work with Debian packages programmatically, this experience is hardly pleasant. Everything seems slow and bulky. I selected three small examples to illustrate my position on this issue.
debiman needs help from piuparts in analyzing the alternative mechanism of each package to display documentation pages, for example, PSQL (1) . This was required because the scripts modify the alternative database by calling shell scripts. But without actually installing the package, you won’t know what changes it makes.
pk4must maintain its own cache to search for package metadata based on its name. Other tools analyze the apt database from scratch with every call. The correct database format, or at least the binary exchange format, will be of great importance to this process.
Debian Code Search wants to receive new packages as quickly as possible. The fedmsg instance was previously used , but it no longer exists. It is unclear where to receive notifications of new packages and where it is best to receive them.
Complex build stack
Here you can just read my post “Debian Package Build Tools” . What really worries me is the fact that increasing the number of tools is not considered a problem.
Debian is a painful experience for a developer
Most of the questions I raised concern Debian development experience, but, as I recently described in my Debian Debug Debugging Experience post , the development experience using Debian also leaves much to be desired.
I have more ideas
The article turned out to be quite voluminous, but I hope you got an approximate idea of my motivation.
Although I described a number of specific flaws above, the last nail in the lid of the coffin is the lack of a positive outlook for the future. I have other ideas that seem really convincing to me, but based on how my previous projects progressed, I don’t think I can implement any of them as part of the Debian project.
I intend to post a few more posts on specific ways to improve operating systems on my blog. So drop in.
And finally, I hope this post inspires someone, ideally a group of people, to make the lives of Debian developers better.