Re: Seeking new members for the DFSG team (Re: Bits from the DPL)
On Fri, Nov 07, 2025 at 10:36:40PM +0100, Joerg Jaspert wrote:
> On 17769 March 1977, Andreas Tille wrote:
>
> > > It's a team that was created/delegated without the members actually
> > > asking
> > That response is astonishing to me. The suggestion to split the team
> > originated inside the former ftpmaster team[1] and was raised on
> > multiple occasions.
>
> It does not come from the team. Looking at team communication all (talking)
> are either surprised or pissed off by your set of (planned) actions.
>
> > > So we now have to see how we deal with this
> > > mess that helps nothing at all except for some "Oh i delegated,
> > > magic now
> > > will happen" bullshit believes. Might take a day or three or
> > > something.
> > Unfortunately, no objections or alternative proposals were received, so
> > I proceeded with what seemed the most constructive path forward:
> > creating clearer scopes of responsibility to make it easier for new
> > contributors to join and for existing work to be shared more evenly.
>...
Joerg, are there any constructive suggestions from the team?
The (often underappreciated) positive and negative aspects of the
ftpmaster team have been a long-term pattern, I'd say the large picture
was already similar back when James Troup and Richard Braakman were in
that position. Which is not pure coincidence, a thick skin is clearly
beneficial when a regular part of your job is telling people that you
have to reject their work.
But it is not healthy when this is the general attitude towards change
wanted in the project, and the ftpmaster team has a history of responding
to wanted change either with "no" or by not responding.
I am seeing 3 areas:
1. dak
Like every piece of software used in production for two decades dak has
its good and bad sides. Overall it is working well, and I do not recall
any major technical or security disasters.
2. NEW processing manpower
Thorsten processing NEW on a nearly daily basis is great, but this is a
bus factor of 1 and there have been times where no-one was regularly
processing NEW.
Part of the problem is that the people who are interested in the more
lawyer-like task of copyright review are not necessarily the people
interested in messing with dak internals, NEW processing needs only
user knowledge of dak.
Splitting FTP Assistants into a separate DFSG team is one solution.
Similar to non-uploading DDs, there would also be the option to turn
FTP Assistants into "non-developing ftpmasters" who are full members
of the team.
In any case training/mentoring is required for new members, since
rigorous, transparent and consistent decisions require knowledge
and experience an average DD does not have.
3. Policy changes
The biggest problem is that many policies in the ftpmaster team seem
to exist because that's how they were done 20 years ago, with huge
reluctance against changing anything.
As an example, a huge pain point is debian/copyright handling.
While for the technical side we went from the pre-debhelper times of
writing debian/rules by hand to a 3 line dh sequence, debian/copyright
is still created manually and ftpmaster is forcing people to manually
implement whatever archaic rules someone invented 25 years ago.
And it comes across as completely arbitrary and hostile when some
packages like src:linux get accepted in NEW with a debian/copyright
that would give a reject for most other packages.
A better workflow would be something like:
- a dh_copyright creates and updates debian/copyright
- the build aborts on non-trivial changes[1]
- the maintainer reviews the changes when the build aborted
(including after the initial packaging)
- a more thorough review happens after the initial upload in NEW
In addition to less work for the maintainer, this avoids also the
regular bugs we currently have when upstream of a package changed
the licence 5 years ago and no-one noticed.
It would also be good to discuss with a lawyer what actual legal
requirements are. It is not clear to me whether debian/copyright
is required for legal reasons at all,[2] but I wonder whether our
Release Notes are in full compliance with 4-clause BSD.
DEP-5 in its current form is not usable for reliably determining the
licence situation of a target filesystem, this is something that could
also be improved.
Above are just my personal thoughts on that topic, people might disagree
with part or all of it and implementing something like that would be a
lot of work in any case. The point is that anyone interested in removing
this pain point for maintainers is being deterred by knowing that the
ftpmaster team would likely declare the whole effort a waste of time
afterwards.
Like we had a lot of unnecessary delay and drama around tag2upload,
which included one FTP Master spreading FUD about security issues
without constructive replies when the people who had implemented and
actually reviewed tag2upload asked for details - as response to a GR
proposal[3] that was justified with:
We think that ftpmaster's position lies more in simple conservatism,
being in favour of existing processes by default, than it lies in actual
technical arguments against tag2upload.
q.e.d.
This "simple conservatism" is the biggest problem, and faith is waning
that anything could improve with the current delegation.
Are there any constructive suggestions from the current delegation?
> bye, Joerg
cu
Adrian
[1] PostgreSQL extensions already have such a mechanism for
debian/control, see e.g. #1117275
[2] *for legal reasons*, we want copyright information in the
binary packages in any case
[3] https://lists.debian.org/debian-vote/2024/06/msg00000.html
Reply to: