Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Sean Whitton]

Hello,

On Sun 29 Dec 2019 at 10:09am -05, Scott Kitterman wrote:

> On Sunday, December 29, 2019 9:56:00 AM EST Sean Whitton wrote:
>> Hello,
>>
>> On Sat 28 Dec 2019 at 10:46am -05, Scott Kitterman wrote:
>> > The same information could be included in the machine readable format as
>> > comments.  It's not the format per se that helps, it's how the maintainer
>> > organizes the information.
>> >
>> > Also, personally, I find understanding what debian/copyright says is a
>> > trivial effort compared to understanding what copyright/licenses actually
>> > apply to the package.
>>
>> I agree with your general points, here, but for very complicated
>> packages with a lot of different licenses, the machine-readable format
>> can be easier to work with.
>
> I agree with that, but I don't think the advantage is sufficient that we 
> should
> burden contributors with making it a requirement.

I agree with this too.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Russ Allbery]

Sean Whitton  writes:

> The main reason I referred to dgit's copyright file in this discussion
> was because I think the "Contributions are accepted upstream ..."
> section is useful to include in d/copyright rather than somewhere else
> in the source package, as then all licensing and copyright information
> is in one place.  I don't think its inclusion there would noticeably
> slow down NEW review.

I'm going to disagree here (although I don't feel strongly about it): I
don't think this belongs in the debian/copyright file.  I think of the
copyright file as a repository for the licensing information and mandatory
notices for the package as delivered as a Debian package, and this isn't
any of those things, so it makes the file longer and is more for anyone
reviewing licensing to read through, while (I think) not being relevant to
the license of the code or binaries.

This sort of upstream contribution policy in my mind should be put as
close as possible to the place where someone is submitting code upstream.
If the project is based on pull requests, for instance, it should ideally
be prominant in the interface where one submits a pull request.  For a
package where most contributions are expected to come through the BTS, I
would instead put the "Contributions are accepted upstream..." paragraph
in README.Debian and the certificate of origin in a separate file in
/usr/share/doc, since I think that would increase the chances that someone
who was preparing a patch would read it. (I personally would never look at
debian/copyright when submitting a patch to the BTS, but would probably
read README.Debian.)

This is just one anecdotal opinion, though, so please take with a grain of
salt.

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

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Jonas Smedegaard]

Quoting Sean Whitton (2019-12-29 15:52:57)
> On Sat 28 Dec 2019 at 04:14pm +01, Thorsten Alteholz wrote:
> > On Sat, 28 Dec 2019, Sean Whitton wrote:
> >> For packages with simple copyright and licensing, machine readable 
> >> copyright files can take longer to write than a freeform copyright 
> >> file.
> >
> > this discussion started with possible stuff to reduce the time for 
> > NEW reviews.
> > If I look at dgit, why do I need to read sentences like "This is a 
> > dummy package containing only Debian metadata" in the copyright 
> > file? I also don't have to be told that GPL is comaptible with 
> > GPLv3.
> > During the time I need to read such freeform prose to understand the 
> > copyright situation, I could check several machine-readable files 
> > where I can capture all important information at first view.
> 
> The main reason I referred to dgit's copyright file in this discussion
> was because I think the "Contributions are accepted upstream ..."
> section is useful to include in d/copyright rather than somewhere else
> in the source package, as then all licensing and copyright information
> is in one place.  I don't think its inclusion there would noticeably
> slow down NEW review.

I agree that it is sensible to include contribution notice in copyright 
file.

I don't follow, however, what makes such notice longer to write (or 
lesser readable, or whichever other reason) in machine-readable format - 
e.g. in a Comment field for the top section.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Scott Kitterman]

On Sunday, December 29, 2019 9:56:00 AM EST Sean Whitton wrote:
> Hello,
> 
> On Sat 28 Dec 2019 at 10:46am -05, Scott Kitterman wrote:
> > The same information could be included in the machine readable format as
> > comments.  It's not the format per se that helps, it's how the maintainer
> > organizes the information.
> > 
> > Also, personally, I find understanding what debian/copyright says is a
> > trivial effort compared to understanding what copyright/licenses actually
> > apply to the package.
> 
> I agree with your general points, here, but for very complicated
> packages with a lot of different licenses, the machine-readable format
> can be easier to work with.

I agree with that, but I don't think the advantage is sufficient that we should 
burden contributors with making it a requirement.

Scott K

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

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Sean Whitton]

Hello,

On Sun 29 Dec 2019 at 09:15am +01, Enrico Zini wrote:

> I see similar things on nm.debian.org, which I ended up calling in my
> head something like "the law of inflation of bureaucracy".
>
> That is, I see that when people are asked to do some work, that later
> will be checked by someone else, over time there is a tendency for the
> perceived amount of work to inflate.
>
> I guess the incentives are such that doing one bit less feels like
> making it more likely that review will fail, and doing one bit more
> feels like making it more likely that review will pass.
>
> The result over time is an increase in the amount effort that both
> people who are doing the work and people who are doing the checking end
> up putting into the system.
>
> For example, an Application Manager in the NM process will tend to err
> for asking a question more, that DAM will have to read.
>
> I haven't yet seen easy ways of introducing a feedback mechanism to
> counter this: saying "you didn't need to do this" feels to me like
> arbitrarily undervaluing someone's work, and maybe the person really
> found it important to do it.

This is interesting.

If you contrast the work that was done with the work that might have
been done, then I don't think you would be undervaluing someone's work,
nor would there be anything arbitrary about it.

In your example, if someone had asked a few questions fewer, they might
be 20% further in their next AM process than they are now.  There's
nothing arbitrary about feedback which says "the goals you and I both
share would have been further advanced, by you, if you hadn't asked
these questions."

-- 
Sean Whitton

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Sean Whitton]

Hello,

On Sat 28 Dec 2019 at 10:46am -05, Scott Kitterman wrote:

> The same information could be included in the machine readable format as
> comments.  It's not the format per se that helps, it's how the maintainer
> organizes the information.
>
> Also, personally, I find understanding what debian/copyright says is a trivial
> effort compared to understanding what copyright/licenses actually apply to the
> package.

I agree with your general points, here, but for very complicated
packages with a lot of different licenses, the machine-readable format
can be easier to work with.

-- 
Sean Whitton

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Sean Whitton]

Hello Thorsten,

On Sat 28 Dec 2019 at 04:14pm +01, Thorsten Alteholz wrote:

> On Sat, 28 Dec 2019, Sean Whitton wrote:
>> For packages with simple copyright and licensing, machine readable
>> copyright files can take longer to write than a freeform copyright file.
>
> this discussion started with possible stuff to reduce the time for NEW
> reviews.
> If I look at dgit, why do I need to read sentences like "This is a dummy
> package containing only Debian metadata" in the copyright file? I
> also don't have to be told that GPL is comaptible with GPLv3.
> During the time I need to read such freeform prose to understand the
> copyright situation, I could check several machine-readable files where I
> can capture all important information at first view.

The main reason I referred to dgit's copyright file in this discussion
was because I think the "Contributions are accepted upstream ..."
section is useful to include in d/copyright rather than somewhere else
in the source package, as then all licensing and copyright information
is in one place.  I don't think its inclusion there would noticeably
slow down NEW review.

I agree with you that there is some superfluous information in the
other parts of the file.

-- 
Sean Whitton

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Enrico Zini]

On Sun, Dec 29, 2019 at 03:15:07PM +0600, Judit Foglszinger wrote:

> Maybe instead of saying "you shouldn't have done that",
> rather explain which parts of questions asked in one specific process
> one found sufficient to approve the NM as a DAM and why,
> so there is some more orientation and more insight,
> what exactly DAM finds important to ask.
> 
> On the other hand given that quite some people find their process
> a valuable experience, it would be sad to reduce it to the bare minimum,
> as long an AM takes the effort to ensure, that
> the NM is not forced to do unnecessary things they rather wouldn't want to do.
> (if some stuff is more clearly optional, it might also easier for DAM to skip 
> it)

Thanks! I like the angle of documenting what was found sufficient,
rather than what was not needed.

Probably the documentation shouldn't be public, to avoid applicants to
build an expectations of a bare minimum work required and then get angry
at the AM if the AM feels like asking more than that, but it could be,
for example, a monthly post to the am@ alias.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Enrico Zini]

On Sat, Dec 28, 2019 at 02:35:50PM +, Sean Whitton wrote:

> On Sat 28 Dec 2019 at 08:21am -05, Roberto C. Sánchez wrote:
> 
> > Oh, wow.  I've been doing this wrong all along.  I am not sure how I
> > developed the impression that it was necessary to distinguish different
> > copyright holders (even same copyright holders with different copyright
> > years), but your approach is most certainly simpler and more compact.
> 
> Right.  This is the sort of overdocumentation that I worry our
> machine-readable copyright format implicitly encourages us to do.

I see similar things on nm.debian.org, which I ended up calling in my
head something like "the law of inflation of bureaucracy".

That is, I see that when people are asked to do some work, that later
will be checked by someone else, over time there is a tendency for the
perceived amount of work to inflate.

I guess the incentives are such that doing one bit less feels like
making it more likely that review will fail, and doing one bit more
feels like making it more likely that review will pass.

The result over time is an increase in the amount effort that both
people who are doing the work and people who are doing the checking end
up putting into the system.

For example, an Application Manager in the NM process will tend to err
for asking a question more, that DAM will have to read.

I haven't yet seen easy ways of introducing a feedback mechanism to
counter this: saying "you didn't need to do this" feels to me like
arbitrarily undervaluing someone's work, and maybe the person really
found it important to do it.

I would be very much interested in reasoning about this.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Russ Allbery]

Mo Zhou  writes:

> Don't know what Red Hat family does, but at least Archlinux and Gentoo
> treat the license checking problem in a very permissive way.  However,
> Debian is sometimes an important reference to these friend distros when
> they encountered some problems about license.

I do think we can maintain that property without hand-checking every file
in every source package we upload.  My sense (I could be wrong) is that
other distributions look at us more for our analysis of the license terms
than for our ability to dig out obscure issues from source trees.  And
even if it's finding obscure issues in the source tree, we still have a
lot of eyes and a community that cares about these things and it's always
possible for people to do volunteer reviews.

Another option that I forgot to mention is that we could continue to ask
the package maintainer to do a thorough license review and treat licensing
problems as bugs.  One way to think about the current ftpmaster review is
that we treat licensing bugs far more seriously than other bugs and thus
have mandatory code review for licensing issues but not for anything else
in Debian.  And again, that could be exactly what we want to do, but it's
worth calling it out as a deliberate choice.  We could decide to treat
licensing bugs as less special (with appropriate legal advice, of course).

> Making that process scalable seemed like a workflow change, which often
> takes centuries to enforce in this community. Even if that process can
> be scaled to a larger group of workers, without proper tool every worker
> node will still work in low efficiency (and still easily get mentally
> bored).

Well, in this case the workflow is already centralized, so I think it's
more tractable than that.  But yes, thank you for starting the discussion
of the tool.  I think such a tool is extremely valuable for maintainers
regardless, and will make any workflow that involves any central review
under any circumstances much easier.

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

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Mo Zhou]

On Sat, Dec 28, 2019 at 02:13:55PM -0800, Russ Allbery wrote:
> If we're only doing this for secondary
> reasons like legal liability, it might be worth looking around and seeing
> if other organizations with similar legal risks take the same precautions,
> or asking for legal advice on whether this precaution is legally necessary
> or if we're creating work for ourselves that exceeds the legal risk we'd
> be accepting by doing something more automatable.

Don't know what Red Hat family does, but at least Archlinux and Gentoo
treat the license checking problem in a very permissive way.
However, Debian is sometimes an important reference to these friend
distros when they encountered some problems about license.
 
