DPL: friction in Debian?

[Lars Wirzenius]

A question to the sole candidate:

What is the biggest source of friction, in your opinion, in Debian
development? What do you propose to do about reducing it?

By friction I mean things that do not hinder things, but increases the
effort required. For example, having to wait for bts.debian.org spam
filtering to process one's new bug report.

[Lars Wirzenius]

Post by Lars Wirzenius
What is the biggest source of friction, in your opinion, in Debian
development? What do you propose to do about reducing it?
By friction I mean things that do not hinder things, but increases the
effort required. For example, having to wait for bts.debian.org spam
filtering to process one's new bug report.

After sleeping on it, I'd like to clarify my question a little.

Given that the DPL doesn't actually lead the technical developoment
work of Debian, I'd be most interested in non-technical sources of
friction. For example, processes, organisational structure, an
resource congenstion.

[Chris Lamb]

Dear Lars,

Firstly, my sincere apologies for the delay in getting back to you
on this. It kept bubbling up to the top of my TODO only to be replaced
by other concerns, not least of which included some sleep.

I hope others are not deterred from writing to -vote based on the
tardiness of this reply!

given that the dpl doesn't actually lead the technical developoment
work of debian, i'd be most interested in non-technical sources of
friction. for example, processes, organisational structure, an
resource congenstion.

That's a very deep question with no possible short reply. :)

I wouldn't deny that there are some processes that could be improved or
otherwise streamlined (NEW, some specific team interactions,
reimbursements, etc.) but I wouldn't agree with Rousseau that «man is
born free but everywhere in chains»... at least in the context of
Debian.

I am very interested in (and read a lot about) the psychological and
social aspects of software development and on wider topics of
"productivity" in general.

This has led me to believe that most of the "congestion" you refer to
probably happens in people's own minds and is not necessarily imposed
by some outside structure.

For example, I see a lot of Developers are "shy" about putting themselves
forward on the (stated) grounds that they don't believe they are qualified,
a particular project "belongs" to someone else, or even that "they are not
100% certain it is a bug" yet so they don't end up filing anything in the
BTS. This is often quite tragic and a little painful for me to watch from
a distance.

Moving the culture so that people feel freer to make more mistakes — even
non-reversible ones! — would not only would encourage more contributions
in a purely numerical sense, it would also make Debian development more
welcoming and, frankly, more fun for all.

We already know how to do this, such as not biting each other's heads off
of appearing to gloat in others' blunders, we just need to be more careful
in our own interactions and — perhaps — gently nudging others when they
cross over the line in their admonishments.

Again, that's not to say some parts of the organisation could do with
tidying up. Indeed, often the situation could be dramatically improved
simply by communicating *why* there is some rule or process in place,
otherwise it can be viewed as just a tedious process or even interpreted
as a deliberate attempt to centralise power.

Just as one example, the NEW queue process certainly has some of these
"Chesterton's Fences" [0] at the moment, and making it more transparent
and descriptive in places would — even without changing any underlying
process at all, which I do note is also being discussed — would vastly
improve the sentiment about that.

[0] https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence


Best wishes,

[Adrian Bunk]

Post by Chris Lamb
...
Just as one example, the NEW queue process certainly has some of these
"Chesterton's Fences" [0] at the moment, and making it more transparent
and descriptive in places would — even without changing any underlying
process at all, which I do note is also being discussed — would vastly
improve the sentiment about that.
...

As delegation the ftp team gets its powers directly from the DPL,
so (except for a GR) there is noone except the DPL with the power
to push for improvements.

A constant source of frustration is the intransparent licence
checking process in NEW, and intransparency regarding what the
ftp team considers mandatory for debian/copyright.

In real life most of us are used to having to comply with pointless
rules, and the motivation for doing so is the money we get.

In a volunteer project there is less incentive to follow rules that
appear to be pointless and only designed to create additional work,
set by people with absolute powers to enforce their decisions.

There is a real risk that people might be leaving the project out of
frustration caused by such intransparent decisions.


