[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What to do when DD considers policy to be optional? [kubernetes]


Quoting Russ Allbery (2020-03-25 03:25:49)
> Michael Lustfield <michael@lustfield.net> writes:
> > One last thing to consider... NEW reviews are already an intense process.
> > If this package hit NEW /and/ we allowed vendored libs, you could safely
> > expect me to never complete that particular review. I doubt I'm the only
> > one; that's essentially ~200 package reviews wrapped into 1.
> I'll repeat a point that I made earlier but put a bit of a sharper point on
> it: We should thoughtfully question whether the current approach to license
> review that we as a project ask ftpmasters to do is a correct investment of
> project resources.
> The current approach to NEW license review is not a law of nature.  It's a
> choice.  Other choices are possible, such as trusting license declarations
> by upstream and then handling upstream mistakes that are later discovered
> as RC bugs.  The project is much better at sharing the load of handling RC
> bugs than it is at sharing the load of NEW license reviews.

the sub-thread as started by this mail only explores the option of reducing how
thoroughly we have to document copyright of the source code we put into Debian.
I wanted to point out that the original problem that started this was the
burden this status-quo puts on the FTP masters and how long packages remain in
NEW due to the required review effort.

So while we are contemplating our choices I wanted to point out that reducing
the quality of d/copyright is not the only possible option to tackle these
issues. The following ideas are not new but I wanted to just list them because
this thread seems to suggest that reducing our d/copyright thoroughness was the
only option we have.

For example it is also our choice that only FTP master are allowed to do the
copyright review and that the uploaded source must not leave the machine it was
uploaded to (even though it probably also lives on salsa at the same time). The
review process could be spread across more people or it could be open to the
public or to DD eyes only.  Yes, this introduces risks but taking this risk is
again a choice that we can make. It could be such that it needs X DDs to agree
and then a package clears the NEW queue or automated scripts could do a
plausibility check upfront. Especially teams that already know how the typical
layout of their domain best could work together to allow quick introduction of
new packages without reducing their quality.

What I'm saying is, that "reduce how good our d/copyright files have to be" is
not the only way to reduce burden on FTP master or to reduce the amount of time
packages spend in NEW. I'm also all in for reducing both but I would dislike it
very much if the quality of d/changelog would suffer as a result.


cheers, josch

Attachment: signature.asc
Description: signature

Reply to: