On Friday, February 4, 2022 2:48:50 PM EST Russ Allbery wrote: > Scott Kitterman <debian@kitterman.com> 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 thing to have. There's an old joke about someone lighting watch fires at night to keep lions and tigers away from the town and someone points out it's not necessary because there's no lions or tigers in the area. Their response is "see, it works". I think we might be inside a variant of that joke. Unlike the joke, I'm not sure who's right. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.