Bug#741573: Two menu systems
Steve Langasek <vorlon@debian.org> writes:
> - What *I* want is for the TC to take a principled stand on the point that
> the policy manual exists to describe distribution-wide integration
> policies, instead of taking a "there's more than one way to do it" easy
> way out.
This is what I'd prefer too. I guess I'm so used to losing on this point
in a Policy context for various reasons, some quite difficult to solve
(such as the continued existence of both shlibs and symbols), that I give
up on it easily. But I do think Debian's most common failure mode is
that, when asked to choose between A and B, we deploy A, B, C, and Z.
It's a failure mode that's also a strength, of course, since it makes us
flexible. But I watch debian-mentors closely, and I have to say that
we're setting our bar of entry extremely high, and in ways that I'm not
sure are really that helpful. It would be one thing if the bar was mostly
around very high-quality core packaging, but a lot of reviews mention all
sorts of things that Lintian complains about (menu integration, doc-base
integration, man pages, language extensions on scripts, arch-independent
files in /usr/share, missing upstream NEWS files, missing upstream signing
keys, etc.) that are what I would call "advanced quality of
implementation" issues, and that I'm not sure we want to make quite as
visible as they currently are.
Don't get me wrong: I care about a lot of those things too, and over time
I try to implement All The Things in my packages. But I also really
*enjoy* that sort of exacting attention to detail, and while that's a nice
quality for us to encourage, it's not clear to me that we want to make
that the bar to entry. And that's how it's being perceived right now.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: