[redirecting to -project, as this is off-topic for -devel]
At 2026-01-26T11:46:02+0100, Andrea Pappacoda wrote:

Il giorno 26 gen 2026, alle ore 00:35, Daniel Gr”ber
<dxld@darkboxed.org> ha scritto:

I have drafted this mail in collaboration with members of the new
DFSG Team, other members of Community Team and the DPL.

It would?ve been nice to also include members of the former FTP team
in the drafting process. I don?t know if it has been attempted,

Imagine yourself in the position of DPL for a moment.
There are several possibilities.
1. The DPL solicited feedback from the FTP team.
a. The team responded with hostility.
b. The team did not respond at all.
c. The team responded with impractical or unconstitutional
proposals.
2. The DPL didn't solicit feedback from the FTP team, because the DPL
doesn't have a good working relationship with the delegates.
a. Perhaps past communications from team members have been hostile.
b. Perhaps past communications from team members have been
nonexistent; their feedback has been solicited and none has been
received.
c. Perhaps, in past communications, team members have made demands
that the DPL cannot fulfill, either because they are contrary to
the DPL's understanding of the Constitution (and perhaps the
Project Secretary's too, if the Secretary was consulted), or the
DPL's pledges to the membership that resulted in his election to
the office.
3. The DPL didn't solicit feedback from the FTP team for a reason that
would reflects poorly on the DPL if disclosed.
a. The DPL forgot that the FTP team existed.
b. The DPL had a good working relationship with the team but has
decided to deliberately undercut them anyway.
None of the foregoing paint an attractive picture of the Debian Project.
If you want the occupant of an elected office to be "politic", that is
to present the Debian Project's best face to the world and to its own membership, asking that a communication, of the kind you're replying to,
convey this sort of information is inconsistent with your goal.
In other words, if you hold to the simple principle that "if you can't
say something nice, don't say anything all", then the reason nothing was
said on the matter was that there was nothing nice to say.
Myself, I think it irresponsible to hold rigidly to that principle, but
I've certainly had my share of conflict with people who did, yet who
exempted themselves from it for the sake of challenging me on the point.
It's worthwhile to take note of people who cultivate more ways of
shutting discussions down than advancing them to productive action.

but it would?ve probably helped avoiding not-so-nice feelings for some people.

I think it's more likely that more negative discussion was avoided, but
we can't know such a thing with certainty. Alea iacta est.

This, among other things, contributes to my thought in the back of my
head of the former FTP team being replaced without really them being
listened to.

That's one possibility. Another possibility is that team members wanted
to be left alone to work without interference or account to anyone,
except at their own complete discretion.

Maybe this was actually attempted, and the team wasn?t collaborative,
but I think that a mail like this should do its best at avoiding
people doing speculations like this one of mine.

Given the foregoing scenarios, how would you have achieved that?

Hope things are not as bad as I think! Bye :)

You may never know, or never get to find out except by approaching a well-connected and/or well-informed person at a DebConf. Show some
initiative and you, too, can be an "insider".
Myself, I'm dubious of the wisdom of the Debian Project stratifying
itself in such a manner, but that die was cast too, a long time ago.
Regards,
Branden


--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

