Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Tuesday, February 8, 2022 2:45:18 PM EST Paul Gevers wrote:
> Hi,
> 
> Release Team member hat on, but not speaking on behalf of the team. I 
> haven't consulted anybody on the idea I mention below.
> 
> On 08-02-2022 14:59, Scott Kitterman wrote:
> 
> > If people want licensing and copyright issues to be treated like other RC
> > bugs, I think the first step is to treat them like other RC bugs[1].
> 
> 
> I have recently heard about somebody that wanted to do archive wide 
> scanning as a service. At least I am open to add support to britney to 
> block migration on license and copyright issues from such a service. 
> Obviously the service would need to have a reasonable small amount of 
> false positives and we should have an accepted process to handle those 
> false positives.
> 
> Paul

Excellent.  Having something like that in place would make it much easier to 
consider options for reducing friction due to latency of New.

Scott K

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

Re: Legal advice regarding the NEW queue

[Paul Gevers]

Hi,

Release Team member hat on, but not speaking on behalf of the team. I 
haven't consulted anybody on the idea I mention below.


On 08-02-2022 14:59, Scott Kitterman wrote:

If people want licensing and copyright issues to be treated like other RC
bugs, I think the first step is to treat them like other RC bugs[1].


I have recently heard about somebody that wanted to do archive wide 
scanning as a service. At least I am open to add support to britney to 
block migration on license and copyright issues from such a service. 
Obviously the service would need to have a reasonable small amount of 
false positives and we should have an accepted process to handle those 
false positives.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Tuesday, February 8, 2022 8:23:36 AM EST Andreas Tille wrote:
> Am Fri, Feb 04, 2022 at 09:39:09AM -0800 schrieb Russ Allbery:
> > Various people have different reactions to and opinions about the
> > necessity of this review, which I understand and which is great for
> > broadening the discussion.  But I feel like we're starting to lose track
> > of my original point,
> 
> Apropos loosing track. ;-)
> 
> > namely that I don't see why we are prioritizing this
> > particular category of bugs over every other type of bug in Debian.  The
> > justification has always been dire consequences if we don't stamp out all
> > of these bugs, but to be honest I think this is wildly unlikely.
> 
> I fully subscribe to this.
> 
> I'd also like to thank Scott for
>   a) His speedy processing of onetbb (which was the package triggering
>  this thread.
>   b) Taking part in the discussion (as so far only member of the ftpteam
>  TTBOMK)
> 
> I think the point of Scott in this discussion is clear.  However, to my
> understanding it is in contrast to the posting I originally pointed
> to[1].  I would like to hear some official statement for the specific
> case of packages that are in new.
> 
> Specific remark to onetbb:  I'd fully agree with Scott that this might
> be a good example to stress his point since the package was obviously
> not OK and was in serious need of some extra work.  But in the same way
> it serves to support Russ' point as well:  While d/copyright was not OK
> it was probably not OK only according to our strict standards (which I
> subscribe as well) and nothing someone would Debian sue about.  The
> delay in the new queue delayed the Python 3.10 migration and kept
> several other friction points.  So how do we want to weight "just another
> RC bug that should be fixed" against the delay of development in other
> aspects?
> 
> I'd be supper happy if this discussion would lead to some statement
> in some document we could use as reference which would probably avoid
> further discussion of this kind.  I'd even volunteer to draft such
> a document ... if I would only know what should be written.
> 
> Kind regards
> 
>   Andreas.
> 
> [1] https://lists.debian.org/debian-devel/2021/07/msg00231.html

First, once it was pointed out that onetbb was blocking something, it got a 
quick review.  While it doesn't always work out (no need to write in with 
examples of when it didn't), generally if there's feedback that a particular 
package is delaying things it will get processed reasonably quickly.

I know that someone noticing the issue and manually poking the FTP Team for a 
review is still a point of friction, but it's not like we delayed python3.10 
by months or anything.

Upon reflection, I think there may be a certain amount of talking past each 
other going on.

When Russ says treat licensing/copyright bugs like other RC bugs, I think we 
see different things.

>From my point of view, treating something like other common classes of RC bugs 
means that the project is producing tools and processes to make detection of 
such bugs more automated to remove them from the archive, that developers are 
actively looking for them, and that they are routinely fixed in the normal 
course of Debian development.

When it comes to this class of RC bug, I don't see a lot of that happening.  
My suggestion earlier in the thread about there being lots of these issues in 
the archive that could stand fixing wasn't that this is OK, but that it seems 
pretty clear that we are, as a project, not treating these bugs like other RC 
bugs.

I understand Russ meant not block things from the archive until manual review 
has determined they are reasonably OK (New review isn't perfect) in this 
respect.

I don't think what Russ is asking for (as I understand it) is currently 
feasible.  I think our choices today are requiring manual review to at least 
provide some mitigation in this area or give up and decide we don't care.

If developers, as a whole, treated these kinds of bugs with the same 
seriousness they treat other RC bugs, then I think we might be in a different 
position.  None of the work required to get into that different position 
requires changes in New.  I think changing New first is putting the cart before 
the horse [doing things in the wrong order].

If people want licensing and copyright issues to be treated like other RC 
bugs, I think the first step is to treat them like other RC bugs[1].

This is, of course, just my perspective, not a team position.

Scott K

[1] I am aware that there are people doing stuff on this front.  This is not a 
dig at you.

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

Re: Legal advice regarding the NEW queue

[Andreas Tille]

Am Fri, Feb 04, 2022 at 09:39:09AM -0800 schrieb Russ Allbery:
> 
> Various people have different reactions to and opinions about the
> necessity of this review, which I understand and which is great for
> broadening the discussion.  But I feel like we're starting to lose track
> of my original point,

Apropos loosing track. ;-)

> namely that I don't see why we are prioritizing this
> particular category of bugs over every other type of bug in Debian.  The
> justification has always been dire consequences if we don't stamp out all
> of these bugs, but to be honest I think this is wildly unlikely.

I fully subscribe to this.

I'd also like to thank Scott for
  a) His speedy processing of onetbb (which was the package triggering
 this thread.
  b) Taking part in the discussion (as so far only member of the ftpteam
 TTBOMK)

I think the point of Scott in this discussion is clear.  However, to my
understanding it is in contrast to the posting I originally pointed
to[1].  I would like to hear some official statement for the specific
case of packages that are in new.

Specific remark to onetbb:  I'd fully agree with Scott that this might
be a good example to stress his point since the package was obviously
not OK and was in serious need of some extra work.  But in the same way
it serves to support Russ' point as well:  While d/copyright was not OK
it was probably not OK only according to our strict standards (which I
subscribe as well) and nothing someone would Debian sue about.  The
delay in the new queue delayed the Python 3.10 migration and kept
several other friction points.  So how do we want to weight "just another
RC bug that should be fixed" against the delay of development in other
aspects?

I'd be supper happy if this discussion would lead to some statement
in some document we could use as reference which would probably avoid
further discussion of this kind.  I'd even volunteer to draft such
a document ... if I would only know what should be written.

Kind regards

  Andreas.

[1] https://lists.debian.org/debian-devel/2021/07/msg00231.html

-- 
http://fam-tille.de

Re: Legal advice regarding the NEW queue

[Sean Whitton]

Hello,

On Fri 04 Feb 2022 at 11:50PM +01, Christian Kastner wrote:

> On 2022-02-04 18:39, Russ Allbery wrote:
>> In other words, this thread is once again drifting into a discussion of
>> how to do copyright review *better*, when my original point is that we
>> should seriously consider not doing the current type of incredibly tedious
>> and nit-picky copyright review *at all*, and instead rely more on
>> upstream's assertions, automated tools, and being reactive in solving the
>> bugs that people actually care about (i.e., notice).
>
> If we're honest, that's basically how the rest of the open source world
> already operates in general. Our level of scrutiny is a burden that I
> don't see many others sharing.
>
> Of course "everybody's doing it" doesn't make something right. However,
> when things go wrong, they don't seem to go wrong in the dramatic ways
> we might anticipate them to.
>
> If GitHub (a Microsoft-owned entity and thus an attractive target for a
> lawsuit) is OK with distributing files uploaded by third parties without
> subjecting them to a manual review process, perhaps we have been
> overthinking the risks here.

Just to note that GitHub let *others* upload things without reviewing,
such that they're a communications platform (or whatever the legal term
is) not a publisher, but we're a publisher.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[John Goerzen]

On Fri, Feb 04 2022, Russ Allbery wrote:

> Scott correctly points out that there are a ton of copyright bugs in
> Debian *anyway*, despite NEW review.  He sees this as a reason for not
> relaxing our review standards.  I see it as the exact opposite: evidence
> that our current review standards are not achieving the 100% correctness
> we have claimed to be striving for, and the nearly complete lack of
> practical consequences for that failure.  It really seems to me like
> evidence that this task is not as important as we think it is.

Well put.  I'd like to expand a bit:

Philip Hands pointed out that we can't download packages in NEW.  It
seems we have a sort of 1990s approach here.

I want to stipulate up-front that it is good and necessary to have
quality controls over what goes into a distribution.

But it is, in 2022, no longer accurate to think that preventing
downloads from NEW prevents Debian from distributing code.  We do, after
all, run salsa, with CI builders, we have people.debian.org, and all
sorts of other places - none of which require any kind of review, at
all.

So if we set aside technical quality, as a legal matter, we have
decided:

1. It is OK to distribute completely unreviewed code from salsa, people,
   planet, etc, etc.

2. It is not OK to distribute unreviewed code from NEW

3. It is not OK to distribute code from unstable or experimental without
   a copyright review

4. It is not OK to distribute code from stable or testing without a
   copyright review

It seems to me that #4 is the strongest argument we can make.  #1 and #2
seem to me practically the same, and even #3 is along those lines.  I
think #1 and #2 are logically inconsistent, in fact.  Perhaps #1 is
inconsistent with all the rest, in fact.

Now to return to your point: I think it is certain that there are even
more un-surfaced issues present on salsa, and yet we have had, AFAIK,
zero issues there.

Is there any fundamental reason that we focus on NEW with such rigidity
other than simply because we always have?

John

Re: Legal advice regarding the NEW queue

[Christian Kastner]

On 2022-02-05 16:07, Andrew M.A. Cater wrote:
> Just because someone else can't be bothered to do licence review checking
> doesn't mean that Debian shouldn't. 

I wasn't advocating against license review checking in general, though.
We expect and trust all contributors to do that.

The question as I see it is: why do we need another party (ftp-master)
to verify that first review. It's a major bottleneck to everyone, a huge
burden to the ftp-master team.

As far as I can recall, the argument has always been that is necessary
for liability reasons. My point is that I don't recall every seeing such
a liability materialize with other projects, so perhaps our assumptions
about the magnitude of this issue are wrong. (Or I'm just ignorant about
such cases.)

> I'd much rather that packages were removed in NEW than that they got
> installed in unstable and we then had to tell people that they had
> gone.

> There's a huge amount of software that's undistributable: Debian's good faith
> attempt to review this is one of the crucial arguments I have with $DAYJOB
> about the benefits of a curated distribution, however fallible we may be.

Fair enough.

Re: Legal advice regarding the NEW queue

[Julien Puydt]

Le samedi 05 février 2022 à 15:07 +, Andrew M.A. Cater a écrit :
> There's a huge amount of software that's undistributable: Debian's
> good faith attempt to review this is one of the crucial arguments I
> have with $DAYJOB about the benefits of a curated distribution,
> however fallible we may be.

That is a strong point and a main difference in quality with other
distributions.

> I think we should use automated tools where available, query with
> upstream where practicable, and continue doing what we're doing as
> far as possible, in my humble opinion.

I would see the screening like this:

- only source uploads are allowed (NEW and all) ;

- automatic building of binary packages ;

- automatic tools try to find problems (licensing and all) ;

- as a last step, human checks for license issues in NEW and randomly
on existing packages. At least if they have seen updates since their
NEW review -- I'm wondering how many packages are a one-time shot?

> Reproducible builds and DEP-5 / SPDX are also crucial in improving
> everyone's quality - I don't see commercial/enterprise distributions
> doing this valuable public service but I very much value the fact
> that Debian does it, for example.

I would add our network of buildd/porterbox to the list of good things
we can boast about.

Cheers,

J.Puydt

Re: Legal advice regarding the NEW queue

[Andrew M.A. Cater]

On Fri, Feb 04, 2022 at 11:50:20PM +0100, Christian Kastner wrote:
> On 2022-02-04 18:39, Russ Allbery wrote:
> > In other words, this thread is once again drifting into a discussion of
> > how to do copyright review *better*, when my original point is that we
> > should seriously consider not doing the current type of incredibly tedious
> > and nit-picky copyright review *at all*, and instead rely more on
> > upstream's assertions, automated tools, and being reactive in solving the
> > bugs that people actually care about (i.e., notice).
> 
> If we're honest, that's basically how the rest of the open source world
> already operates in general. Our level of scrutiny is a burden that I
> don't see many others sharing.
> 
> Of course "everybody's doing it" doesn't make something right. However,
> when things go wrong, they don't seem to go wrong in the dramatic ways
> we might anticipate them to.
> 
> If GitHub (a Microsoft-owned entity and thus an attractive target for a
> lawsuit) is OK with distributing files uploaded by third parties without
> subjecting them to a manual review process, perhaps we have been
> overthinking the risks here.
>

Just because someone else can't be bothered to do licence review checking
doesn't mean that Debian shouldn't. I'd much rather that packages were
removed in NEW than that they got installed in unstable and we then had
to tell people that they had gone.

There's a huge amount of software that's undistributable: Debian's good faith
attempt to review this is one of the crucial arguments I have with $DAYJOB
about the benefits of a curated distribution, however fallible we may be.

I think we should use automated tools where available, query with upstream
where practicable, and continue doing what we're doing as far as possible,
in my humble opinion.

Reproducible builds and DEP-5 / SPDX are also crucial in improving everyone's 
quality - I don't see commercial/enterprise distributions doing this
valuable public service but I very much value the fact that Debian does
it, for example.

[No particular skin in the game, since I don't upload any package at
the moment but very appreciative of others' efforts]

With every good wish, as ever,

Andy Cater

[amaca...@debian.org] 

Re: Legal advice regarding the NEW queue

[Philip Hands]

Scott Kitterman  writes:

> On Friday, February 4, 2022 6:24:56 PM EST Philip Hands wrote:
>> Scott Kitterman  writes:
>> 
>> ...
>> 
>> > Currently the only answer is join the FTP Team as a trainee when there
>> > is a call for volunteers. I totally get the frustration.
>> 
>> People could always just send additional data points to the relevant ITP
>> bug, like this:
>> 
>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004021#10
>> 
>> If that's actually useful for FTP team members, it could be encouraged
>> on the New queue page.
>> 
>> A link to a wiki page with suggestions of what to check, and how best to
>> submit reports in order to make them most useful would probably do the
>> trick.
>> 
>> Would that actually help?
>
> I'm not sure what the best solution is as far as notification goes.  
> Generally 
> we don't look at the ITP when reviewing packages (ITP isn't even required, so 
> it's really outside our scope).

I only went for that because it is at least linked to from the New entry
(if there's an ITP).

> A comment to the ITP should get to the original packager. If it's a
> worthwhile issue they can fix and re-upload.
>
> Most packages are currently available on Salsa even though not directly 
> available through the New queue.  A copy of the New queue does exist on 
> coccia, but it's not currently readable for non-FTP Team members.  It's 
> probably not too hard to change that if it turns out having other DDs review 
> things is useful.
>
> Right to the ITP bug and mention it on #debian-ftp might not be a bad way to 
> start experimenting with external reviews.

OK, done that, so let's see if it's deemed useful.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Friday, February 4, 2022 6:24:56 PM EST Philip Hands wrote:
> Scott Kitterman  writes:
> 
> ...
> 
> > Currently the only answer is join the FTP Team as a trainee when there
> > is a call for volunteers. I totally get the frustration.
> 
> People could always just send additional data points to the relevant ITP
> bug, like this:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004021#10
> 
> If that's actually useful for FTP team members, it could be encouraged
> on the New queue page.
> 
> A link to a wiki page with suggestions of what to check, and how best to
> submit reports in order to make them most useful would probably do the
> trick.
> 
> Would that actually help?

I'm not sure what the best solution is as far as notification goes.  Generally 
we don't look at the ITP when reviewing packages (ITP isn't even required, so 
it's really outside our scope).  A comment to the ITP should get to the 
original packager.  If it's a worthwhile issue they can fix and re-upload.

Most packages are currently available on Salsa even though not directly 
available through the New queue.  A copy of the New queue does exist on 
coccia, but it's not currently readable for non-FTP Team members.  It's 
probably not too hard to change that if it turns out having other DDs review 
things is useful.

Right to the ITP bug and mention it on #debian-ftp might not be a bad way to 
start experimenting with external reviews.

Scott K

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

Re: Legal advice regarding the NEW queue

[Philip Hands]

Scott Kitterman  writes:

...
> Currently the only answer is join the FTP Team as a trainee when there
> is a call for volunteers. I totally get the frustration.

People could always just send additional data points to the relevant ITP
bug, like this:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004021#10

If that's actually useful for FTP team members, it could be encouraged
on the New queue page.

A link to a wiki page with suggestions of what to check, and how best to
submit reports in order to make them most useful would probably do the
trick.

Would that actually help?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Christian Kastner]

On 2022-02-04 18:39, Russ Allbery wrote:
> In other words, this thread is once again drifting into a discussion of
> how to do copyright review *better*, when my original point is that we
> should seriously consider not doing the current type of incredibly tedious
> and nit-picky copyright review *at all*, and instead rely more on
> upstream's assertions, automated tools, and being reactive in solving the
> bugs that people actually care about (i.e., notice).

If we're honest, that's basically how the rest of the open source world
already operates in general. Our level of scrutiny is a burden that I
don't see many others sharing.

Of course "everybody's doing it" doesn't make something right. However,
when things go wrong, they don't seem to go wrong in the dramatic ways
we might anticipate them to.

If GitHub (a Microsoft-owned entity and thus an attractive target for a
lawsuit) is OK with distributing files uploaded by third parties without
subjecting them to a manual review process, perhaps we have been
overthinking the risks here.

Re: Legal advice regarding the NEW queue

[Russ Allbery]

Timo Röhling  writes:

> The FTP team review should focus on these types of mistakes, and not
> only with new packages: any "suspicious" upload should be rerouted to a
> POLICY queue for additional verification.  There is some prior art with
> the auto-REJECT on Lintian errors, which could be extended to a
> three-way decision (ACCEPT, POLICY REVIEW, REJECT).

I feel like it would also be a lot easier to get volunteers to look at
packages that had already been flagged, rather than do green-field reviews
of every package everyone uploads (most of which are entirely fine or have
at most minor issues).  It certainly feels like a more interesting problem
to me!  "Here are a few things that looked weird, please manually look at
this package to see if they're a problem."

Or even "this package has maintainer scripts that aren't just
debhelper-generated boilerplate, please look at them and make sure they're
not going to run rm -r / or something crazy."

> For instance, we could flag epoch bumps or major version numbers which
> skip ahead significantly (think 020220101 instead of 0.20220101). We can
> certainly continue to flag new binaries and potential copyright
> violations (e.g., packages with incompatible licenses or files with
> "(?i)(?:do|must) not distribute" in their headers), or anything else we
> consider important. The automated checks need not be perfect as long as
> we avoid false negatives on the critical issues.

Exactly.  We're not going to catch everything, to be sure, but we're not
catching everything *now*, and improvements of automation scale in ways
that trying to do more painstaking human review do not.

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

Re: Legal advice regarding the NEW queue

[Timo Röhling]

* Russ Allbery  [2022-02-04 11:48]:

No, that's fine, that's not a strawman argument.  That is, in fact, my
argument: I think it should be okay to put crap packages in the unstable
archive and fix them later, and I would rather put more effort into the
"noticing" part than in the pre-review part.

[...]

Now, all of that being said, I also want to say that I'm sketching out one
end of the argument because I think that end has been underrepresented.  I
don't think this is an all-or-nothing binary choice.  We could, for
example, focus our review on only packages that are viewed as riskier
(only packages with maintainer scripts or that start daemons, for
instance, or stop doing NEW review for packages uploaded under the
auspices of well-established Debian teams, or stop doing NEW review for
shared libraries whose source packages are already in Debian), all of
which would be improvements from my perspective. 

In my opinion, this is a very important train of thought, because
not all crap is created equal. While some things can be fixed easily
with a new upload, others have permanent repercussions, for example:

- It is impossible to undo an epoch bump, or more
  generally, revert to an earlier version number.
- The package namespace can be polluted, or existing names can be
  hijacked, potentially rendering names unusuable
  for future uploads (particularly if the hijacking version number is
  sufficiently large and/or epoch'd).

I'm not implying any ill-will, merely observing that people make
mistakes, and some mistakes are more costly to rectify than others.

The FTP team review should focus on these types of mistakes, and not
only with new packages: any "suspicious" upload should be rerouted
to a POLICY queue for additional verification.  There is some prior
art with the auto-REJECT on Lintian errors, which could be
extended to a three-way decision (ACCEPT, POLICY REVIEW, REJECT).

For instance, we could flag epoch bumps or major version numbers
which skip ahead significantly (think 020220101 instead of
0.20220101). We can certainly continue to flag new binaries and
potential copyright violations (e.g., packages with incompatible
licenses or files with "(?i)(?:do|must) not distribute" in their
headers), or anything else we consider important. The automated
checks need not be perfect as long as we avoid false negatives on
the critical issues. And I imagine it will also speed up the review
considerably if the FTP team already knows what problems (not) to
look for.


Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Friday, February 4, 2022 2:48:50 PM EST Russ Allbery wrote:
> Scott Kitterman  writes:
> > Since we're doing strawman arguments in this thread: I disagree with the
> > notion that it's not a problem to put crap packages in the archive and
> > fix them later if anyone happens to notice.
> 
> No, that's fine, that's not a strawman argument.  That is, in fact, my
> argument: I think it should be okay to put crap packages in the unstable
> archive and fix them later, and I would rather put more effort into the
> "noticing" part than in the pre-review part.
> 
> We may quibble about what "crap" means and we may disagree about how much
> of this potentially could be weeded by automated tools (and I want to be
> very clear that I'm not opposed to automated checks and indeed think we
> should make them stricter), but I think this is a blunt but fair
> characterization of my position.
> 
> To be clear on the nuance I see here, I don't mean that this is "okay" in
> the sense that people should feel fine about doing it.  I think we should
> all aspire to not do that, of course.  But I think it should be "okay" in
> the sense that I don't think we should invest the level of resources we're
> currently investing in trying to avoid it, because I think that's causing
> other significant problems for the project.
> 
> My argument in favor of this position is that while it's very obvious to
> see the harm from having crap packages in the archive, we're overlooking
> the very substantial cost we're paying with our current method of trying
> to reduce the frequency with which this happens.  I think we're
> underestimating just how costly and demoralizing dealing with NEW delays
> is for project work, and also how much of a drain and competition for
> resources that is with other archive work that we could be doing.
> 
> For example, in just the past two months I have seen two *extremely
> experienced* Debian developers who maintain extremely high-quality
> packages express qualms about package architectures that would fix other
> bugs in Debian *solely* because they would force more trips through NEW
> and the trip through NEW is so disruptive to their work that it was at
> least tempting to accept other bugs in order to avoid that disruption.  To
> me, this indicates that we may have our priorities out of alignment.
> 
> Now, all of that being said, I also want to say that I'm sketching out one
> end of the argument because I think that end has been underrepresented.  I
> don't think this is an all-or-nothing binary choice.  We could, for
> example, focus our review on only packages that are viewed as riskier
> (only packages with maintainer scripts or that start daemons, for
> instance, or stop doing NEW review for packages uploaded under the
> auspices of well-established Debian teams, or stop doing NEW review for
> shared libraries whose source packages are already in Debian), all of
> which would be improvements from my perspective.  We could also do some
> parts of NEW review and not others and see if that makes it more
> attractive for other people to volunteer.  (The manual review for
> d/copyright correctness is certainly the part of NEW review that I can't
> imagine volunteering to do, and I suspect I'm not alone.)
> 
> To be clear, as long as the rules in Debian are what they are, I will of
> course follow them as I promised to do when I became a Debian Developer.
> If the project continues to believe that it is of primary importance for
> us to be the copyright notice and license catalog review system for the
> entire free software ecosystem (which is honestly what it feels like we've
> currently decided to volunteer to do on top of our goal of building a
> distribution), then I will do my part with the packages that I upload so
> that I don't put unnecessary load on the folks doing NEW review.  But when
> we've collectively been doing something for so long, we can lose track of
> the fact that it's a choice, and other choices are possible.  It's worth
> revisiting those choices consciously from time to time.

OK.  Fair enough.  I think your assessment of the costs of the current 
approach is reasonable.

I've seen several assertions that more could be done to detect and correct 
problems in the archive, which would make New review less important, but these 
discussions all seem to start with the assertion that we should throw out the 
current system and then something good will happen.  I think that puts the 
cart before the horse.

Personally, if someone had a system that could post-process uploads and 
identify which licenses are in use and if there are any incompatibilities, I 
think that would go a long way towards moving the balance in the direction you 
are advocating for.  Speaking just for myself, packages that are 
undistributable due to lack of licensing or use of incompatible licenses which 
impairs sublicensabiltiy is a large concern.  Whether we drop New or not, I 
think that would be great 

Re: Legal advice regarding the NEW queue

[Russ Allbery]

Scott Kitterman  writes:

> Since we're doing strawman arguments in this thread: I disagree with the
> notion that it's not a problem to put crap packages in the archive and
> fix them later if anyone happens to notice.

No, that's fine, that's not a strawman argument.  That is, in fact, my
argument: I think it should be okay to put crap packages in the unstable
archive and fix them later, and I would rather put more effort into the
"noticing" part than in the pre-review part.

We may quibble about what "crap" means and we may disagree about how much
of this potentially could be weeded by automated tools (and I want to be
very clear that I'm not opposed to automated checks and indeed think we
should make them stricter), but I think this is a blunt but fair
characterization of my position.

To be clear on the nuance I see here, I don't mean that this is "okay" in
the sense that people should feel fine about doing it.  I think we should
all aspire to not do that, of course.  But I think it should be "okay" in
the sense that I don't think we should invest the level of resources we're
currently investing in trying to avoid it, because I think that's causing
other significant problems for the project.

My argument in favor of this position is that while it's very obvious to
see the harm from having crap packages in the archive, we're overlooking
the very substantial cost we're paying with our current method of trying
to reduce the frequency with which this happens.  I think we're
underestimating just how costly and demoralizing dealing with NEW delays
is for project work, and also how much of a drain and competition for
resources that is with other archive work that we could be doing.

For example, in just the past two months I have seen two *extremely
experienced* Debian developers who maintain extremely high-quality
packages express qualms about package architectures that would fix other
bugs in Debian *solely* because they would force more trips through NEW
and the trip through NEW is so disruptive to their work that it was at
least tempting to accept other bugs in order to avoid that disruption.  To
me, this indicates that we may have our priorities out of alignment.

Now, all of that being said, I also want to say that I'm sketching out one
end of the argument because I think that end has been underrepresented.  I
don't think this is an all-or-nothing binary choice.  We could, for
example, focus our review on only packages that are viewed as riskier
(only packages with maintainer scripts or that start daemons, for
instance, or stop doing NEW review for packages uploaded under the
auspices of well-established Debian teams, or stop doing NEW review for
shared libraries whose source packages are already in Debian), all of
which would be improvements from my perspective.  We could also do some
parts of NEW review and not others and see if that makes it more
attractive for other people to volunteer.  (The manual review for
d/copyright correctness is certainly the part of NEW review that I can't
imagine volunteering to do, and I suspect I'm not alone.)

To be clear, as long as the rules in Debian are what they are, I will of
course follow them as I promised to do when I became a Debian Developer.
If the project continues to believe that it is of primary importance for
us to be the copyright notice and license catalog review system for the
entire free software ecosystem (which is honestly what it feels like we've
currently decided to volunteer to do on top of our goal of building a
distribution), then I will do my part with the packages that I upload so
that I don't put unnecessary load on the folks doing NEW review.  But when
we've collectively been doing something for so long, we can lose track of
the fact that it's a choice, and other choices are possible.  It's worth
revisiting those choices consciously from time to time.

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

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Friday, February 4, 2022 12:39:09 PM EST Russ Allbery wrote:
> The Wanderer  writes:
> > What I read Scott as having been suggesting, by contrast, is that people
> > instead do copyright review for packages already in Debian, which may
> > well have had changes that did not have to pass through NEW and that
> > might not have been able to pass the NEW copyright review.
> > 
> > If a practice of doing that latter were established and sufficiently
> > widespread, then it would not be as important to do the review for every
> > package in NEW, and the FTP team might feel less of a need to insist
> > that the review take place at that stage of things.
> 
> Various people have different reactions to and opinions about the
> necessity of this review, which I understand and which is great for
> broadening the discussion.  But I feel like we're starting to lose track
> of my original point, namely that I don't see why we are prioritizing this
> particular category of bugs over every other type of bug in Debian.  The
> justification has always been dire consequences if we don't stamp out all
> of these bugs, but to be honest I think this is wildly unlikely.
> 
> In other words, this thread is once again drifting into a discussion of
> how to do copyright review *better*, when my original point is that we
> should seriously consider not doing the current type of incredibly tedious
> and nit-picky copyright review *at all*, and instead rely more on
> upstream's assertions, automated tools, and being reactive in solving the
> bugs that people actually care about (i.e., notice).
> 
> In other words, what if, when upstream said "this whole package is covered
> by the MIT license," we just defaulted to believing them?  And if there's
> some file buried in there that's actually covered by the GPL, we fixed
> that when someone brought it to our attention, or when we were able to
> detect it with automated tools, but we didn't ask people to spend hours
> reviewing the license headers on every source file?  What, concretely,
> would go wrong?
> 
> Scott correctly points out that there are a ton of copyright bugs in
> Debian *anyway*, despite NEW review.  He sees this as a reason for not
> relaxing our review standards.  I see it as the exact opposite: evidence
> that our current review standards are not achieving the 100% correctness
> we have claimed to be striving for, and the nearly complete lack of
> practical consequences for that failure.  It really seems to me like
> evidence that this task is not as important as we think it is.

A substantial fraction of packages uploaded to New are not deemed to be 
sufficiently policy compliant to enter the archive.  I don't have numbers, but 
if it was more than a quarter of them, I wouldn't be surprised.  It's true 
that the bulk of that is due to copyright/license issues, but it's not all of 
it.  While most of the severe bugs we find are in this area, that's not all we 
look for.

I disagree with the premise that all DDs can and do create packages of 
sufficient quality that no check point is needed to assess them before they 
enter the archive.  My experience is that this is just not true.  We review a 
lot of genuinely awful stuff that's uploaded even when it's known there will be 
a review in New.

If we kept the New queue in place, but didn't review the correctness of d/
copyright, it would make it faster to review packages, but I don't think it 
makes sense to make that one aspect of policy that the FTP Team decides to 
ignore.  I think most of your argument is with Policy 2.3.

We don't search out the true source/licensing of files in the packages we 
review.  There are cases where the upstream file indicates it was copies from 
elsewhere and the license/copyright attribution is ignored, but generally we 
assume that what is in the package is correct.

Since we're doing strawman arguments in this thread: I disagree with the 
notion that it's not a problem to put crap packages in the archive and fix them 
later if anyone happens to notice.

Scott K

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

Re: Legal advice regarding the NEW queue

[Russ Allbery]

The Wanderer  writes:

> What I read Scott as having been suggesting, by contrast, is that people
> instead do copyright review for packages already in Debian, which may
> well have had changes that did not have to pass through NEW and that
> might not have been able to pass the NEW copyright review.

> If a practice of doing that latter were established and sufficiently
> widespread, then it would not be as important to do the review for every
> package in NEW, and the FTP team might feel less of a need to insist
> that the review take place at that stage of things.

Various people have different reactions to and opinions about the
necessity of this review, which I understand and which is great for
broadening the discussion.  But I feel like we're starting to lose track
of my original point, namely that I don't see why we are prioritizing this
particular category of bugs over every other type of bug in Debian.  The
justification has always been dire consequences if we don't stamp out all
of these bugs, but to be honest I think this is wildly unlikely.

In other words, this thread is once again drifting into a discussion of
how to do copyright review *better*, when my original point is that we
should seriously consider not doing the current type of incredibly tedious
and nit-picky copyright review *at all*, and instead rely more on
upstream's assertions, automated tools, and being reactive in solving the
bugs that people actually care about (i.e., notice).

In other words, what if, when upstream said "this whole package is covered
by the MIT license," we just defaulted to believing them?  And if there's
some file buried in there that's actually covered by the GPL, we fixed
that when someone brought it to our attention, or when we were able to
detect it with automated tools, but we didn't ask people to spend hours
reviewing the license headers on every source file?  What, concretely,
would go wrong?

Scott correctly points out that there are a ton of copyright bugs in
Debian *anyway*, despite NEW review.  He sees this as a reason for not
relaxing our review standards.  I see it as the exact opposite: evidence
that our current review standards are not achieving the 100% correctness
we have claimed to be striving for, and the nearly complete lack of
practical consequences for that failure.  It really seems to me like
evidence that this task is not as important as we think it is.

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

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Friday, February 4, 2022 4:00:44 AM EST Philip Hands wrote:
> Scott Kitterman  writes:
> 
> ...
> 
> > My impression is that people are tired of waiting on New, but no one
> > really seems to be interested in doing any work on any alternative
> > other than more bugs.
> 
> Part of the problem is that New processing is a bit of a black box, so
> it's not clear to those of us outside the team how we could help.
> 
> (or at least, not clear to me -- links welcome).
> 
> As a random example, I noticed John Goerzen's post[1] about Yggdrasil on
> planet.d.o last month. John has since uploaded a package.
> 
> As I write it's still in New[2], which is no great shock, as it's only
> been a couple of weeks.
> 
> I'm quite keen to give it a spin.
> 
> So, what can we do with that enthusiasm:
> 
>   I could grab the source and build it locally.
> 
>   I could squander my enthusiasm by waiting for New.
> 
>   I could complain about not being able to download from New, and if if
>   the FTP team listened to me, the enthusiasm would immediately become
>   unavailable to others, as I'd not be feeling frustrated any more.
> 
>   If I knew how to do it, and there were some obvious method, I could
>   contribute to reviewing the package I want to see in the archive.
> 
> On reflection, I think that removing the bottle-neck of New would be a
> mistake, as it would the remove the itch we all want to scratch.
> 
> Instead please just provide us with the ability to scratch that itch and
> you may find that you suddenly have quite a few more volunteers.
> 
> In the example above, eventually I will get sufficiently bored of
> waiting to build the package myself, which will probably be rather more
> effort than reviewing it would have been, so I'd much rather be able to
> apply that effort in a way that benefits more than just me.

I think that all makes sense.  Currently the only answer is join the FTP Team 
as a trainee when there is a call for volunteers.  I totally get the 
frustration.

I'm not sure how much value there is in drive-by reviews as a general case.  I 
suppose if external reviews were done it could identify reject cases that 
would mean the FTP Team could spend more time on packages that might be 
accepted.  I don't expect an external review that said "It's fine, recommend 
you accept it" would cause any FTP Team member to blindly accept the package.

I'll consider if there's not perhaps some middle ground so that we can see if 
there are enough volunteers to make a dent in things.

Scott K

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

Re: Legal advice regarding the NEW queue

[The Wanderer]

On 2022-02-04 at 04:00, Philip Hands wrote:

> Scott Kitterman  writes:
> 
> ...
>> My impression is that people are tired of waiting on New, but no
>> one really seems to be interested in doing any work on any
>> alternative other than more bugs.
> 
> Part of the problem is that New processing is a bit of a black box,
> so it's not clear to those of us outside the team how we could help.
> 
> (or at least, not clear to me -- links welcome).
> 
> As a random example, I noticed John Goerzen's post[1] about Yggdrasil
> on planet.d.o last month. John has since uploaded a package.
> 
> As I write it's still in New[2], which is no great shock, as it's
> only been a couple of weeks.

If I read your response (and Andrei's) correctly, you're approaching
this in terms of providing copyright reviews for packages waiting in
NEW, to relieve some of the burden on the FTP team and speed up the
processing of those packages through NEW.

What I read Scott as having been suggesting, by contrast, is that people
instead do copyright review for packages already in Debian, which may
well have had changes that did not have to pass through NEW and that
might not have been able to pass the NEW copyright review.

If a practice of doing that latter were established and sufficiently
widespread, then it would not be as important to do the review for every
package in NEW, and the FTP team might feel less of a need to insist
that the review take place at that stage of things.

> On reflection, I think that removing the bottle-neck of New would be
> a mistake, as it would the remove the itch we all want to scratch.
> 
> Instead please just provide us with the ability to scratch that itch
> and you may find that you suddenly have quite a few more volunteers.

I do, however, concur with these sentiments. Expanding the sphere of
those who can to provide reviews (if not necessarily grant approvals) to
packages in NEW might well be a good idea.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Legal advice regarding the NEW queue

[Philip Hands]

Scott Kitterman  writes:

...
> My impression is that people are tired of waiting on New, but no one
> really seems to be interested in doing any work on any alternative
> other than more bugs.

Part of the problem is that New processing is a bit of a black box, so
it's not clear to those of us outside the team how we could help.

(or at least, not clear to me -- links welcome).

As a random example, I noticed John Goerzen's post[1] about Yggdrasil on
planet.d.o last month. John has since uploaded a package.

As I write it's still in New[2], which is no great shock, as it's only
been a couple of weeks.

I'm quite keen to give it a spin.

So, what can we do with that enthusiasm:

  I could grab the source and build it locally.

  I could squander my enthusiasm by waiting for New.

  I could complain about not being able to download from New, and if if
  the FTP team listened to me, the enthusiasm would immediately become
  unavailable to others, as I'd not be feeling frustrated any more.

  If I knew how to do it, and there were some obvious method, I could
  contribute to reviewing the package I want to see in the archive.

On reflection, I think that removing the bottle-neck of New would be a
mistake, as it would the remove the itch we all want to scratch.

Instead please just provide us with the ability to scratch that itch and
you may find that you suddenly have quite a few more volunteers.

In the example above, eventually I will get sufficiently bored of
waiting to build the package myself, which will probably be rather more
effort than reviewing it would have been, so I'd much rather be able to
apply that effort in a way that benefits more than just me.

I fully expect the act of building my own package to precede the package
passing New by about a day :-/I think this is a pretty depressing
scenario, which dampens the enthusiasm of all involved on each repeat.

Cheers, Phil.

[1] 
https://changelog.complete.org/archives/10319-make-the-internet-yours-again-with-an-instant-mesh-network

[2] https://ftp-master.debian.org/new/yggdrasil_0.4.2-1.html
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Andrei POPESCU]

On Jo, 03 feb 22, 18:55:44, Scott Kitterman wrote:
> On Thursday, February 3, 2022 2:40:08 PM EST Phil Morrell wrote:
> > 
> > That is not the challenge being made here. I don't believe anyone is
> > arguing that licensing documentation bugs would be anything other than
> > RC bugs according to policy §2.3, just that NEW processing is not the
> > only possible mitigation for the Debian project's legal risk.
> 
> Right, but my point is that anyone who wants to work on identifying licensing 
> and copyright documentation issues in the archive is free to do so today.  
> Anyone can file them and, given appropriate deference to the NMU procedures, 
> anyone can fix them.  Nothing the FTP Team is doing or not doing prevents 
> that.

From the outside (non-DD, lurking for 15 years or so) the FTP Team 
appears to be adamant that the current process is The Only True Way to 
do copyright review.
 
> If someone thinks that there is a viable alternate method, then they should 
> demonstrate it.  You do not need anyone's permission.

Without a clear statement from the FTP Team that alternative copyright 
review processes might even be considered there is very little 
motivation for anyone to even start working on it.

The start could be something as simple as "we (the FTP Team) will 
prioritise packages in NEW that have at least $number of reviews from 
other DDs".

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Thursday, February 3, 2022 2:40:08 PM EST Phil Morrell wrote:
> On Thu, Feb 03, 2022 at 09:43:16AM -0500, Scott Kitterman wrote:
> > I am a member of the FTP Team and have been participating, at least a bit,
> > in this thread.  I am not, however, speaking for the team.
> 
> Hello Scott, thank you for taking the time to follow this thread, there
> are two very specific questions outstanding that those outside the FTP
> team would like an answer to - if you're not willing to speak for the
> team on these then please can you encourage internal discussion and
> announcement of the team's opinion.
> 
> 1. Is it ftpmaster's opinion and policy that there is no difference in
> NEW queue review process between bin and src?
>Namely that a full copyright review is necessary to catch the kind of
> issues you noticed and so it is unhelpful to ping a mention on e.g. IRC
> that something only needs a lighter review.
>Alternatively, is it true that bin-NEW is primarily about
> non-copyright checks and only if something looks egregiously wrong it
> becomes subject to a full review which may take more time.
> 
> https://lists.debian.org/debian-devel/2022/01/msg00226.html
> 
> > I would certainly not support the notion that we have too few licensing
> > documentation bugs in the archive and we can afford to dismantle the one
> > process we have in place that actually makes a difference in this area.
> 
> That is not the challenge being made here. I don't believe anyone is
> arguing that licensing documentation bugs would be anything other than
> RC bugs according to policy §2.3, just that NEW processing is not the
> only possible mitigation for the Debian project's legal risk.

Right, but my point is that anyone who wants to work on identifying licensing 
and copyright documentation issues in the archive is free to do so today.  
Anyone can file them and, given appropriate deference to the NMU procedures, 
anyone can fix them.  Nothing the FTP Team is doing or not doing prevents that.

If someone thinks that there is a viable alternate method, then they should 
demonstrate it.  You do not need anyone's permission.

> 2. Is the ftpmaster team willing and able to select someone to represent
> the team in a collaboration with non-team members to seek further legal
> council on the current NEW copyright practices?
>Specifically, to compile a list of questions in advance and join a
> call where these questions are put, communicate the results to the team
> and obviously have buy-in that any changes needed can be worked with.
>As examples, there are doubts over: the "abundance of caution"
> approach to avoiding redistribution during the review; the above
> mentioned copyright review for bin-NEW; whether RC licensing bugs should
> be treated differently to other RC bugs.
> 
> https://lists.debian.org/debian-devel/2022/01/msg00359.html
> 
> I really hope you can help get the answers to these two questions,
> because without it there doesn't seem to be a way forward for those with
> time available outside the ftpmaster team.

I can't really address that, but there are other reasons than legal risks to 
follow Debian policy.  My impression is that people are tired of waiting on 
New, but no one really seems to be interested in doing any work on any 
alternative other than more bugs.  I'm not sure how a lawyer can tell you how 
many bugs are acceptable.

Scott K

P.S. I am subscribed, so no need to cc me.


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

Re: Legal advice regarding the NEW queue

[Phil Morrell]

On Thu, Feb 03, 2022 at 09:43:16AM -0500, Scott Kitterman wrote:
> I am a member of the FTP Team and have been participating, at least a bit, in 
> this thread.  I am not, however, speaking for the team.

Hello Scott, thank you for taking the time to follow this thread, there
are two very specific questions outstanding that those outside the FTP
team would like an answer to - if you're not willing to speak for the
team on these then please can you encourage internal discussion and
announcement of the team's opinion.

1. Is it ftpmaster's opinion and policy that there is no difference in
NEW queue review process between bin and src?
   Namely that a full copyright review is necessary to catch the kind of
issues you noticed and so it is unhelpful to ping a mention on e.g. IRC
that something only needs a lighter review.
   Alternatively, is it true that bin-NEW is primarily about
non-copyright checks and only if something looks egregiously wrong it
becomes subject to a full review which may take more time.

https://lists.debian.org/debian-devel/2022/01/msg00226.html

> I would certainly not support the notion that we have too few licensing 
> documentation bugs in the archive and we can afford to dismantle the one 
> process we have in place that actually makes a difference in this area.

That is not the challenge being made here. I don't believe anyone is
arguing that licensing documentation bugs would be anything other than
RC bugs according to policy §2.3, just that NEW processing is not the
only possible mitigation for the Debian project's legal risk.

2. Is the ftpmaster team willing and able to select someone to represent
the team in a collaboration with non-team members to seek further legal
council on the current NEW copyright practices?
   Specifically, to compile a list of questions in advance and join a
call where these questions are put, communicate the results to the team
and obviously have buy-in that any changes needed can be worked with.
   As examples, there are doubts over: the "abundance of caution"
approach to avoiding redistribution during the review; the above
mentioned copyright review for bin-NEW; whether RC licensing bugs should
be treated differently to other RC bugs.

https://lists.debian.org/debian-devel/2022/01/msg00359.html

I really hope you can help get the answers to these two questions,
because without it there doesn't seem to be a way forward for those with
time available outside the ftpmaster team.


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Wednesday, February 2, 2022 1:21:38 PM EST Alec Leamas wrote:
> Dear list,
> 
> On 02/02/2022 18:46, Michael Stone wrote:
> > On Wed, Feb 02, 2022 at 10:16:36PM +0500, Andrey Rahmatullin wrote:
> >> On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote:
> >>> On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote:
> >>> > Doesn't that, then, lead to the suggestion that any package entering
> >>> > unstable without having undergone NEW review (which, in the revised
> >>> > model, might be every new package) should automatically have a bug
> >>> 
> >>> filed
> >>> 
> >>> > against it requesting suitable review, and that bug should be
> >>> 
> >>> treated as
> >>> 
> >>> > a blocker for entering testing?
> >>> 
> >>> Not really, since anyone in the world could close said bug (including
> >>> the
> >>> uploader).
> >> 
> >> This applies to any RC bug.
> > 
> > Yes, but in this case it means that we wouldn't have that minimal
> > standard of at least one person other than the uploader having ever
> > reviewed the package--which I think is a fairly low bar that we should
> > meet. (It would be even better if we could add reviews for changes, but
> > at any rate I don't think we should go backward here.)
> 
> This is basically a question of social contracts and tooling. It can
> IMHO certainly be done.
> 
> But isn't this discussion on details moot until we clear out the
> fundamentals such as the legal risk/cost analysis of dropping the NEW
> queue in its current form i. e., the topic for this thread?
> 
> And not least, some input from the ftp-masters team -- this discussion
> is about a huge change in a process they currently manage.

I am a member of the FTP Team and have been participating, at least a bit, in 
this thread.  I am not, however, speaking for the team.

In response to pings on #debian-ftp that a package in New just for a soname 
bump was blocking a transition, I took a look at it.  As is our practice, I 
did review the status of the copyright and licensing documentation in the 
package's debian/copyright.

It's pretty clear that even with going to New, the maintainer didn't bother to 
check at all.  I did a simple grep:

grep -ir copyright * > ../copyright_list

pared the results down to just the copyright claims that are not correctly 
reflected in debian/copyright and it was 806 lines long and there were multiple 
undocumented licenses (I didn't count them).

Maybe I'm just frustrated with that experience right now, but I have zero 
sense that there's any real interest in improving the quality of the archive 
in this regard from people not on the FTP Team.  If people think reviews by 
the broader community can replace New, I would invite you to get started on 
the work and demonstrate that there is sufficient interest in doing the work.  
There are plenty of in-archive issues to be found and fixed.

I would certainly not support the notion that we have too few licensing 
documentation bugs in the archive and we can afford to dismantle the one 
process we have in place that actually makes a difference in this area.

Scott K




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

Re: Legal advice regarding the NEW queue

[Philip Hands]

John Goerzen  writes:

> On Tue, Feb 01 2022, Russ Allbery wrote:
>
>> I would hate to entirely lose the quality review that we get via NEW, but
>> I wonder if we could regain many those benefits by setting up some sort of
>> peer review system for new packages that is less formal and less
>> bottlenecked on a single team than the current NEW processing setup.
>
> This is a fantastic idea.
>
> In fact, it wouldn't have to bottleneck packages at all.  I mean, if a
> quality issue is found in NEW, wouldn't the same be an RC bug preventing
> a transition to testing?

Looking at https://ftp-master.debian.org/REJECT-FAQ.html it looks like
one could assemble many of these potential issues into a checklist that
ought to be easily within the abilities of any DD to apply.

If that assumption is true, we could require that one performs some
number of such reviews on packages already in NEW before gaining the
right to add another one of your own.

Of course, we'd need some way of allocating packages to reviewers, and
some way for reviewers to submit their reviews, which would need
writing, but once that was done this should ensure that the effort
required to do initial checks on packages was spread out more, enabling
team members to concentrate on the more skilled bits of the process.

It might also act as a recruiting ground for people to get more heavily
involved in the FTP team.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Alec Leamas]

Dear list,

On 02/02/2022 18:46, Michael Stone wrote:

On Wed, Feb 02, 2022 at 10:16:36PM +0500, Andrey Rahmatullin wrote:

On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote:

On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote:
> Doesn't that, then, lead to the suggestion that any package entering
> unstable without having undergone NEW review (which, in the revised
> model, might be every new package) should automatically have a bug 
filed
> against it requesting suitable review, and that bug should be 
treated as

> a blocker for entering testing?

Not really, since anyone in the world could close said bug (including 
the

uploader).

This applies to any RC bug.


Yes, but in this case it means that we wouldn't have that minimal 
standard of at least one person other than the uploader having ever 
reviewed the package--which I think is a fairly low bar that we should 
meet. (It would be even better if we could add reviews for changes, but 
at any rate I don't think we should go backward here.)



This is basically a question of social contracts and tooling. It can 
IMHO certainly be done.


But isn't this discussion on details moot until we clear out the 
fundamentals such as the legal risk/cost analysis of dropping the NEW 
queue in its current form i. e., the topic for this thread?


And not least, some input from the ftp-masters team -- this discussion 
is about a huge change in a process they currently manage.


Cheers,

--alec

Re: Legal advice regarding the NEW queue

[Michael Stone]

On Wed, Feb 02, 2022 at 10:16:36PM +0500, Andrey Rahmatullin wrote:

On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote:

On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote:
> Doesn't that, then, lead to the suggestion that any package entering
> unstable without having undergone NEW review (which, in the revised
> model, might be every new package) should automatically have a bug filed
> against it requesting suitable review, and that bug should be treated as
> a blocker for entering testing?

Not really, since anyone in the world could close said bug (including the
uploader).

This applies to any RC bug.


Yes, but in this case it means that we wouldn't have that minimal 
standard of at least one person other than the uploader having ever 
reviewed the package--which I think is a fairly low bar that we should 
meet. (It would be even better if we could add reviews for changes, but 
at any rate I don't think we should go backward here.)

Re: Legal advice regarding the NEW queue

[Andrey Rahmatullin]

On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote:
> On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote:
> > Doesn't that, then, lead to the suggestion that any package entering
> > unstable without having undergone NEW review (which, in the revised
> > model, might be every new package) should automatically have a bug filed
> > against it requesting suitable review, and that bug should be treated as
> > a blocker for entering testing?
> 
> Not really, since anyone in the world could close said bug (including the
> uploader).
This applies to any RC bug.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Michael Stone]

On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote:

Doesn't that, then, lead to the suggestion that any package entering
unstable without having undergone NEW review (which, in the revised
model, might be every new package) should automatically have a bug filed
against it requesting suitable review, and that bug should be treated as
a blocker for entering testing?


Not really, since anyone in the world could close said bug (including 
the uploader).

Re: Legal advice regarding the NEW queue

[Andrey Rahmatullin]

On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote:
> >>> I would hate to entirely lose the quality review that we get via
> >>> NEW, but I wonder if we could regain many those benefits by
> >>> setting up some sort of peer review system for new packages that
> >>> is less formal and less bottlenecked on a single team than the
> >>> current NEW processing setup.
> >> 
> >> This is a fantastic idea.
> >> 
> >> In fact, it wouldn't have to bottleneck packages at all.  I mean,
> >> if a quality issue is found in NEW, wouldn't the same be an RC bug
> >> preventing a transition to testing?
> > 
> > I'm not sure "nobody ever looked at this" is a suitable criteria for
> > inclusion in a stable release. We sort of have that problem now in
> > crusty corners of the archive if someone uploads a bad change, but at
> > least there's been one review at some point in the package's
> > lifetime.
> 
> Doesn't that, then, lead to the suggestion that any package entering
> unstable without having undergone NEW review (which, in the revised
> model, might be every new package) should automatically have a bug filed
> against it requesting suitable review, and that bug should be treated as
> a blocker for entering testing?
> 
> That wouldn't help the "someone uploads a bad change" problem for
> already-accepted packages, but it would seem to avoid the "nobody ever
> looked at this" situation.
> 
> It would also increase the number of automatically-filed bugs by quite a
> lot, I suspect, which would itself be some degree of downside...
This will also decrease the number of new packages in testing, which can
be considered an upside too...


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[The Wanderer]

On 2022-02-02 at 11:21, Michael Stone wrote:

> On Wed, Feb 02, 2022 at 09:39:02AM -0600, John Goerzen wrote:
> 
>> On Tue, Feb 01 2022, Russ Allbery wrote:
>> 
>>> I would hate to entirely lose the quality review that we get via
>>> NEW, but I wonder if we could regain many those benefits by
>>> setting up some sort of peer review system for new packages that
>>> is less formal and less bottlenecked on a single team than the
>>> current NEW processing setup.
>> 
>> This is a fantastic idea.
>> 
>> In fact, it wouldn't have to bottleneck packages at all.  I mean,
>> if a quality issue is found in NEW, wouldn't the same be an RC bug
>> preventing a transition to testing?
> 
> I'm not sure "nobody ever looked at this" is a suitable criteria for
> inclusion in a stable release. We sort of have that problem now in
> crusty corners of the archive if someone uploads a bad change, but at
> least there's been one review at some point in the package's
> lifetime.

Doesn't that, then, lead to the suggestion that any package entering
unstable without having undergone NEW review (which, in the revised
model, might be every new package) should automatically have a bug filed
against it requesting suitable review, and that bug should be treated as
a blocker for entering testing?

That wouldn't help the "someone uploads a bad change" problem for
already-accepted packages, but it would seem to avoid the "nobody ever
looked at this" situation.

It would also increase the number of automatically-filed bugs by quite a
lot, I suspect, which would itself be some degree of downside...

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Legal advice regarding the NEW queue

[Michael Stone]

On Wed, Feb 02, 2022 at 09:39:02AM -0600, John Goerzen wrote:


On Tue, Feb 01 2022, Russ Allbery wrote:


I would hate to entirely lose the quality review that we get via NEW, but
I wonder if we could regain many those benefits by setting up some sort of
peer review system for new packages that is less formal and less
bottlenecked on a single team than the current NEW processing setup.


This is a fantastic idea.

In fact, it wouldn't have to bottleneck packages at all.  I mean, if a
quality issue is found in NEW, wouldn't the same be an RC bug preventing
a transition to testing?


I'm not sure "nobody ever looked at this" is a suitable criteria for 
inclusion in a stable release. We sort of have that problem now in 
crusty corners of the archive if someone uploads a bad change, but at 
least there's been one review at some point in the package's lifetime.

Re: Legal advice regarding the NEW queue

[John Goerzen]

On Tue, Feb 01 2022, Russ Allbery wrote:

> I would hate to entirely lose the quality review that we get via NEW, but
> I wonder if we could regain many those benefits by setting up some sort of
> peer review system for new packages that is less formal and less
> bottlenecked on a single team than the current NEW processing setup.

This is a fantastic idea.

In fact, it wouldn't have to bottleneck packages at all.  I mean, if a
quality issue is found in NEW, wouldn't the same be an RC bug preventing
a transition to testing?

- John

Re: Legal advice regarding the NEW queue

[M. Zhou]

On Wed, 2022-02-02 at 13:44 +0100, Andreas Tille wrote:
> Hi Wookey,
> 
> Am Tue, Feb 01, 2022 at 02:07:21PM + schrieb Wookey:
> > Has anyone on the actual FTP team responded to this thread yet?
> > (sorry, I can't remember who that is currently)
> > 
> > Either on Andreas's original simple question: 'Do we still _have_
> > to keep the binary-NEW thing?'
> > Or this more complex question: Is NEW really giving us a pain:risk
> > ratio that is appropriate?
> > 
> > Andreas tried hard to get someone to just stick to the first matter
> > and answer that. I don't recall seeing an answer from FTP-master
> > yet?
> 
> Me neither.  In my eyes its a problem that it is hard to comminicate
> with ftpmaster team.  I tried on IRC as well but I prefer mailing
> list
> since this is recorded online.
> 

Without answer from FTP team, it's hard to reach anywhere constructive
with respect to this problem. They have the most accurate understanding
on what part needs to be improved or revised.

Of course I can propose ideas based on my shallow experience and
speculation, but ideas in this thread will largely going to sink
unless there is any effective way to make real progress on it.

Re: Legal advice regarding the NEW queue

[Andreas Tille]

Hi Wookey,

Am Tue, Feb 01, 2022 at 02:07:21PM + schrieb Wookey:
> Has anyone on the actual FTP team responded to this thread yet? (sorry, I 
> can't remember who that is currently)
> 
> Either on Andreas's original simple question: 'Do we still _have_ to keep the 
> binary-NEW thing?'
> Or this more complex question: Is NEW really giving us a pain:risk ratio that 
> is appropriate?
> 
> Andreas tried hard to get someone to just stick to the first matter
> and answer that. I don't recall seeing an answer from FTP-master yet?

Me neither.  In my eyes its a problem that it is hard to comminicate
with ftpmaster team.  I tried on IRC as well but I prefer mailing list
since this is recorded online.

Thank you for this question

Andreas.

-- 
http://fam-tille.de

Re: Legal advice regarding the NEW queue

[Russ Allbery]

Scott Kitterman  writes:
> On Tuesday, February 1, 2022 12:18:07 PM EST Russ Allbery wrote:
>> Wookey  writes:

>>> For what it is worth I concur with everything that Russ has written,
>>> and would like to have us look at this again (and that's honestly not
>>> particularly because I currenly have the honour of the 6th-oldest
>>> package in NEW (8 months) :-) In general I have found NEW valuable as
>>> FTP-masters sometimes spot things that I missed, but the delay, and
>>> perhaps worse, the highly uncertain length of the delay (anything from
>>> a day to a year), is a significant cost and drag, and it seems
>>> increasingly anachronistic as the rest of the software ecosystem seems
>>> to accelerate around us (not entirely a good thing, of course). Who
>>> needs quality when you can have updates, eh?

>> I would hate to entirely lose the quality review that we get via NEW,
>> but I wonder if we could regain many those benefits by setting up some
>> sort of peer review system for new packages that is less formal and
>> less bottlenecked on a single team than the current NEW processing
>> setup.

> It's my impression that review of copyright and license considerations
> when not going through New is not a priority for most.  I doubt making
> New go away will make it more so.

To be clear, that's not the part I was intending to reference.  I think we
spend too much time reviewing copyright and license considerations for the
amount of benefit we get from it and would rather we rely more heavily on
automated tools and upstream's assertions, and otherwise be more reactive
and less proactive about issues that aren't fundamental to whether
something is free software.  (This is one of the reasons why I'm
interested in REUSE.  I would love for us to be able to leverage the work
that some upstreams have already done and trust it unless we know it's
wrong.)

I was thinking about all the other things that NEW catches, where people
have accidentally made more foundational mistakes in constructing a
package.  That comes up a lot in these discussions and I do think there's
merit in NEW as another pair of eyes on each new package.  That's the part
that I think would be interesting to try to find a way to preserve if
possible.

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

Re: Legal advice regarding the NEW queue

[Scott Kitterman]

On Tuesday, February 1, 2022 12:18:07 PM EST Russ Allbery wrote:
> Wookey  writes:
> > For what it is worth I concur with everything that Russ has written, and
> > would like to have us look at this again (and that's honestly not
> > particularly because I currenly have the honour of the 6th-oldest
> > package in NEW (8 months) :-) In general I have found NEW valuable as
> > FTP-masters sometimes spot things that I missed, but the delay, and
> > perhaps worse, the highly uncertain length of the delay (anything from a
> > day to a year), is a significant cost and drag, and it seems
> > increasingly anachronistic as the rest of the software ecosystem seems
> > to accelerate around us (not entirely a good thing, of course). Who
> > needs quality when you can have updates, eh?
> 
> I would hate to entirely lose the quality review that we get via NEW, but
> I wonder if we could regain many those benefits by setting up some sort of
> peer review system for new packages that is less formal and less
> bottlenecked on a single team than the current NEW processing setup.

It's my impression that review of copyright and license considerations when 
not going through New is not a priority for most.  I doubt making New go away 
will make it more so.

This doesn't need a change in policy for New to start work on.  If we're going 
to go in this direction, I think such a mechanism would need to be established 
and demonstrated to be effective.  No reason this can't be done with existing 
packages to establish the concept.

Scott K

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

Re: Legal advice regarding the NEW queue

[Russ Allbery]

Andrey Rahmatullin  writes:
> On Tue, Feb 01, 2022 at 09:18:07AM -0800, Russ Allbery wrote:

>> I would hate to entirely lose the quality review that we get via NEW,
>> but I wonder if we could regain many those benefits by setting up some
>> sort of peer review system for new packages that is less formal and
>> less bottlenecked on a single team than the current NEW processing
>> setup.

> What do you think, would it be more or less staffed than the current RFS
> review process?

Good point, it probably would be about the same.  The fundamental problem
we have is that we don't have enough packaging resources to keep up with
demand.  My intuition is that the resources we do have could be allocated
with more impact than the comprehensive copyright NEW review (honestly,
I'd rather rely on tools like licensecheck as much as possible and live
with occasional bugs, since I'm not convinced the bugs are serious enough
to warrant special attention above and beyond any other bug), but it's
true that this won't change the basic resource constraint, just move
around what we spend resources on.

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

Re: Legal advice regarding the NEW queue

[Andrey Rahmatullin]

On Tue, Feb 01, 2022 at 09:18:07AM -0800, Russ Allbery wrote:
> I would hate to entirely lose the quality review that we get via NEW, but
> I wonder if we could regain many those benefits by setting up some sort of
> peer review system for new packages that is less formal and less
> bottlenecked on a single team than the current NEW processing setup.
What do you think, would it be more or less staffed than the current RFS
review process?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Russ Allbery]

Wookey  writes:

> For what it is worth I concur with everything that Russ has written, and
> would like to have us look at this again (and that's honestly not
> particularly because I currenly have the honour of the 6th-oldest
> package in NEW (8 months) :-) In general I have found NEW valuable as
> FTP-masters sometimes spot things that I missed, but the delay, and
> perhaps worse, the highly uncertain length of the delay (anything from a
> day to a year), is a significant cost and drag, and it seems
> increasingly anachronistic as the rest of the software ecosystem seems
> to accelerate around us (not entirely a good thing, of course). Who
> needs quality when you can have updates, eh?

I would hate to entirely lose the quality review that we get via NEW, but
I wonder if we could regain many those benefits by setting up some sort of
peer review system for new packages that is less formal and less
bottlenecked on a single team than the current NEW processing setup.

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

Re: Legal advice regarding the NEW queue

[Wookey]

On 2022-02-01 07:56 -0500, Paul R. Tagliamonte wrote:
>I seemed to remember we retain actual outside council last i knew. Is that
>still the case?
>This request ought to come from the ftp team if we do do this, fwiw

Has anyone on the actual FTP team responded to this thread yet? (sorry, I can't 
remember who that is currently)

Either on Andreas's original simple question: 'Do we still _have_ to keep the 
binary-NEW thing?'
Or this more complex question: Is NEW really giving us a pain:risk ratio that 
is appropriate?

Andreas tried hard to get someone to just stick to the first matter
and answer that. I don't recall seeing an answer from FTP-master yet?

For what it is worth I concur with everything that Russ has written,
and would like to have us look at this again (and that's honestly not
particularly because I currenly have the honour of the 6th-oldest
package in NEW (8 months) :-) In general I have found NEW valuable as
FTP-masters sometimes spot things that I missed, but the delay, and
perhaps worse, the highly uncertain length of the delay (anything from
a day to a year), is a significant cost and drag, and it seems
increasingly anachronistic as the rest of the software ecosystem seems
to accelerate around us (not entirely a good thing, of course). Who
needs quality when you can have updates, eh?

The combination of binary uploads for NEW and source-only uploads for
the archive proper also seems a tad clunky.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Legal advice regarding the NEW queue

[Paul R. Tagliamonte]

I seemed to remember we retain actual outside council last i knew. Is that
still the case?

This request ought to come from the ftp team if we do do this, fwiw

Paul


On Tue, Feb 1, 2022, 4:12 AM Stephan Lachnit 
wrote:

> On Mon, Jan 31, 2022 at 10:47 AM Jonathan Carter  wrote:
> >
> > As for getting legal advice, we do have an existing contract with Aaron
> > K. Williamson of Williamson Legal, PLLC (https://www.akwlc.com/). His
> > specialty is Open Source softwware, technology, licensing and contracts,
> > so he would be a good person to ask specific questions about this, and
> > since we have an existing contract with him, it's really easy to set up
> > a video call / email thread with him if anyone wants to get some advice
> > from him. So if anyone has some time / energy to put together some
> > concrete questions / examples (and ideally also recruit one or more
> > people from FTP team to be involved), then I'd be happy to do the
> > introductions and set that up.
>
> Thanks for this information, Jonathan.
>
> I would volunteer for gathering and formulating questions and asking
> them to Aaron Williamson.
>
> I suggest the best would be to start with an IRC or video call session
> for everyone interested to formulate a "call for questions to ask",
> looking through the questions and formulating a document we can send
> to Aaron Williamson. Then we can discuss the question in a video call,
> and again formulate a document with the answers from Aaron Williamson.
> The next step would then probably be a GR.
>
> However I am currently in my exam phase until February 14th, but after
> this I have quite a lot of time.
>
> Regards,
> Stephan
>
>

Legal advice regarding the NEW queue

[Stephan Lachnit]

On Mon, Jan 31, 2022 at 10:47 AM Jonathan Carter  wrote:
>
> As for getting legal advice, we do have an existing contract with Aaron
> K. Williamson of Williamson Legal, PLLC (https://www.akwlc.com/). His
> specialty is Open Source softwware, technology, licensing and contracts,
> so he would be a good person to ask specific questions about this, and
> since we have an existing contract with him, it's really easy to set up
> a video call / email thread with him if anyone wants to get some advice
> from him. So if anyone has some time / energy to put together some
> concrete questions / examples (and ideally also recruit one or more
> people from FTP team to be involved), then I'd be happy to do the
> introductions and set that up.

Thanks for this information, Jonathan.

I would volunteer for gathering and formulating questions and asking
them to Aaron Williamson.

I suggest the best would be to start with an IRC or video call session
for everyone interested to formulate a "call for questions to ask",
looking through the questions and formulating a document we can send
to Aaron Williamson. Then we can discuss the question in a video call,
and again formulate a document with the answers from Aaron Williamson.
The next step would then probably be a GR.

However I am currently in my exam phase until February 14th, but after
this I have quite a lot of time.

Regards,
Stephan