Some packages get rejected for reasons that appear to be arbitrary and
pointless, or there is nitpicking on things where it isn't clear for
what legal reason the ftp team requires these.

Other packages where even a cursory look at debian/copyright reveals
huge problems pass NEW with no complaints and in no time.


IMHO it would be good to have:
1. documented what exactly the requirements are for debian/copyright
2. documented for what legal reasons they are required
3. a clear rule that the above is applied to all packages without any
exceptions

Do you agree that this would be desirable?

If yes, what would you consider a reasonable schedule for the ftp team
delegation to provide and implement this?


Thanks
Adrian

BTW: When I use the word "appear" this means that something is
perceived as being this way, and it is possible that there
is a good reason that is just not communicated properly.

- --

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

[Chris Lamb]

Hi Adrian,

Post by Adrian Bunk
A constant source of frustration is the intransparent licence
checking process in NEW, and intransparency regarding what the
ftp team considers mandatory for debian/copyright.

Thanks for your question. So, I won't specifically respond to any of
the separate sub-issues in this area (transparency vs inconsistency
vs legality, etc.) and humbly beg that we leave that to a more
appropriate list to avoid this thread going off-topic too soon. I'm
sure you know how these things work.

So, I completely agree that the current situation is in a very bad
way. Indeed, it is not sustainable for the ftp-team itself.

I've recently been in direct discussion with the ftp-team members on
this, both electronically and IRL, specifically requesting that it
be included in the agenda for upcoming sprint in April. Unfortunately,
I will not be able to attend this myself to persue the issue in person.

I also totally acknowledge that there is a wide gap between perception
and reality here & further ACK that this makes difference whatsoever
for anyone needing to interact with NEW. It was wise of you to imply
that communication is critical.

With regard to your request for a timeline or schedule, whilst targets
of this kind can often help prioritisation and focus work, applying my
best judgement I do not believe that imposing an ultimatum on the ftp-
team to be the best way forward here.

I have always instinctively felt such things to be antithetical to the
spirit of Debian development so should only be applied in extreme
circumstances. With respect to the frustrations expressed here and
elsewhere, I don't believe we have reached that point just yet.

Post by Adrian Bunk
rules that appear to be pointless and only designed to create
additional work set by people with absolute powers

[…]

Post by Adrian Bunk
reasons that appear to be arbitrary and pointless, or there
is nitpicking

[…]

Post by Adrian Bunk
a real risk that people might be leaving the project

I'm afraid I simply can't reply without making a more general comment
with respect to this kind of argument style.

Don't get me wrong, I *completely* understand and empathise with the
frustrations here, but do we really want to a culture in Debian where
it is acceptable to publically belittle others' efforts using such
emotionally loaded words or in such a combatitive / adversarial manner?

I'm sure many Developers have thick skins and perhaps even take pride
in conversing in an "objective" way, but do we really think this is best
way as a Project to get things done? I personally don't and I believe
that the silent majority not find satisfication, purpose or enjoyment
from such a community.

If you will permit me to exaggerate for a moment, if anybody is leaving
the Project it is due to sustained exposure to such low-level
toxicity. :(


Best wishes,

[Adrian Bunk]

Post by Chris Lamb
Hi Adrian,

Hi Chris,

Post by Chris Lamb
...
I have always instinctively felt such things to be antithetical to the
spirit of Debian development so should only be applied in extreme
circumstances. With respect to the frustrations expressed here and
elsewhere, I don't believe we have reached that point just yet.

Post by Adrian Bunk
rules that appear to be pointless and only designed to create
additional work set by people with absolute powers

[…]

Post by Adrian Bunk
reasons that appear to be arbitrary and pointless, or there
is nitpicking

[…]

Post by Adrian Bunk
a real risk that people might be leaving the project

I'm afraid I simply can't reply without making a more general comment
with respect to this kind of argument style.
Don't get me wrong, I *completely* understand and empathise with the
frustrations here, but do we really want to a culture in Debian where
it is acceptable to publically belittle others' efforts using such
emotionally loaded words or in such a combatitive / adversarial manner?
BTW: When I use the word "appear" this means that something is
perceived as being this way, and it is possible that there
is a good reason that is just not communicated properly.

For many people who are not a member of the ftp team,
the actions of the ftp team have a clear adversarial
effect on both the work and motivation.

When something does "appear to be arbitrary and pointless" the problem
might be either an actual arbitrary decision or just a lack of
communication regarding the rationale.

Post by Chris Lamb
I'm sure many Developers have thick skins and perhaps even take pride
in conversing in an "objective" way, but do we really think this is best
way as a Project to get things done? I personally don't and I believe
that the silent majority not find satisfication, purpose or enjoyment
from such a community.
If you will permit me to exaggerate for a moment, if anybody is leaving
the Project it is due to sustained exposure to such low-level
toxicity. :(

There are two orders of magnitude of people more in the project that
need a thick skin due to the toxity of the intransparent NEW handling
of the ftp team than there are members in the ftp team.

The silent majority just tends to be on the "follow the orders of the
ftp team no matter whether they make sense" side of things, since there
is nothing short of a GR a normal DD could do about it.

Publishing the rules with a clear rationale would bring transparency,
reducing the frustration about this.

In some cases it would be clear why the ftp team makes some decisions,
in other cases it might even reveal that a rule does not make sense and
could be abolished.

As an example for a rule that does not make sense, recently a member of
the ftp team stated on debian-devel that the contents of NEW cannot be
made available to people outside the ftp team since it might not be
distributable, and that this is not expected to be changed.

It was quickly pointed out to this member of the ftp team that most of
the time exactly this contents is already publicly distributed by Debian
on alioth/salsa by the time it enters NEW.

There are options to improve the situation for everyone in Debian
(including the ftp team) once there is transparency on the rules
and the rationale.

Post by Chris Lamb
...
With regard to your request for a timeline or schedule, whilst targets
of this kind can often help prioritisation and focus work, applying my
best judgement I do not believe that imposing an ultimatum on the ftp-
team to be the best way forward here.
...

The ftp team has repeatedly stated that it is working as a team and
that decisions are not arbitrary decisions by individual team members.

This implies that for tasks like NEW handling there exist guidelines
in some form, that might need some polishing before publication.

The ftp team is granted powers over the work of all people in Debian
directly from the DPL, and the only person in the project who is able
to push for improvements in this area is the DPL.

The only alternative would be a GR to override the DPL decision
regarding the ftp team delegation, and no matter the outcome this
would be ugly.

It is therefore disappointing when a DPL candidate tries to wiggle out
of making a commitment to get such a longstanding conflict inside the
project resolved within a reasonable amount of time.

Post by Chris Lamb
Best wishes,

cu
Adrian

[Adam D. Barratt]

The ftp team is granted powers over the work of all people in Debian 
directly from the DPL,

To be slightly picky here, and possibly veering a little off the topic,
the FTP Masters are delegated. Any powers that the remainder of the
team have only exist in so far as the FTP Masters extend them. (My
understanding is that unlike, for instance, the Release Team, the FTP
Team still has technical restrictions in place which affect what
members of the team can do - e.g. only FTP Masters can deploy changes
to dak or the projectb database.)

Regards,

Adam

[Russ Allbery]

Post by Adrian Bunk
The ftp team has repeatedly stated that it is working as a team and
that decisions are not arbitrary decisions by individual team members.
This implies that for tasks like NEW handling there exist guidelines
in some form, that might need some polishing before publication.

People often assume there's some sort of "real" documentation for what is
and isn't acceptable, but it's being kept secret from the rest of the
project, and point to the above as a justification for that belief.

However, I think it's worth realizing this isn't necessarily true. A
group can share a consensus opinion without having written documentation
in the case where training is via mentorship and apprenticeship rather
than through written instruction. And I believe that's exactly the case
for FTP master. The team arrives at the same practices because they are
taught the same practices through apprenticeship, IRC discussions, and
corrected practice, not because there's some secret reference manual.

So yes, in some sense there are some guidelines, but they could well be
entirely unwritten tribal knowledge that has been communicated through
innumerable fragmentary IRC conversations and in-person chats. Which
means that turning them into something that can be given to the rest of
the project as reference is still extremely difficult.

Unfortunately, due to the nature of this ongoing discussion, there's also
now a ton of *pressure* around the first release of that document. It
would be met with a ton of scrutiny and discussion, which makes it even
harder to be the one to put oneself on the line and try to write down
unwritten tribal knowledge, possibly incorrectly or incompletely.

[Adrian Bunk]

Post by Russ Allbery

Post by Adrian Bunk
The ftp team has repeatedly stated that it is working as a team and
that decisions are not arbitrary decisions by individual team members.
This implies that for tasks like NEW handling there exist guidelines
in some form, that might need some polishing before publication.

People often assume there's some sort of "real" documentation for what is
and isn't acceptable, but it's being kept secret from the rest of the
project, and point to the above as a justification for that belief.
However, I think it's worth realizing this isn't necessarily true. A
group can share a consensus opinion without having written documentation
in the case where training is via mentorship and apprenticeship rather
than through written instruction. And I believe that's exactly the case
for FTP master. The team arrives at the same practices because they are
taught the same practices through apprenticeship, IRC discussions, and
corrected practice, not because there's some secret reference manual.
So yes, in some sense there are some guidelines, but they could well be
entirely unwritten tribal knowledge that has been communicated through
innumerable fragmentary IRC conversations and in-person chats. Which
means that turning them into something that can be given to the rest of
the project as reference is still extremely difficult.

It is also a technical process that is executed
~ 1000 times each year, by 10 different people.

Post by Russ Allbery
Unfortunately, due to the nature of this ongoing discussion, there's also
now a ton of *pressure* around the first release of that document. It
would be met with a ton of scrutiny and discussion, which makes it even
harder to be the one to put oneself on the line and try to write down
unwritten tribal knowledge, possibly incorrectly or incompletely.

The main problem might well be whether it has to justify all past
actions of the tribe as correct under the new rules, or whether
it is seen as part of an effort that might result in changed rules.

I already mentioned "contents of NEW cannot be made available" as
an example of tribal knowledge that stopped making sense years ago.

I also suspect there might be tribal rules that are strictly applied to
all packages, except some packages like src:linux that are too important
to be rejected.

In such cases it might be most convenient for the tribe to simply delay
everything until the day when the President of the United States
releasees his tax returns. Perhaps not even intentionally, but it can be
painful when you have to question whether some things you have enforced
for years actually make sense.

cu
Adrian

[Joerg Jaspert]

Post by Adrian Bunk
As an example for a rule that does not make sense, recently a member of
the ftp team stated on debian-devel that the contents of NEW cannot be
made available to people outside the ftp team since it might not be
distributable, and that this is not expected to be changed.

Like it or not, but there *is* a big difference in the project making
something available for the big wide world (which a public NEW would
be), or a user putting it somewhere readable for everyone even though
the latter might be using project resources too. Sure, this is an
argument for making salsa restricted too and have NEW processing on any
project there, and be safe(r). *I* dont want that, you seem to advocate
for it.

[Adrian Bunk]

Post by Joerg Jaspert

Post by Adrian Bunk
As an example for a rule that does not make sense, recently a member of
the ftp team stated on debian-devel that the contents of NEW cannot be
made available to people outside the ftp team since it might not be
distributable, and that this is not expected to be changed.

Like it or not, but there *is* a big difference in the project making
something available for the big wide world (which a public NEW would
be), or a user putting it somewhere readable for everyone even though
the latter might be using project resources too.

What is the big (legal) difference between distributing something
from the Debian group on the Debian machine salsa.debian.org, and
distributing the same from a different Debian machine?

Post by Joerg Jaspert
Sure, this is an
argument for making salsa restricted too and have NEW processing on any
project there, and be safe(r). *I* dont want that
...

Someone uploads something to NEW, and Debian does currently not make it
available for the big wide world.
Someone uploads something to salsa, and Debian does make it available
for the big wide world.

Uploading to NEW is restricted to DDs.
Uploading to salsa is not restricted.

Since Debian distributing whatever random people upload to salsa
is fine for you, I fail to see the point why you would consider
distributing what is in the DD-only NEW a huge problem.

In a sidenote, the trivial way to solve "make the contents of NEW
available to more people" would be making the Vcs-Browser: link
available at [1] (it is already visible at the subpage for each package).
For the vast majority of packages in NEW, this will point to the Debian
machine that already makes the contents available for everyone.

Post by Joerg Jaspert
bye, Joerg

cu
Adrian

[1] https://ftp-master.debian.org/new.html

[Joerg Jaspert]

Post by Adrian Bunk
Since Debian distributing whatever random people upload to salsa
is fine for you, I fail to see the point why you would consider
distributing what is in the DD-only NEW a huge problem.

It is not fine. But I've chosen to not go down the road that would be
needed here. I've got enough on my plate, I can't put this on.

If someone does go down the road, then any project creation on salsa
would possibly end up needing to be vetted by an admin (or a new team
doing this, or a combination of new team and NEW handling, as parts of
this surely could be merged then).

Right now, the handling of stuff on salsa follows what was done for
alioth "It may have a .debian.org, but its not run by Debian, so the
project chose to ignore parts of the problems with it". And implicitly
either put it onto the shoulders of the alioth admins, or the individual.

There is an argument for this having changed now, with the new setup,
yes, but following that opens such a big can, I don't want to do this.
Thats something the DPL might want to get some informed (ie. lawyers)
opinion on, how free that service can be.

I would love for the outcome of that to be something like "It's fine if
open, as long as there is a contact that quickly disables reported
$legalfoo violations".

Also, in a way we do assume people NOT intentionally putting bad stuff
up, though the current system does make it farely easy to play bad here.

[Adrian Bunk]

Post by Joerg Jaspert

Post by Adrian Bunk
Since Debian distributing whatever random people upload to salsa
is fine for you, I fail to see the point why you would consider
distributing what is in the DD-only NEW a huge problem.

It is not fine. But I've chosen to not go down the road that would be
needed here. I've got enough on my plate, I can't put this on.

The sensible time for anyone to bring up this topic would have been
during or before the Alioth replacement sprint.

I am not involved with salsa, but this kind of changes tend to be a
lot less work when they are included in the planning phase, instead
of changes to a heavily used running system.

Post by Joerg Jaspert
If someone does go down the road, then any project creation on salsa
would possibly end up needing to be vetted by an admin (or a new team
doing this, or a combination of new team and NEW handling, as parts of
this surely could be merged then).

If someone does go down the road, the most likely result will be to
decommission salsa:

With a bureaucratic process in place that might take weeks just for
getting a new git tree approved, most people would consider external
places like GitHub much more attractive and use these instead.

At that point it might no longer make sense to spend scarce Debian
resources on server maintainance and contents vetting.

Post by Joerg Jaspert
Right now, the handling of stuff on salsa follows what was done for
alioth "It may have a .debian.org, but its not run by Debian, so the
project chose to ignore parts of the problems with it". And implicitly
either put it onto the shoulders of the alioth admins, or the individual.

So in case of problems with contents on salsa, we expect that the
salsa administrators will pay all legal expenses out of their own
pockets without any support from Debian?

Post by Joerg Jaspert
There is an argument for this having changed now, with the new setup,
yes, but following that opens such a big can, I don't want to do this.
Thats something the DPL might want to get some informed (ie. lawyers)
opinion on, how free that service can be.
I would love for the outcome of that to be something like "It's fine if
open, as long as there is a contact that quickly disables reported
$legalfoo violations".

If that's the outcome, it would be great.

Post by Joerg Jaspert
Also, in a way we do assume people NOT intentionally putting bad stuff
up, though the current system does make it farely easy to play bad here.

This a fair assumption for the DD-only NEW, but not for salsa.

Post by Joerg Jaspert
bye, Joerg

cu
Adrian

[Adam Borowski]

Post by Adrian Bunk

Post by Joerg Jaspert
If someone does go down the road, then any project creation on salsa
would possibly end up needing to be vetted by an admin (or a new team
doing this, or a combination of new team and NEW handling, as parts of
this surely could be merged then).

If someone does go down the road, the most likely result will be to
With a bureaucratic process in place that might take weeks just for
getting a new git tree approved, most people would consider external
places like GitHub much more attractive and use these instead.

And what about badly licensed or wholly copyrighted by EvilCorp patches in
the BTS? Or even, whole tarballs attached to bug reports?

Or the mailing list, for that matter. You also can have attachments, or put
short but sensitive pieces inline, like:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Post by Adrian Bunk

Post by Joerg Jaspert
There is an argument for this having changed now, with the new setup,
yes, but following that opens such a big can, I don't want to do this.
Thats something the DPL might want to get some informed (ie. lawyers)
opinion on, how free that service can be.
I would love for the outcome of that to be something like "It's fine if
open, as long as there is a contact that quickly disables reported
$legalfoo violations".

You can't have basically any user contributions if you'd require
pre-approval. So, having just this one piece pre-approval rather than
removal-upon-report is inconsistent.

Post by Adrian Bunk

Post by Joerg Jaspert
Also, in a way we do assume people NOT intentionally putting bad stuff
up, though the current system does make it farely easy to play bad here.

This a fair assumption for the DD-only NEW, but not for salsa.

DDs are already trusted wrt adding extra stuff to existing packages, giving
them access to this temporary holding ground is reasonable. Anyone else,
even a DM, needs to seek a DD's review. Yet we allow anyone untrusted to
put any crap on Salsa.

Copyright is a bad enough drain on the world already, let's not suffer more
due to a tight _inconsistent_ interpretation.

Plus, there's already a mechanism for removing things from NEW. There's a
fat button emblazoned with "REJECT" in all-caps.


Meow!

[Paul Wise]

Post by Adrian Bunk
What is the big (legal) difference between distributing something
from the Debian group on the Debian machine salsa.debian.org, and
distributing the same from a different Debian machine?

The big difference appears to be the Social Contract (and DFSG), which
we generally don't seem to apply to alioth/salsa, especially because
they often contain full upstream development history, which might or
might not contain non-free material.

[Adrian Bunk]

Post by Paul Wise

Post by Adrian Bunk
What is the big (legal) difference between distributing something
from the Debian group on the Debian machine salsa.debian.org, and
distributing the same from a different Debian machine?

The big difference appears to be the Social Contract (and DFSG), which
we generally don't seem to apply to alioth/salsa, especially because
they often contain full upstream development history, which might or
might not contain non-free material.

No, this is not about the Social Contract, the DFSG, or any other
policies how we choose to divide our archive.

After a non-free package passes NEW it will be distributed by
Debian machines and Debian mirrors, just as we have pledged
in the Social Contract.

Non-free material is not a problem here.
Non-distributable material is what we are talking about.

Post by Paul Wise
bye,
pabs

cu
Adrian

[Didier 'OdyX' Raboud]

Post by Adrian Bunk

Post by Joerg Jaspert
Like it or not, but there *is* a big difference in the project making
something available for the big wide world (which a public NEW would
be), or a user putting it somewhere readable for everyone even though
the latter might be using project resources too.

What is the big (legal) difference between distributing something
from the Debian group on the Debian machine salsa.debian.org, and
distributing the same from a different Debian machine?

People are mirroring the Debian pool under a set of well-understood norms, as
that's what the Debian project "produces" (think of the mirror network, people
pressing CDs, etc). A .deb in a Debian suite in the Debian pool isn't
comparable to a random .deb, as only the former has the Debian-seal-of-
approval (DFSG & fulfills releasability criterias).

Salsa is not meant to be mirrored by third-parties, and really shouldn't.

Cheers,
OdyX

[Andrey Rahmatullin]

Post by Didier 'OdyX' Raboud

Post by Adrian Bunk

Post by Joerg Jaspert
Like it or not, but there *is* a big difference in the project making
something available for the big wide world (which a public NEW would
be), or a user putting it somewhere readable for everyone even though
the latter might be using project resources too.

What is the big (legal) difference between distributing something
from the Debian group on the Debian machine salsa.debian.org, and
distributing the same from a different Debian machine?

People are mirroring the Debian pool under a set of well-understood norms, as
that's what the Debian project "produces" (think of the mirror network, people
pressing CDs, etc). A .deb in a Debian suite in the Debian pool isn't
comparable to a random .deb, as only the former has the Debian-seal-of-
approval (DFSG & fulfills releasability criterias).
Salsa is not meant to be mirrored by third-parties, and really shouldn't.

But that equally applies to NEW.

[Chris Lamb]

Hi Adrian,

do we really want to a culture in Debian where it is acceptable to
publically belittle others' efforts using such emotionally loaded
words or in such a combatitive / adversarial manner?

you omitted the relevant part from my email

I'm sorry you feel misquoted but I believe I explicitly praised you
in my last mail for pointing out the potential disparity between
perception & reality and even underlined my agreement with you.

If you will permit me to exaggerate for a moment, if anybody is leaving
the Project it is due to sustained exposure to such low-level
toxicity. :(

There are two orders of magnitude of people more in the project that
need a thick skin due to the toxity of the intransparent NEW handling
of the ftp team than there are members in the ftp team.

Again, apologies for any miscommunication but I was referring to
members of the Debian Project as a whole who perhaps do not find it
satisfying to be part of generally negative interactions, rather than
members of the FTP team specifically.

the only person in the project who is able to push for improvements
in this area is the DPL.

Which, as I mentioned, I have been persuing in my role as DPL and as
an FTP-assistant. Indeed, a glance at my mailbox suggests that things
have been in motion even since your reply to me.

The other, critical, factor nobody has raised is time. Why not
assume good faith here? After all, which is more likely - the FTP
team are sitting around doing nothing and happy/enjoying the current
state of affairs, or too busy with life/family/work and the quotidien
admin tasks & other breakages that they don't have as spare cycles as
we would like to work on this?

The only alternative would be a GR to override the DPL decision
regarding the ftp team delegation, and no matter the outcome this
would be ugly.
It is therefore disappointing when a DPL candidate tries to wiggle out
of making a commitment

There is no wiggle; I think I already implied that a DPL passive-
aggressively threatening the FTP team with a General Resolution
masquerading as a schedule would not lead to the situation improving
any quicker. :)


