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/>

Reply via email to