> To be clear, it may be that we'll ask this question and decide that yes,
> detailed license review is something we consider important and we want to
> keep doing it the way that we have been doing it, and we need to figure
> out how to make that work scale.

Making that process scalable seemed like a workflow change, which often
takes centuries to enforce in this community. Even if that process can
be scaled to a larger group of workers, without proper tool every worker
node will still work in low efficiency (and still easily get mentally
bored).

Assuming "license reviewing is inevitable to Debian", someone must
manually check the debian/copyright file.  In Chinese there is an old
saying "工欲善其事，必先利其器", which means "one who wants to get the
work done has to sharpen their tools first" (note, not a standard
translation).

So, trying to design a human-oriented tool for more efficient license
review should be worth consideration, at least. That's what my thread on
-devel is trying to do.

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Russ Allbery]

Jonas Smedegaard  writes:

> Beware that I say we must _check_ every file - not that we must _list_
> every file in debian/copyright.

> All that Debian distributes must be legal to distribute.

> You may argue that you need not check e.g. if PNG files in your package 
> contain embedded non-free ICC profiles, but that just means that you 
> rely on ftpmasters to check it on your behalf.

> You may argue that your upstream has already checked that for you.  I'd 
> call that a sloppy check, and there is a real risk that again you then 
> burden ftpmasters with digging out dirt because upstream has a different 
> view than Debian what is legally acceptable.

Requiring ftpmasters to do this check is a choice that Debian has made.
Maybe it's the right choice, but other choices exist, and other entities
make different choices.

For example, we could chose to trust upstream license assertions and fix
them later if upstream turns out to be wrong.  Or we could chose to adopt
a specific tool for automated license checks and base the accept decision
on the output of that tool plus upstream assertions in the knowledge that
this could be incorrect, and later fix problems that are drawn to our
attention.  (Note that thorough license review has not completely
eliminated license problems that we have had to fix later, although it
certainly reduces the number of them.  We will be fixing some issues
retroactively under any approach.)

In the context of limited project resources, it seems worth asking not the
absolute question of whether thorough license checks have desirable
properties (obviously they do), but instead whether this is the most
effective use to which the project could be putting this energy, or if we
should consider alternatives so that we can redirect some of that energy
to other things the project considers important.

Another way of asking that question is to ask whether this sort of
thorough license double-checking is something we consider a core mission
of the project, or something that we're doing for secondary reasons (such
as reducing the risk of legal liability).  If it's a core mission of the
project, then maybe we do want to reaffirm our decision to spend
significant resources on it.  If we're only doing this for secondary
reasons like legal liability, it might be worth looking around and seeing
if other organizations with similar legal risks take the same precautions,
or asking for legal advice on whether this precaution is legally necessary
or if we're creating work for ourselves that exceeds the legal risk we'd
be accepting by doing something more automatable.

To be clear, it may be that we'll ask this question and decide that yes,
detailed license review is something we consider important and we want to
keep doing it the way that we have been doing it, and we need to figure
out how to make that work scale.  But I do think it's worth occasionally
explicitly asking the question and then making an intentional choice,
rather than assuming we're obligated to continue doing what we're doing.

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

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Jonas Smedegaard]

Quoting Clint Adams (2019-12-28 21:20:03)
> On Sat, Dec 28, 2019 at 05:32:02PM +0100, Jonas Smedegaard wrote:
> > metadata file - without checking licensing of each and every _file_ 
> > which we *must* do (machine-readable or not).
> 
> Why do you believe this to be true?

Beware that I say we must _check_ every file - not that we must _list_ 
every file in debian/copyright.

All that Debian distributes must be legal to distribute.

You may argue that you need not check e.g. if PNG files in your package 
contain embedded non-free ICC profiles, but that just means that you 
rely on ftpmasters to check it on your behalf.

You may argue that your upstream has already checked that for you.  I'd 
call that a sloppy check, and there is a real risk that again you then 
burden ftpmasters with digging out dirt because upstream has a different 
view than Debian what is legally acceptable.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Clint Adams]

On Sat, Dec 28, 2019 at 05:32:02PM +0100, Jonas Smedegaard wrote:
> metadata file - without checking licensing of each and every _file_ 
> which we *must* do (machine-readable or not).

Why do you believe this to be true?

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Ole Streicher]

Scott Kitterman  writes:
> On December 28, 2019 2:30:54 PM UTC, Sean Whitton
>>For packages with simple copyright and licensing, there are useful
>>things you can do with a freeform copyright file which you can't do
>>with a machine-readable file.  See for example the contribution
>>information in the copyright files of src:dgit and src:mailscripts.
>
> Also, please consider the impact on new contributors.  This list of
> somewhat arcane policies and procedures that new contributors need to
> learn us already long.  Adding to it raises barriers to contributing.

Trying to get people involved into Debian, I see this completely
different: It is much simpler to tell people to basically fill out a
sheet with fields like "Files", "License", "Copyright" then to tell them
that they should "somehow" merge all licenses together into a single
copyright.

The machine readable form guides people to look into all individual
files and to document the copyright. The actual pain is not the format
but the need to *do* the review.

Best regards

Ole

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Jonas Smedegaard]

Quoting Sean Whitton (2019-12-28 15:35:50)
> On Sat 28 Dec 2019 at 08:21am -05, Roberto C. Sánchez wrote:
> 
> > Oh, wow.  I've been doing this wrong all along.  I am not sure how I 
> > developed the impression that it was necessary to distinguish 
> > different copyright holders (even same copyright holders with 
> > different copyright years), but your approach is most certainly 
> > simpler and more compact.
> 
> Right.  This is the sort of overdocumentation that I worry our 
> machine-readable copyright format implicitly encourages us to do.

I worry that *not* using machine-readable copyright format implicitly 
encourages us to document only _project-wide_ licensing - e.g. what some 
upstreams write in a top-level LICENSE or COPYRIGHT file or in some 
metadata file - without checking licensing of each and every _file_ 
which we *must* do (machine-readable or not).

ftp-masters check all files, which I guess is slower when only they do 
so.

...which is the topic of this discussion!

Both you and I worry about subjective implicit encouragements, however - 
not about the actual demands of machine-readable format.

The definition of machine-readable format includes this:

> Nothing in this proposal supersedes or modifies any of the 
> requirements specified in Debian Policy regarding the appropriate 
> detail or granularity to use when documenting copyright and lice> nse 
> status in debian/copyright.

In other words, debian/copyright need *same* amount of detail, 
regardless of the file being machine-readable or not!

machine-readable format does *not* require more detail.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Thorsten Alteholz]

On Sat, 28 Dec 2019, Scott Kitterman wrote:

The same information could be included in the machine readable format as
comments.  It's not the format per se that helps, it's how the maintainer
organizes the information.


Yes, sure, but Sean mentioned the copyright file of dgit as a good example 
for a freeform copyright file and I objected.
From my experience Comments: are rather seldom used in File:-blocks and 

are much shorter.


Also, personally, I find understanding what debian/copyright says is a trivial
effort compared to understanding what copyright/licenses actually apply to the
package.


This is true for large packages, but nowadays most packages are simple 
go-, rust-, ruby-, node-, or whatever-fancy-language-packages where you 
just need that trivial effort and I would prefer to have this done as 
fast as possible.


  Thorsten

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Scott Kitterman]

On Saturday, December 28, 2019 10:14:21 AM EST Thorsten Alteholz wrote:
> Hi Sean,
> 
> On Sat, 28 Dec 2019, Sean Whitton wrote:
> > For packages with simple copyright and licensing, machine readable
> > copyright files can take longer to write than a freeform copyright file.
> 
> this discussion started with possible stuff to reduce the time for NEW
> reviews.
> If I look at dgit, why do I need to read sentences like "This is a dummy
> package containing only Debian metadata" in the copyright file? I
> also don't have to be told that GPL is comaptible with GPLv3.
> During the time I need to read such freeform prose to understand the
> copyright situation, I could check several machine-readable files where I
> can capture all important information at first view.
> 
>Thorsten

The same information could be included in the machine readable format as 
comments.  It's not the format per se that helps, it's how the maintainer 
organizes the information.

Also, personally, I find understanding what debian/copyright says is a trivial 
effort compared to understanding what copyright/licenses actually apply to the 
package.

Scott K

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

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Thorsten Alteholz]

Hi Sean,

On Sat, 28 Dec 2019, Sean Whitton wrote:

For packages with simple copyright and licensing, machine readable
copyright files can take longer to write than a freeform copyright file.


this discussion started with possible stuff to reduce the time for NEW 
reviews.
If I look at dgit, why do I need to read sentences like "This is a dummy 
package containing only Debian metadata" in the copyright file? I 
also don't have to be told that GPL is comaptible with GPLv3.
During the time I need to read such freeform prose to understand the 
copyright situation, I could check several machine-readable files where I 
can capture all important information at first view.


  Thorsten

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Scott Kitterman]

On December 28, 2019 2:30:54 PM UTC, Sean Whitton  
wrote:
>Hello,
>
>On Sat 28 Dec 2019 at 11:31am +01, Jonas Smedegaard wrote:
>
>> I ceertainly agree that our copyright files should be
>machine-readable
>> in _addition_ to being human-readable, not instead.
>>
>> I believe our current machine-readable format is expressive enough to
>> also be decently human-readable.
>>
>> Please help challenge me on that: Provide me examples of packages
>> considered unsuitable for use with our machine-readable format
>because
>> that would make them too human-unreadable.  I would like to have a
>> closer look at such cases.
>
>It's not usually that they are unreadable, but that they are less
>readable.  I'm afraid I don't have examples to hand.
>
>For packages with simple copyright and licensing, machine readable
>copyright files can take longer to write than a freeform copyright
>file.
>
>For packages with simple copyright and licensing, there are useful
>things you can do with a freeform copyright file which you can't do
>with
>a machine-readable file.  See for example the contribution information
>in the copyright files of src:dgit and src:mailscripts.


Also, please consider the impact on new contributors.  This list of somewhat 
arcane policies and procedures that new contributors need to learn us already 
long.  Adding to it raises barriers to contributing.

I don't think there's anything important enough about machine readable 
copyright that we should tell people that they are to ignorant to contribute a 
new package unless they learn it.

Scott K

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Sean Whitton]

Hello,

On Sat 28 Dec 2019 at 11:31am +01, Jonas Smedegaard wrote:

> I ceertainly agree that our copyright files should be machine-readable
> in _addition_ to being human-readable, not instead.
>
> I believe our current machine-readable format is expressive enough to
> also be decently human-readable.
>
> Please help challenge me on that: Provide me examples of packages
> considered unsuitable for use with our machine-readable format because
> that would make them too human-unreadable.  I would like to have a
> closer look at such cases.

It's not usually that they are unreadable, but that they are less
readable.  I'm afraid I don't have examples to hand.

For packages with simple copyright and licensing, machine readable
copyright files can take longer to write than a freeform copyright file.

For packages with simple copyright and licensing, there are useful
things you can do with a freeform copyright file which you can't do with
a machine-readable file.  See for example the contribution information
in the copyright files of src:dgit and src:mailscripts.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Sean Whitton]

Hello,

On Sat 28 Dec 2019 at 11:39am +01, Michael Banck wrote:

> Really? Why?

Yes.  (source: I'm an ftptrainee)

> So far I assumed that simple binary package renames due to shared
> library bumps or other API transitions where fast-tracked without full
> review, perhaps slightly less so for additions or split-offs of e.g.
> -data or -doc packages.
>
> Adding new binaries is an arbitrary (apart from the technical
> implementation reason in dak, of course) point in time to recheck a
> source package; even more so if this is due to external reasons (binary
> name changed to the external API changes, like a PostgreSQL major
> version transition).

I don't think it's fair to say that it's arbitrary.  A new binary
package might be added if the library gained Python bindings, say, in
which case there would be a pile of new Python code in the package whose
copyright and licensing status should be checked.

I agree that there might be more sophisticated ways in which we could
schedule these rereviews of source packages.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Sean Whitton]

Hello,

On Sat 28 Dec 2019 at 08:21am -05, Roberto C. Sánchez wrote:

> Oh, wow.  I've been doing this wrong all along.  I am not sure how I
> developed the impression that it was necessary to distinguish different
> copyright holders (even same copyright holders with different copyright
> years), but your approach is most certainly simpler and more compact.

Right.  This is the sort of overdocumentation that I worry our
machine-readable copyright format implicitly encourages us to do.

> How about licenses with slight variations?  I'm thinking BSD-like and
> MIT-like licenses which mention the copyright holder usually as the
> first thing in the in license text.  Could those be combined into a
> single stanza in the way you describe?

IANAL, but my understanding is that the statement of copyright does not
actually form part of the license text, so you can consolidate, indeed.

> Also, I assume that it is good practice to verify actual license texts
> included by upstream against known good sources since that seems like
> something FTP masters would have to do as well.  Is that correct?

You should check for variant licenses, though with GNU licenses it is
unlikely to come up because those licenses do not permit derivative
works.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Roberto C . Sánchez]

On Sat, Dec 28, 2019 at 09:47:20AM +, Sean Whitton wrote:
> Hello Thorsten,
> 
> On Thu 26 Dec 2019 at 04:30pm +01, Thorsten Alteholz wrote:
> 
> > Make the machine-readable copyright file mandatory.
> > It is much easier to "parse" than just a bunch of copyright information.
> 
> The other side of this is that using that format tends to encourage
> documenting a bunch of information about the source package which we
> don't need to document, but which the ftp team member processing NEW is
> still going to have to verify as correct.
> 
> So I'd like to append to your point: do take advantage of the
> machine-readable copyright format for complex source packages, but don't
> add more "Files:" stanzas than are strictly necessary.
> 
> For example,
> 
> Files: *
> Copyright: (c) 1994 A. Developer
> License: GPL-2+
> 
> Files: foo.js baz/bar.js
> Copyright: (c) 1995 Google
> License: GPL-2+
> 
> could be combined into
> 
> Files: *
> Copyright: (c) 1994 A. Developer
>  (c) 1995 Google
> License: GPL-2+
> 
> i.e. you generally only need separate stanzas when the license is
> different, not simply because there are different coyright holders.  In
> most cases you should should not need more stanzas than there are
> different licenses.
> 
Oh, wow.  I've been doing this wrong all along.  I am not sure how I
developed the impression that it was necessary to distinguish different
copyright holders (even same copyright holders with different copyright
years), but your approach is most certainly simpler and more compact.

How about licenses with slight variations?  I'm thinking BSD-like and
MIT-like licenses which mention the copyright holder usually as the
first thing in the in license text.  Could those be combined into a
single stanza in the way you describe?

Also, I assume that it is good practice to verify actual license texts
included by upstream against known good sources since that seems like
something FTP masters would have to do as well.  Is that correct?

Regards,

-Roberto
-- 
Roberto C. Sánchez

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Mo Zhou]

On Sat, Dec 28, 2019 at 09:58:57AM +, Sean Whitton wrote:
> Not sure why I'm being mentioned here;

Just a guess. Nevermind.

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Michael Banck]

Hi,

On Sat, Dec 28, 2019 at 09:49:22AM +, Sean Whitton wrote:
> Hello,
> 
> On Thu 26 Dec 2019 at 11:29am -05, Roberto C. Sánchez wrote:
> 
> > One interesting thing about this is that I have often wondered if it
> > would be beneficial to have checks on debian/copyright during the life
> > of a package.  Checking only once when a package first enters the Debian
> > archive seems to leave open the rather likely possibility that some
> > change in a future upstream release changes or adds some component
> > license that should be documented in debian/copyright.  I try to be
> > diligent in this regard and even at times have found that I overlook
> > things.
> 
> Well, this is one of the reasons why source package which add new binary
> packages end up in NEW again.

> The full source tree gets checked again at that point as if the source
> package were completely new.

Really? Why?

So far I assumed that simple binary package renames due to shared
library bumps or other API transitions where fast-tracked without full
review, perhaps slightly less so for additions or split-offs of e.g.
-data or -doc packages.

Adding new binaries is an arbitrary (apart from the technical
implementation reason in dak, of course) point in time to recheck a
source package; even more so if this is due to external reasons (binary
name changed to the external API changes, like a PostgreSQL major
version transition).

Maybe we should have a conversation about periodical rechecks, but
packages like rdkit[1] languishing in NEW for almost two months and
counting just because of a new PostgreSQL release is a bit depressing.


Michael

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

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Jonas Smedegaard]

Quoting Sean Whitton (2019-12-28 10:53:14)
> On Thu 26 Dec 2019 at 07:05pm +00, Scott Kitterman wrote:
> 
> > The notion that it's easier for a human to parse isn't universal.  I 
> > don't find it's the case.  Hard to follow copyright files can be 
> > written in any format.
> 
> This has been my experience as well.
> 
> For some packages, the traditional format is easier for humans to use, 
> and for others, the machine-readable format is easier to both read and 
> write.  It is good to let maintainers judge which one will work best 
> for their package.  (I think we should be optimising for our human 
> volunteers, because they are the lifeblood of our project.)

I ceertainly agree that our copyright files should be machine-readable 
in _addition_ to being human-readable, not instead.

I believe our current machine-readable format is expressive enough to 
also be decently human-readable.

Please help challenge me on that: Provide me examples of packages 
considered unsuitable for use with our machine-readable format because 
that would make them too human-unreadable.  I would like to have a 
closer look at such cases.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Sean Whitton]

Hello Thorsten,