Best wishes,

[Adrian Bunk]

Post by Chris Lamb
...
The other, critical, factor nobody has raised is time. Why not
assume good faith here? After all, which is more likely - the FTP
team are sitting around doing nothing and happy/enjoying the current
state of affairs, or too busy with life/family/work and the quotidien
admin tasks & other breakages that they don't have as spare cycles as
we would like to work on this?
...

This is not about assuming bad faith, more about bad priorities.

There are plenty of cases where people get annoyed by the NEW handling,
and when you say that the ftp team needs a thick skin that is also due
to many people thinking "Why did the idiots in the ftp teams do this
with my work?".

Post by Chris Lamb
From outside copyright handling in NEW ranges from

How did this package pass NEW with this copyright problem that is
obvious when looking at debian/copyright?
through
What the legal reason that the ftp team insists on adding all author
attribution to debian/copyright for GPLv2 software?
to
What is the legal reason that adding all author attribution is not
required for src:linux to pass NEW?

Post by Chris Lamb
From outside all this appears arbitrary and unfair, and you might be

underestimating the amount of frustration it causes.

Some cases might be an ftp team member making a mistake.
Many cases might be people not understanding why something is required
for legal reasons.

Most of us have more Debian TODO items than available Debian time.
Waiting for spare cycles might therefore not be a good way forward
for something that causes widespread frustration.

You were calling it "imposing an ultimatum", I would rather call it
"agree with the ftp team on a deadline".

cu
Adrian

[Ian Jackson]

[lots of things]

Thank you, Chris, for this absolutely excellent reply.

Ian.