Scott Kitterman <deb...@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. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
