Re: Q: NEW process licence requirements

[Ian Jackson]

Chris Lamb writes ("Re: Q: NEW process licence requirements"):
> [lots of things]

Thank you, Chris, for this absolutely excellent reply.

Ian.

Re: Q: NEW process licence requirements

[Adrian Bunk]

On Tue, Apr 03, 2018 at 11:30:23AM +0800, Paul Wise wrote:
> On Sun, Apr 1, 2018 at 6:11 AM, Adrian Bunk wrote:
> 
> > 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.

> bye,
> pabs

cu
Adrian

-- 

   "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

Re: Q: NEW process licence requirements

[Andrey Rahmatullin]

On Tue, Apr 03, 2018 at 07:57:11AM +0200, Didier 'OdyX' Raboud wrote:
> > > 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.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: NEW process licence requirements

[Didier 'OdyX' Raboud]

Le dimanche, 1 avril 2018, 00.11:58 h CEST Adrian Bunk a écrit :
> Sat, Mar 31, 2018 at 11:03:00PM +0200, Joerg Jaspert wrote:
> > 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

signature.asc
Description: This is a digitally signed message part.

Re: Q: NEW process licence requirements

[Paul Wise]

On Sun, Apr 1, 2018 at 6:11 AM, Adrian Bunk wrote:

> 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.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Q: NEW process licence requirements

[Adrian Bunk]

On Mon, Apr 02, 2018 at 10:57:24AM +0100, Chris Lamb wrote:
>...
> 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?".

>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?

>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

-- 

   "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

Re: Q: NEW process licence requirements

[Adam Borowski]

On Mon, Apr 02, 2018 at 04:11:40PM +0300, Adrian Bunk wrote:
> On Sun, Apr 01, 2018 at 10:36:23PM +0200, Joerg Jaspert wrote:
> > 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.

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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

> > 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.

> > 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!
-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ

Re: Q: NEW process licence requirements

[Adrian Bunk]

On Sun, Apr 01, 2018 at 10:36:23PM +0200, Joerg Jaspert wrote:
> On 14994 March 1977, Adrian Bunk wrote:
> 
> > 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.

> 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.

> 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?

> 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.

> 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.

> bye, Joerg

cu
Adrian

-- 

   "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

Re: Q: NEW process licence requirements

[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,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Q: NEW process licence requirements

[Joerg Jaspert]

On 14994 March 1977, Adrian Bunk wrote:

> 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.

-- 
bye, Joerg

Re: Q: NEW process licence requirements

[Adrian Bunk]

On Sat, Mar 31, 2018 at 11:03:00PM +0200, Joerg Jaspert wrote:
> On 14993 March 1977, Adrian Bunk wrote:
> 
> > 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?

> 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.

> bye, Joerg

cu
Adrian

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

-- 

   "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

Re: Q: NEW process licence requirements

[Joerg Jaspert]

On 14993 March 1977, Adrian Bunk wrote:

> 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.

-- 
bye, Joerg

Re: Q: NEW process licence requirements

[Adrian Bunk]

On Sat, Mar 31, 2018 at 09:44:45AM -0700, Russ Allbery wrote:
> Adrian Bunk  writes:
> 
> > 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.

> 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

-- 

   "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

Re: Q: NEW process licence requirements

[Russ Allbery]

Adrian Bunk  writes:

> 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.

-- 
Russ Allbery (r...@debian.org)   

Re: Q: NEW process licence requirements

[Adam D. Barratt]

On Sat, 2018-03-31 at 15:37 +0300, Adrian Bunk wrote:
> 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

Re: Q: NEW process licence requirements

[Adrian Bunk]

On Fri, Mar 30, 2018 at 10:55:30PM +0100, Chris Lamb wrote:
> Hi Adrian,

Hi Chris,

>...
> 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.
> 
> 
> > rules that appear to be pointless and only designed to create
> > additional work set by people with absolute powers
> […]
> > reasons that appear to be arbitrary and pointless, or there
> > is nitpicking
> […]
> > 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?

you omitted the relevant part from my email:

> 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.

> 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.

>...
> 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.

> Best wishes,

cu
Adrian

-- 

   "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

Re: Q: NEW process licence requirements

[Chris Lamb]

Hi Adrian,

> 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.


> rules that appear to be pointless and only designed to create
> additional work set by people with absolute powers
[…]
> reasons that appear to be arbitrary and pointless, or there
> is nitpicking
[…]
> 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,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-