Hi, Quoting Russ Allbery (2020-03-25 03:25:49) > Michael Lustfield <mich...@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. Thanks! cheers, josch
signature.asc
Description: signature
