Debian's Master is Deleting Criticism of SystemD and Other Things (On-Topic and Published by Debian Developers), Resorts to the Excuse Messages Are "Too Long"
Censorship serves nobody except the masters that control this censorship
Debian Project Leader: "Unproductive behaviour on Debian mailing lists - including excessively long, complex, and unfocused messages that consume disproportionate attention and discourage participation - is not acceptable."
8 days later Michael Lustfield said his message had been suppressed by censors of the mailing list:
My first/second attempt to reply on-list with a detailed/thoughtful explanation seem to have been silently discarded, so no idea what happened. It was at least able to get the people who needed to see the copy; this is one last attempt to provide a public response. (attachments removed, email me if you want a copy) - ---
Note: All "quoted text" is paraphrased.
On Wed, 11 Feb 2026 11:58:22 +0000 Sean Whitton <spwhitton@spwhitton.name> wrote:
> Hello, > > Michael Lustfield [10/Feb 3:13pm -06] wrote: > > Yeah...my time for emeritus is long overdue. > > > > [...] > > Just to confirm, is this a resignation notice from you too?
Yes, this is indeed my own resignation as well, although I can see now that it was excessively curt and I apologize for the confusion this caused. Some of the people who believe they were the reason I chose to "revoke my option to interact" have asked me to speak more candidly on the frustrations that led me to resign.
Long-Term Concerns - ------------------
To start this off, let me clarify that there is no single event that drove this decision and my references to world politics are more than just casual.
systemD - -------
This change in perception of Debian dates all the way back to systemD. Rather than coming together to collectively discuss technical merit, the Debian Constitution was abused to force the decision out of DD hands. The claim was that we can keep supporting both, but then we immediately saw removal of (fully-functioning) support for other init systems. This change in Debian ultimately came down to politics over technical merit.
To me, this mirrors Ajit Pai, who was given a position solely to remove Title II classification of Internet Service Providers (ISPs), along with (my) representatives that were paid to look the other way. ISPs claimed it was totally not about failing to meet standards or making fast lanes, yet Verizon was caught with fast lanes the same day the law changed, and rural access saw the expected tank in service.
Salsa - -----
This perception deepened when it became time to retire Alioth. This was a well-known pain in Debian architecture, and performing two critical tasks made it especially difficult to replace. There was a brief call for discussion, however I now perceive that as entirely for show because the decision had already been made and the only thing left to do was get drunk and pick a name...salsa, because "we're eating chips and salsa."
I was told that the decision was made and if I want to have anyone consider anything else, I need a fully-functional prototype that fully integrates with existing authentication and it needs to be in Debian's main archive.
It took about two days for me to work out authentication, using gitea with certificates handled by nginx. Getting gitea into main was going to take a lot more work as a solo project, but that requirement was eventually dropped...for gitlab anyway. Ultimately, the challenges were insincere and the choice had already been made.
Was gitea the right choice, or would something else have been better? We'll never know. When I attempted to obtain resources so that I could run it on debian infrastructure, rather than my own VM, Wirt literally said (in #d-admin) that he will rage-quit the project if anyone gives me any of Debian's resources, and that was enough to ensure my requests never saw a response.
I continued pushing gitea into debian/main because I genuinely thought gitea was a great candidate and didn't see why there should be any problem having multiple options, especially when one could be mirrored to the other and it was me personally footing the bill for gitea.
Call for Resource Usage - -----------------------
This was prior to an email thread on d-private@l.d.o, with the subject: > Spending Debian money, Dev boards, laptops, upcoming Lenovo discounts and more...
SSO - ---
It was not long after that "we may as well use gitlab as the new SSO provider" came up, to which I found immediate alarm. In truth, this [1,2] is still something that I find very concerning.
I attempted to ask for some time to build something that addressed concerns, but the conclusion was, "I don't hear anyone, so you should just do it." [3]
I still believe that LemonLDAP-NG [4] is the best long-term solution for Debian SSO. Xavier literally wrote that software from the ground up to serve The National Police [5] and knew better than anyone how to build an SSO solution with long-term concerns put to rest. All of their internal developers are encouraged to become DDs because their own release into production is through main. He even wrote a plugin [6] that was able to fully replicate certificate-based authentication, providing backward compatible migrations.
Unfortunately, this was also just bits to the wind; the oligarchs already made their choice and serious discussion was never on the table.
[1] https://lists.debian.org/debian-project/2020/04/msg00054.html [2] https://lists.debian.org/debian-project/2020/04/msg00005.html [3] https://lists.debian.org/debian-project/2020/04/msg00086.html [4] https://lists.debian.org/debian-project/2020/04/msg00009.html [5] https://en.wikipedia.org/wiki/National_Police_(France) [6] https://salsa.debian.org/yadd/debian-sso
Unhealthy Discussion - --------------------
This perception of claiming to engage in constructive conversation while doing the exact opposite is not mine alone. It is a common plea that I do not believe has changed in any significant way.
I have been given permission to repeat this segment from d-private@lists.d.o, that captures my feelings perfectly:
> I have always had great appreciation for the community members' > technical skills, which are generally far beyond average. However, for > the longest time, I erroneously assumed that people with great ability > to analyze technical problems and to devise solutions for them would be > capable of doing the same for social problems. > > Everything escalates here. Issues get amplified way beyond proportion, > people shout past each other louder and louder trying to get the last > word (which they'll never get, since enough of them never realize when > it's time to walk away from a discussion, even if you're in the right). > > De-escalation seems to be such a foreign concept to parts of this > community. Some things clearly deserve a strong response. Some don't, > and much like a Rorschach test, the fact that said stuff still produces > endless threads says nothing about the stuff, but about the people > producing the thread.
This thread was also the point where I was no longer able to handle the mental toll of being on that mailing list and unsubscribed. A few claimed that I shouldn't be part of the project if I'm not subscribed to that list, even though I was still working toward becoming an "FTP Master" (team member).
FTP Team - --------
While contributing to that team, I was subjected to an opaque process that was clearly used to play favorites. Trainee reviews were rarely discussed openly, unless being used for open reprimand. It was incredibly uncommon for Trainee reviews to actually be reviewed at all, unless at least one FTP Master was dedicating their time to fast-track their favorite Trainee...in order to gain access to make policy changes.
In #d-ftp-private, team members were very open about which packages they wanted to prioritize and which uploaders got to the shit list and should be ignored. Anyone who attempted to suggest a replacement project was responded to by never again seeing their own package reviews reviewed; effectively making them (us) "Permanent Trainees."
Perhaps the most shocking interaction I witnessed was deciding someone "need not apply" because "[they] don't trust anyone involved with that many teams."
Review Tool - -----------
There's only so much that someone can do without support of others, and FTP Team effectively shut down my own project efforts by stating their opposition and booting one of those trainees--because they shared something from #d-ftp-private onto d-private@lists.d.o (instant +kb).
This was the point when I began to take very long breaks. Aside from responding to requests for advice, my entire activity can be shown on github/MTeck/tdc. [7]
[7] https://github.com/MTecknology/tdc/commits/debian/
Tag2Upload - ----------
- From my perspective, this was rushed to GC in a similar way to sytemD, and then dropped because, "we found a loophole so we don't need your approval."
New Review - ----------
I recently became aware of a renewed [8] interest in a replacement review utility [9] that would address historical concerns. I was very excited about this and attempted to share my own [10] attempt to solve core requirements. I honestly thought this was going to finally renew my interest in Debian and get me excited for a long-term project grind.
Unfortunately, I quickly discovered that the current replacement tool [11] was built by an LLM and had all the signs of fundamental framework misalignment (i.e. golang+nodejs+reactjs+bootstrap...with dart a planned addition) and I was easily able to pick out some security and performance issues that are common to LLM-generated Golang. To put this bluntly, dfsg-new-queue [11] "feels" exactly like a bad demo [12].
I felt like my concerns were being ignored, so I forwarded them [13] to DPL, accepted further silence, and disengaged. It feels worth repeating this bit:
> Anyway, there are certainly other people with FTP Team history that would love > to resolve core issues, although it's doubtful any of them would unite without > jumping back to waterfall a complete system--and I'm going to double down on my > outside perspective that you are absolutely at the most perfect point for that.
[8] https://lists.debian.org/debian-devel/2020/03/msg00476.html [9] https://lists.debian.org/debian-devel-announce/2026/01/msg00004.html [10] "Screenshot from 2026-01-05.png", fasalo_review.txt, review_setup.png [11] https://salsa.debian.org/awm/dfsg-new-queue [12] https://github.com/MTecknology/LLM-Demo [13] "Fwd: [michael@lustfield.net: Re: Bits from the DPL].eml"
Appealing Community Team Action - -------------------------------
A few have asked something to the effect of, "why now? why this?" or... "If you were subscribed to d-private@, you would have seen he was in the wrong."
Let me clarify that this is "the [thread] that broke [my] back" because I felt like something brought out of private, to the project, warranted at least an honest review and hoped to head off any drama with a facts-driven response [14]:
1. I stated that no objective position can be drawn from what was shared 2. Asked for some sort of simple explanation 3. Also posed a best-guess hypothetical with simple conclusions 4. Commented on concerning language in the warning email
It is #4 that I want to repeat and focus on:
> That said, I will say that I found the email warning concerning. It engages > debate and creates confusion where it should only be a simple restatement of > facts...something that, if shared, would provide all an outside reader would > need to draw a conclusion.
Looking back at the original email warning [15], I still believe that it:
- - Fails to call out the specific behavior that is problematic - - Leaving ambiguity that yields all-or-nothing assumptions - - Lacks constructive feedback that could guide improved communication - - Comes across as adversarial and emphasizes extreme response - - Phrases expulsion as punitive rather than an unfortunate protection - - Closes any potential dialog that could improve future communication
I also find it very concerning that someone expressed resentment toward Branden for publicly sharing the warning from Debian Community Team. From my perspective, this is akin to bodycam footage that should have been used to improve future reprimands.
Instead, the response was [16] outrage and doubled down on this problematic approach, using language that reinforces a top-down, dismissive posture rather than fostering understanding or improvement. I was particularly concerned by "acts under my delegation and enjoys my full confidence," because it comes across as authoritarian and confirms a defensive and closed process.
Branden reached out privately and the conversation began in a way that would certainly lead to an expected reprimand if conducted on-list, but this was also easily resolved in one single message, with subsequent messages being a mutual apology. To be frank, I suspect this is what was lacking from any historical dispute resolution because it truly was, "oh, sorry, not sure WTF I was reading."
[14] https://lists.debian.org/debian-project/2026/02/msg00058.html [15] https://lists.debian.org/debian-project/2026/02/msg00057.html [16] https://lists.debian.org/debian-project/2026/02/msg00060.html
My Resignation - --------------
My decision to resign [17] was solidified, written, and sent while waiting to board a multi-day return flight to the US, and it came alongside a recognition that both home country and beloved project continue to remain deeply divided. I'm left with the perception that both were great attempts at democracy that gradually turned into a collection of decision makers who more closely resemble an oligarchy.
During a moment of meditation and reflection, I questioned if there is any place for an old greybeard like me to keep trying, despite being continually disillusioned by current direction. When I thought about the silence my concerns received, the answer became loud and clear.
[17] https://lists.debian.org/debian-project/2026/02/msg00063.html
Cheers mates,
- -- Michael Lustfield
This merits attention. Some people in Debian try to silence these views.