On Thu 26 Dec 2019 at 04:30pm +01, Thorsten Alteholz wrote:

> Make the machine-readable copyright file mandatory.
> It is much easier to "parse" than just a bunch of copyright information.

The other side of this is that using that format tends to encourage
documenting a bunch of information about the source package which we
don't need to document, but which the ftp team member processing NEW is
still going to have to verify as correct.

So I'd like to append to your point: do take advantage of the
machine-readable copyright format for complex source packages, but don't
add more "Files:" stanzas than are strictly necessary.

For example,

Files: *
Copyright: (c) 1994 A. Developer
License: GPL-2+

Files: foo.js baz/bar.js
Copyright: (c) 1995 Google
License: GPL-2+

could be combined into

Files: *
Copyright: (c) 1994 A. Developer
 (c) 1995 Google
License: GPL-2+

i.e. you generally only need separate stanzas when the license is
different, not simply because there are different coyright holders.  In
most cases you should should not need more stanzas than there are
different licenses.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Sean Whitton]

Hello,

On Thu 26 Dec 2019 at 11:29am -05, Roberto C. Sánchez wrote:

> One interesting thing about this is that I have often wondered if it
> would be beneficial to have checks on debian/copyright during the life
> of a package.  Checking only once when a package first enters the Debian
> archive seems to leave open the rather likely possibility that some
> change in a future upstream release changes or adds some component
> license that should be documented in debian/copyright.  I try to be
> diligent in this regard and even at times have found that I overlook
> things.

Well, this is one of the reasons why source package which add new binary
packages end up in NEW again.  The full source tree gets checked again
at that point as if the source package were completely new.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Sean Whitton]

Hello,

On Thu 26 Dec 2019 at 04:05am +00, Mo Zhou wrote:

> However, accelerating the recruitment process of ftp team looks quite
> difficult to all participants, including the ftp-masters and the trainees:
>
> ftp-master:
>  * time and energy is limited. doesn't have enough resource to provide
>too much feedbacks to the trainee
>  * wants to make sure every new member will be qualified enough to take
>this important role.
>
> trainee:
>  * limited time and energy. generally not able to produce a large amount
>of reviews to the NEW packages in a short period of time
>  * lacks feed back. they don't know how are they actually doing in
>reviewing the NEW packages.
>
> So accelerating the recruitment process is not easy, given that we will
> not lower our quality standards.
>
> ---
>
> I think Sean shares some similar feelings.
>
> FTP team shouts for help, and the team seems too "exhausted" to even
> accept help ...
>
> I respect all my fellow developers and their endeavor. In this mail
> I'm simply describing the fact I saw.

Not sure why I'm being mentioned here; I don't recall writing about this
anywhere.  I agree with you that effective recruitment to teams with
roles like the ftpteam is a difficult problem to solve for volunteer
projects like ours.  I don't have a settled opinion about exactly why
it's difficult and what if anything we might do better, however.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Sean Whitton]

Hello,

On Thu 26 Dec 2019 at 07:05pm +00, Scott Kitterman wrote:

> The notion that it's easier for a human to parse isn't universal.  I
> don't find it's the case.  Hard to follow copyright files can be
> written in any format.

This has been my experience as well.

For some packages, the traditional format is easier for humans to use,
and for others, the machine-readable format is easier to both read and
write.  It is good to let maintainers judge which one will work best for
their package.  (I think we should be optimising for our human
volunteers, because they are the lifeblood of our project.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Holger Levsen]

On Thu, Dec 26, 2019 at 11:21:08PM +0500, Andrey Rahmatullin wrote:
> On Thu, Dec 26, 2019 at 04:29:57PM +, Holger Levsen wrote:
> > > Make the machine-readable copyright file mandatory.
> > > It is much easier to "parse" than just a bunch of copyright information.
> > hear hear. (as in: what's blocking us from doing this?)
> I'm sure some people will orphan or RM their packages instead of writing
> machine-readable debian/copyright. I suspect it will be worse than
> mandating source format 3.0.

that can be worked around easily be only requesting this for NEW
packages...


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Scott Kitterman]

On December 26, 2019 6:21:08 PM UTC, Andrey Rahmatullin  wrote:
>On Thu, Dec 26, 2019 at 04:29:57PM +, Holger Levsen wrote:
>> > Make the machine-readable copyright file mandatory.
>> > It is much easier to "parse" than just a bunch of copyright
>information.
>> 
>> hear hear. (as in: what's blocking us from doing this?)
>I'm sure some people will orphan or RM their packages instead of
>writing
>machine-readable debian/copyright. I suspect it will be worse than
>mandating source format 3.0.

The notion that it's easier for a human to parse isn't universal.  I don't find 
it's the case.  Hard to follow copyright files can be written in any format.

Scott K

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Andrey Rahmatullin]

On Thu, Dec 26, 2019 at 04:29:57PM +, Holger Levsen wrote:
> > Make the machine-readable copyright file mandatory.
> > It is much easier to "parse" than just a bunch of copyright information.
> 
> hear hear. (as in: what's blocking us from doing this?)
I'm sure some people will orphan or RM their packages instead of writing
machine-readable debian/copyright. I suspect it will be worse than
mandating source format 3.0.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Roberto C . Sánchez]