[sending this message to -project; it's off-topic for -devel]
At 2026-01-26T10:59:39+0100, Thorsten Alteholz wrote:

On 26.01.26 00:25, Daniel Gr”ber wrote:

That state of affairs ultimately led to one team member carrying the
vast majority of, the team's ongoing package review workload.

Most recently [96.87%] of it to be exact.

For years now.

With no change in sight.

Let that sink in for a minute.

[96.87%]: https://lists.debian.org/debian-devel/2025/11/msg00222.html

While this level of dedication to Debian volunteer work is truly
admirable the imbalance in workload is not a hallmark of a
well-functioning team and has resisted repeated attempts at
improving the situation.

Within the Debian community, there have long been complaints about
the unpredictability of NEW processing time as well as
nontransparent and rigid policy on both licensing and technical
aspects.

Along with the team's existing challenges this has created palpable frustration among Debian Developers, package Maintainers, and,
reportedly, even more far-flung members of our community alike.

While /effectively/ single-person teams are an unfortunate reality
in some areas of Debian it's simply not a sustainable state of
affairs for one of *the most foundational* areas of our project.

wow, from a team member dealing with one task to a single-person team
within a few lines of text.

I have my own issues to raise with Daniel's mail, but I'll save (some
of) them for a separate message.

Why don't you mention the other tasks that other team members had been working on?

How are people to know what those are? Are all of them within the
team's delegation charter? If not, what else have the members been
doing ex officio but without delegated authority? With that
information, the DPL can amend a delegation's charter if necessary and appropriate. Does that delegated team produce reports to the DPL or to
the membership as a whole? How frequently? How detailed are these?

Do you assume that only one person on the team was doing anything or
does this not fit into the argument why a complete team had to be
dumped?

It is the responsibility of a delegate under the Debian Constitution to
be accountable to the Project Leader and to the membership as a whole.
The Debian Project is explicitly democratically organized, which means ultimately that all powers and authority ultimately arise from
collective will and sufferance of its membership.
Because we commit ourselves to not hiding problems (Social Contract ?3),
I personally think it would be best if delegates made reports to the
entire community of Debian Developers in almost all circumstances.
In the Debian Project, among certain teams in particular, there is a
tradition, reinforced over multiple decades, of avoiding accountability
or even basic communication about the conduct of delegated
responsibilities.

This email is insulting and makes me really angry.

That's not a helpful comment as such. Anger is fine, in my opinion, but
you should take the time to work out what, specifically, is rousing your emotional response. I'll guess that you have an expectation that is not
being met. You will make yourself better understood if you articulate
that expectation explicitly.
Sometimes, when we do this, the expectation we express comes across as
sounding unreasonable. And even after spending some time wordsmithing
it, it still seems that way.
That is because we sometimes have unreasonable expectations.
On the other hand, sometimes when we express reasonable expectations,
people get angry with us--or, if empowered, carry out reprisals against
us for stating them. While unpleasant, such episodes have great
informational worth; see below regarding the presumption of good faith.

Even the Community Team, who should protect the Debian community
against such things,

Where is it written in the Community Team's delegation charter that
their job is to protect Debian Developers from experiencing feelings of
anger? The Community Team is not empowered to dispose of our humanity,
and I submit that it would be a dreadful threat to us if it were.
Being human means experiencing negative feelings sometimes. Being an
adult means managing those feelings responsibly and pro-socially.
I've complained before about paternalistic attitudes among some people
in this project. With this statement you are practically beseeching
someone to be "daddy" and protect you from negative feelings.
That attitude, whether I'm right about you in particular holding it or
not, is deeply unhealthy in a commonwealth of adults engaged in a
cooperative venture.

did support this content.

Apparently. When I get some time I'll offer my view on that.

But one has to always assume good faith.

I've never seen this principle so ill applied as in the Debian Project.
A presumption of good faith is something one has in lieu of evidence.
That presumption is a tool to start, in relative comity, encounters
between people who are not well known to each other.
When you have _evidence_ that is difficult or impossible to reconcile
with a presumption of good faith, the presumption is overturned.
If someone suggested that the Debian Project should continue to treat,
say, Daniel Pocock with a presumption of good faith, I predict they'd be laughed at in their face.
...or someone would say they're "really angry", as you have.

How did Debian end up like this?

That's an _excellent_ question. I propose that Debian Developers (and
Debian Maintainers) spend time thinking for themselves about it. In particular, they should not divert themselves by looking to a paternal
figure, of a disposition kindly or otherwise, to locate a perspective
they can adopt uncritically.
Regards,
Branden


--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

"G. Branden Robinson" <g.branden.robinson@gmail.com> writes:

How did Debian end up like this?

That's an _excellent_ question. I propose that Debian Developers (and
Debian Maintainers) spend time thinking for themselves about it.

There are many things involved here, but the social consequences of
having a 'Maintainer:' field for packages, and no central version
control system for development, explains a lot to me. Group
maintainance is great, but it is a workaround for something else.
/Simon


--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

At 2026-01-26T15:55:52+0100, Simon Josefsson wrote:

"G. Branden Robinson" <g.branden.robinson@gmail.com> writes:

How did Debian end up like this?

That's an _excellent_ question. I propose that Debian Developers
(and Debian Maintainers) spend time thinking for themselves about
it.

There are many things involved here, but the social consequences of
having a 'Maintainer:' field for packages, and no central version
control system for development, explains a lot to me.

I don't agree. While I can see how it's tempting to imagine that in
early years, Debian developers adapted the "maintainership"
concept to all administrative functions, that doesn't explain how we
ended up, even before the Debian Constitution was drafted, with "teams"
that weren't really "teams", but instead individuals who viewed
themselves as as functionally isolated from their teammates as they were
from any other Debian Developer.
Having now stated it thus, maybe you're right!

Group maintainance is great, but it is a workaround for something
else.

I once read, on the Web, someone crediting me with innovating the
concept of team maintainership when I announced the "X Strike Force" for managing the unwieldy monolith of XFree86 packaging for Debian.[1]
I don't know if that's true. I don't remember copying the idea from
anyone, but it could have been in the air. What I recall of my
intentions was that the XFree86 package bug list was gigantic and after
some long duration (measurable in years), I felt I was making little
headway in burning that list down to zero. I fixed many, many bugs, but
new ones seemed to come up with as much or even greater frequency.[2]
That was the reason for the name "X Strike Force". Being a typical
American, I imagined that the solution to a persistent problem was to
bomb it into submission by bringing more resources to bear on it.
(Had I been a clever Brit, maybe I'd have taken a Churchillian approach
of employing chemical weapons rather than uncouth explosives.[4])
In any case, I'd say the primary and best justification for team
maintenance is the same as for any co”perative effort in labor: the
scale of the task exceeds the resources of a single diligent human.
Regards,
Branden
[1] https://lists.debian.org/debian-devel-announce/2003/06/msg00000.html
[2] The foregoing URL touts the adoption of Subversion for management of
the package. For my first few years maintaining XFree86, I did so
without the benefit of any revision control system at all.[3] As
I've said before on this point--I was _completely insane_. That, or
CVS was so horrible to use that a nullity was preferable.
[3] A more sober claim might be that I used my Debian package releases
as a snapshotting mechanism, and composed extensive change log
entries to make a sort of audit trail. At the time, some people
grumbled about the length of those change logs just as they complain
about my emails today. Yo, people don't join up to READ STUFF.
[4] https://www.theguardian.com/world/shortcuts/2013/sep/01/winston-churchill-shocking-use-chemical-weapons


--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)