Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #14107 > unrolled thread

Re: Now what? On FTP Master division into Archive Ops and DFSG Team

Back to article view | Back to linux.debian.project

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Now what? On FTP Master division into Archive Ops and DFSG Team "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2026-01-26 12:40 +0100
    Re: Now what? On FTP Master division into Archive Ops and DFSG Team Simon Josefsson <simon@josefsson.org> - 2026-01-26 16:30 +0100
      Re: Now what? On FTP Master division into Archive Ops and DFSG Team "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2026-01-26 21:10 +0100

#14107 — Re: Now what? On FTP Master division into Archive Ops and DFSG Team

[Multipart message — attachments visible in raw view] — view raw

[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

[toc] | [next] | [standalone]

#14108

[Multipart message — attachments visible in raw view] — view raw

"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

[toc] | [prev] | [next] | [standalone]

#14109

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web