Re: what is policy about?

[Sam Hartman <hartmans@debian.org>]

>>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:

    Anthony> On Tue, Aug 26, 2003 at 02:02:44PM -0400, Sam Hartman
    Anthony> wrote:
    >> I'd see it as a problem if there were some best practice in
    >> policy that was implemented by a good fraction of the packages
    >> but the release team were not willing to accept that practice
    >> as a release requirement.


    Anthony> Release requirements are the
    Anthony> _bare minimum_ requirements that package must
    Anthony> satisfy. The simplest counter-example is
    Anthony> documentation. It's certainly best practice to write good
    Anthony> user documentation for all our programs and
    Anthony> packages. While we mightn't be there yet, I'd certainly
    Anthony> hope that one day more than just "a good fraction" of
    Anthony> packages have good documentation. But nevertheless, I
    Anthony> expect we'll still be willing to accept new, undocumented
    Anthony> or poorly-documented packages in Debian when they have
    Anthony> useful new features that aren't otherwise available.


You are of course correct.  I think the problem is in the specific
phrasing of my statement rather than in the general sense of the
statement.  I would see it as a problem if the release community were
not responsive to the policy community.

In other words it seems fine if as in cases like documentation people
acknowledge that a particular goal will never be a release
requirement.  It also seems reasonable if the release team is not yet
willing to add some requirement because doing so would break too much,
would delay the release, or would be hard to test.  But there are
other reasons for differences between best practice and release
requirements that I would find problematic.  For example if the
release team did not add some requirement because they didn't believe
it was a best practice, I would find that problematic.

Basically I'm happy if things work together; I don't want a split of
policy to turn into two competing visions of Debian.  I especially am
uncomfortable with two competing visions of Debian when one of the
visions is controlled by a roughly consensus-based process, but that
one that matters is controlled by a small cabal.

In practice I don't think there is much to worry about.  You've always
been willing to listen to other points of view.  I'm also going to be
really surprised if you suddenly stop participating in the
best-practices discussions.

--Sam