Hi Michael (2026.06.16_19:57:52_+0000)
Thanks for the mail. For complaints about conduct, I think the
community team (who you CCed) are the right people to talk to.
The Debian TC handles technical disputes (which typically boil down to
people struggling to come to agreement for non-technical reasons).
This is our mailing list. The way to formally raise an issue to the TC
is to file a bug against the "tech-ctte" pseudo-bug in the Debian bug
tracker. From a quick read, I don't think you really need to raise that
bug with us, because I don't see any formal action that you want us to
take. It looks like things just got a bit heated on a bug, and you'd
like to understand what comes next.
So, my thoughts on this issue. First, let's deal with the technical
questions:
What I do care about is that I think the experience demonstrated that there
isn't much if any review process for these patches being added. I would
like to understand how Debian ensures that supply chain attacks aren't
being inserted into packages at this packaging layer given they appear to
be able to be landed by a single Debian Developer without any internal
review. Surely this class of attacks should be of concern to Debian just as
much as people's freedom to own and change the software they run?
You asked about supply chain attacks. Generally in Debian packages are
managed at the discretion of their maintainers. In this case the
maintainers are a group of people on a mailing list, the "Debian
PhotoTools Team". I don't know anything about this team, and can't see
any documented team processes. Most of the larger teams in Debian have
more clearly defined process.
So, I'd expect that in practice any member of the team can upload any of
the packages under its umbrella, with any change they wish. Other team
members may follow changes in git, and may follow-up with changes or
raising questions, if they feel the need. That's how things work in
almost every package in Debian.
To get the right to do this in Debian, you need to get through Debian's
NM process (vetting technical understanding, ethical alignment, and to
some degree fit, on recommendation of a project member). You also need
to get added to the team in question, which is probably something only a
small number of team owners can do.
Alternatively, you need to get through Debian's (much easier) DM
process (vetting some technical ability, and the recommendation of a
project member). Then a project member needs to grant you upload access
to the package in question.
The person applying this patch is a full Debian project member.
I think the bar to entry is higher than most other free software
projects, that I've been involved in.
Generally, it's in the interest of package maintainers to form a
friendly working relationship with their upstream. I'm sorry that that
isn't the case here.
Then, the social questions:
I see some behaviour here that I agree is not ideal. Notably:
1. Forwarding bugs as a 1-line link to another bug is probably not what
I'd do. But I also don't see any real problem with it, it looks like
reports like that have been accepted and acted on in the past (e.g.
#1123747)
2. Random users raising bug severity is not polite. Typically the
package maintainer (or other project members like the release team)
decides the severity. But again, no real harm done here.
3. The response about filing bugs in 25yr old software on the Debian BTS
seems a little passive aggressive to me. I don't think that was called
for.
I understand the submitter calling that out and questioning it, but
also at this point everything going downhill is completely
unsurprising.
4. Calling out a developer for using AI tools is not polite. (Although
there's a sizeable community within Debian that has serious concerns
about these tools.)
But it's also factual and to the point. I think at this point
everybody is a bit confused and trying to figure out what's going on.
5. Describing somebody publicly as "clearly unwell", based on such a
fleeting interaction really isn't OK.
Obviously things are now going to escalate, and they do.
6. Applying a patch over the objection of an upstream, is something I
would try not to do. Sometimes it's necessary, but I would be careful
with that.
Also, in this case the patch is described as being "forwarded" to the
upstream bug, but I don't see any MR upstream, or any mention in the
upstream bug of applying this patch.
I'm not even going to try to describe actions in the rest of the thread,
it's just continuing to escalate and ... well here we are.
Things that some people may raise issue with, but I think are OK in
principle:
1. Users filing bugs in the Debian BTS rather than with the upstream.
In some cases, something Debian is doing is different enough that the
bug only affects Debian. Some upstreams do *not* want to receive bugs
that would fall into this category.
Debian's BTS is open (if arcane). In many cases it's easier for users
to file a bug with us than to create an account on another system.
It's not ideal to be forwarding bugs upstream in this case. But I'm
grudgingly willing to do it, when I agree with the bug.
2. Asking users to provide a patch is probably not appropriate in many
cases, but I think it is OK to say effectively "I am not going to
spend any time working on this, but I'll review a patch if somebody
writes one".
3. Carrying patches to upstream code is fine.
Of course almost everyone involved here is not speaking English as their
first language, so we need to understand that. I don't know many of the
people involved, but I think patience and understanding is almost always
the answer. Clear communication is hard, even for those of us who are
native English speakers.
I would encourage you to clearly state your opinions on the patch, if it
concerns you. Or apply it yourself if you agree with it (which I gather
you don't).
Stefano
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
