Re: Debian patch review process (was Complaint regarding conduct on bug 1132795)

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