Re: Too many Recommends (in particular on mail-transport-agent)
Jeremy Bicha writes ("Re: Too many Recommends (in particular on mail-transport-agent)"):
> I think you're looking at this from the opposite perspective that I
> am. If you intent to ask the TC to override a Debian maintainer, I
> think your arguments need to be much more detailed and documented on
> the bug why you believe it to be that critical of an issue.
Recommends bloat as a whole is a serious problem for the whole
project. This is true even though the problem caused by each
individual instance is small.
Our second-line institutional structures (after individual
maintainers) for dealing with _classes_ of problem are policy (which
is already very clear IMO on this, but is often not followed);
automation (lintian, buildds, rebuild tests, etc); and peer review
(d-devel); and ftpmaster review (not applicable to existing packages
and I don't think they focus on this).
Unfortunately Recommends abuse is too subjective to be readily
amenable to the latter. (Although perhaps a better information system
showing the causes of bloat might help.) Peer review seems often to
fail on this point; and that is because the way to approach the
abstract rules seems to be disputed.
That means we need to go to our third-line response. I think that's
the TC. Getting the TC to add its voice to the abstract imprecations
is not helpful. On the other hand I a good worked example or two
would help educate maintainers, and strengthen the power of peer
Ian Jackson <email@example.com> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.