On Thu, Dec 26, 2019 at 06:01:40PM +0100, Jonas Smedegaard wrote:
> Quoting Roberto C. Sánchez (2019-12-26 17:29:52)
> > On Thu, Dec 26, 2019 at 04:30:58PM +0100, Thorsten Alteholz wrote:
> > > On Thu, 26 Dec 2019, Roberto C. Sánchez wrote:
> > > >So, what does the FTP team consider that we, as the wider 
> > > >community of Debian Developers, can do to help?
> [...]
> > > When there is a REJECT and the maintainer used a tool like 
> > > licensecheck, file a bug and let the tools become better.
> > 
> > One interesting thing about this is that I have often wondered if it 
> > would be beneficial to have checks on debian/copyright during the life 
> > of a package.
> 
> lintian does some continuous checks.
> 
> Doing it more aggressively requires (I guess¹) more work than is 
> currently available with licensecheck and related tools.
> 
> 
> > Checking only once when a package first enters the Debian archive 
> > seems to leave open the rather likely possibility that some change in 
> > a future upstream release changes or adds some component license that 
> > should be documented in debian/copyright.  I try to be diligent in 
> > this regard and even at times have found that I overlook things.
> 
> Keeping debian/copyright up-to-date is certainly an important and 
> *required* part of package maintenance!
> 
> Some use cme for automating this, I currently use licensecheck2dep5 - 
> again, please look at https://wiki.debian.org/CopyrightReviewTools for 
> options, and anyone having experience with other approaches please add 
> them to that wiki page!
> 
> 
> > In any event, a tool that can scan a source tree and produce a base 
> > debian/copyright file that I as a maintianer could edit would be a 
> > marvelous thing.  Would be possible to make the licensecheck tool dual 
> > use in that way?
> 
> You mean this?:
> 
>   licensecheck --recursive --deb-machine *
> 
> Other tools listed at https://wiki.debian.org/CopyrightReviewTools can 
> do similar/related tasks - in particular cme and licensecheck2dep5.
> 
> 

Thanks for the pointers.  I clearly need to update my knowledge
regarding the available options.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Jonas Smedegaard]

Quoting Roberto C. Sánchez (2019-12-26 17:29:52)
> On Thu, Dec 26, 2019 at 04:30:58PM +0100, Thorsten Alteholz wrote:
> > On Thu, 26 Dec 2019, Roberto C. Sánchez wrote:
> > >So, what does the FTP team consider that we, as the wider 
> > >community of Debian Developers, can do to help?
[...]
> > When there is a REJECT and the maintainer used a tool like 
> > licensecheck, file a bug and let the tools become better.
> 
> One interesting thing about this is that I have often wondered if it 
> would be beneficial to have checks on debian/copyright during the life 
> of a package.

lintian does some continuous checks.

Doing it more aggressively requires (I guess¹) more work than is 
currently available with licensecheck and related tools.


> Checking only once when a package first enters the Debian archive 
> seems to leave open the rather likely possibility that some change in 
> a future upstream release changes or adds some component license that 
> should be documented in debian/copyright.  I try to be diligent in 
> this regard and even at times have found that I overlook things.

Keeping debian/copyright up-to-date is certainly an important and 
*required* part of package maintenance!

Some use cme for automating this, I currently use licensecheck2dep5 - 
again, please look at https://wiki.debian.org/CopyrightReviewTools for 
options, and anyone having experience with other approaches please add 
them to that wiki page!


> In any event, a tool that can scan a source tree and produce a base 
> debian/copyright file that I as a maintianer could edit would be a 
> marvelous thing.  Would be possible to make the licensecheck tool dual 
> use in that way?

You mean this?:

  licensecheck --recursive --deb-machine *

Other tools listed at https://wiki.debian.org/CopyrightReviewTools can 
do similar/related tasks - in particular cme and licensecheck2dep5.


 - Jonas


¹ I am not intimately familiar with linitan, so I only guess that the 
reason it does not e.g. makes use of licensecheck is that it is too 
unreliable to correlate with machine-readable debian/copyright files.

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Holger Levsen]

On Thu, Dec 26, 2019 at 04:30:58PM +0100, Thorsten Alteholz wrote:
> Make the machine-readable copyright file mandatory.
> It is much easier to "parse" than just a bunch of copyright information.

hear hear. (as in: what's blocking us from doing this?)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Roberto C . Sánchez]

On Thu, Dec 26, 2019 at 04:30:58PM +0100, Thorsten Alteholz wrote:
> 
> 
> On Thu, 26 Dec 2019, Roberto C. Sánchez wrote:
> >So, what does the FTP team consider that we, as the wider community
> >of Debian Developers, can do to help?
> 
> What about being more careful when creating the debian/copyright for a
> package?
> I know it is boring, but writing a REJECT-mail is not much fun as well.
> Seeing a copy error once is ok, but seeing that in a bunch of
> packages, makes me wonder.
> Don't neglect fonts, pictures, sound files.
> 
I agree that this is a terribly boring thing to do when packaging new
software.  I cannot imagine how much more boring it would be for the
person performing the verification on the FTP team.

> When there is a REJECT and the maintainer used a tool like licensecheck,
> file a bug and let the tools become better.

One interesting thing about this is that I have often wondered if it
would be beneficial to have checks on debian/copyright during the life
of a package.  Checking only once when a package first enters the Debian
archive seems to leave open the rather likely possibility that some
change in a future upstream release changes or adds some component
license that should be documented in debian/copyright.  I try to be
diligent in this regard and even at times have found that I overlook
things.

In any event, a tool that can scan a source tree and produce a base
debian/copyright file that I as a maintianer could edit would be a
marvelous thing.  Would be possible to make the licensecheck tool dual
use in that way?  The FTP team could use it when validating and
developers could use it for creating the initial debian/copyright.

Then it might also serve as the basis for a lintian check (when the
quality is sufficiently high), or some other process whereby ongoing
checks of debian/copyright could be performed.

> (I tested some commercial tools a while ago and they were extremely bad in
> detecting correct licenses.)
> 
> Make the machine-readable copyright file mandatory.
> It is much easier to "parse" than just a bunch of copyright information.
> 
Yes.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Thorsten Alteholz]

On Thu, 26 Dec 2019, Roberto C. Sánchez wrote:

   So, what does the FTP team consider that we, as the wider community
   of Debian Developers, can do to help?


What about being more careful when creating the debian/copyright for a 
package?

I know it is boring, but writing a REJECT-mail is not much fun as well.
Seeing a copy error once is ok, but seeing that in a bunch of 
packages, makes me wonder.

Don't neglect fonts, pictures, sound files.

When there is a REJECT and the maintainer used a tool like licensecheck, 
file a bug and let the tools become better.
(I tested some commercial tools a while ago and they were extremely bad in 
detecting correct licenses.)


Make the machine-readable copyright file mandatory.
It is much easier to "parse" than just a bunch of copyright information.

  Thorsten

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Roberto C . Sánchez]

On Thu, Dec 26, 2019 at 08:53:43AM -0500, Roberto C. Sánchez wrote:
> 
> So, what can we, as the wider community of Debian Developers, do to
> help?

Replying to myself.

I recognize that this thread contains varying suggestions as to how to
improve the situation.  My question should have perhaps been phrased
more definitively:

So, what does the FTP team consider that we, as the wider community
of Debian Developers, can do to help?

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Roberto C . Sánchez]

On Thu, Dec 26, 2019 at 04:05:20AM +, Mo Zhou wrote:
> However, accelerating the recruitment process of ftp team looks quite
> difficult to all participants, including the ftp-masters and the trainees:
> 
> ftp-master:
>  * time and energy is limited. doesn't have enough resource to provide
>too much feedbacks to the trainee
>  * wants to make sure every new member will be qualified enough to take
>this important role.
> 
> trainee:
>  * limited time and energy. generally not able to produce a large amount
>of reviews to the NEW packages in a short period of time
>  * lacks feed back. they don't know how are they actually doing in
>reviewing the NEW packages.
> 
> So accelerating the recruitment process is not easy, given that we will
> not lower our quality standards.
> 
An application of the principle that "adding more programmers to a late
project makes it later" (from _The Mythical Man-month_) to this
situation leaves us with possible ways forward:

1. maintain the status quo and accept that FTP master tasks will
necessarily include a very large built-in delay in completion time

2. accept a further reduction in responsiveness/slow down now and for
some, perhaps indeterminate, period of time to allow for dedicating a
certain amount of effort to train extra team members (which seems to
require a high degree of close collaboration and supervision with lots
of feedback); after some time the team's productivity should increase
and surpass its current level

Speaking as someone who has had uploads processed through NEW in a
matter of days (and been very pleasantly surprised) and also still with
a package that is approaching a year in NEW (and being a bit
disappointed with that), the second of the above scenarios seems to be
by far the more sustainable and productive approach from the long-term
perspective.

So, what can we, as the wider community of Debian Developers, do to
help?

Regards,

-Roberto

-- 
Roberto C. Sánchez

possibly exhausted ftp-masters (Re: Do we still value contributions?

[Mo Zhou]

Hi,

Some personal opinions as one of the current batch of FTP trainees.

* The ftp team might be in a (somewhat) negative loop from the
  sustainable development aspect.

Let's first list a couple of facts:
(0) There are a small group of DDs working as ftp-master. Their time and
energy are limited.
(1) ftp-master is doing hard work, reviewing NEW packages, processing
RM bugs, maintaining dak, and recruiting new members to expand the team.
All of these are not trivial things.

(0)+(1) means that: the time that FTP spend on recruiting is quite
limited. Then how "limited" is it?

+ I seriously explained about the slow NEW queue process 2 years ago.
+ I joined the ftp team as trainee about 1 year ago, after 6 months
  since sending out the application mail.
+ the preliminary assessment of the current batch of trainee is still
  not available.
^ My (possibly biased) experience shows that the recruitment process is
  quite slow.

What concerns me most is, what if the FTP team's "quit rate" gets larger
than "expansion rate"? You know what it means from a long-term
perspective.

---

However, accelerating the recruitment process of ftp team looks quite
difficult to all participants, including the ftp-masters and the trainees:

ftp-master:
 * time and energy is limited. doesn't have enough resource to provide
   too much feedbacks to the trainee
 * wants to make sure every new member will be qualified enough to take
   this important role.

trainee:
 * limited time and energy. generally not able to produce a large amount
   of reviews to the NEW packages in a short period of time
 * lacks feed back. they don't know how are they actually doing in
   reviewing the NEW packages.

So accelerating the recruitment process is not easy, given that we will
not lower our quality standards.

---

I think Sean shares some similar feelings.

FTP team shouts for help, and the team seems too "exhausted" to even
accept help ...

I respect all my fellow developers and their endeavor. In this mail
I'm simply describing the fact I saw.


On Wed, Dec 25, 2019 at 11:45:28PM +0200, Jonathan Carter wrote:
> On 2019/12/24 20:08, John Goerzen wrote:
> 
> > But at the same time, I feel that the project as a whole isn't really
> > taking this problem very seriously.
> 
> That is true, probably mostly because many people don't really
> understand that there is a problem. The NEW queue waits are tough, but
> there are also the following which are also often in serious need of
> attention:
> 
>  * Patches attached to bug reports
>  * Request for sponsorships
>  * Merge requests
> 
> Energy put into all areas like that end up paying for itself because it
> helps energize and attract new contributors.
> 
> I try to keep up with sponsorship backlogs (making good strides but
> can't really keep up), which at the same time adds load to the NEW queue
> (11 of my and sponsoree packages stuck in there right now), which I feel
> kind of bad for so I've been trying to join as an FTP team trainee too
> to help out there (which I should probably try to follow-up again but
> that's also been a bit frustrating).
> 
> I think many will agree with you that we should do better in all those
> areas, especially the NEW queue, but change is difficult and in itself
> takes time. In a commercial setting it would probably be easier to
> create incentives to motivate staff to do more review kind of work, but
> I suppose in Debian it's seen as somewhat unglamorous work and we don't
> have many methods to incentivise contributors.
> 
> In particular I think it's important to support events like bug
> squashing parties because it's one of the few things that we can do, and
> encourage things like patch reviews, sponsoring and NEW queue reviews at
> these events and maybe even thank all the people who participate in
> these on a monthly basis in bits from Debian so that maybe this work can
> be highlighted more as something that we do value and might encourage
> more people to get involved there.
> 
> -Jonathan
> 
> -- 
>   ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
>   ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
>   ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
>   ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.
>