[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Conflicts between developers and policy

Buddha Buck <bmbuck@acsu.buffalo.edu> wrote:
> Your objection is to the use of the admittedly subjective criteria
> "if they feel it is a technically superior approach." Would the
> (slightly) more objective criteria "if they feel that strict adherence
> to the policy would jeopardize system integrity or weaken package
> usability."?

This is better, but I feel as if it's still lacking something.

Remember that (a) we are preparing packages for a wide variety of
systems, (b) we've claimed that what we build now we'll support
upgrading from in the future, (c) we're also concerned with the matter
of boot strapping onto systems which previously didn't have debian (boot
disks, ...), (d) we're trying to provide some level of interoperability
with non-debian systems (that's why we talk about fhs), (e) we're at
least considering different kinds of installation mechanisms (among
other things, for the people who want to put together several hundred
copies of the same installation).  Plus we're talking about putting
together administrative tools, to make life simpler for the end
user who might be frustrated at the way one conceptual activity
requires studying some wide variety of package documentation (most
of which may be irrelevant to that user).

The point is: we've got a wide variety of goals; debian-policy is a
fleshed-out statement of those goals. What you're essentially saying is
that the expression of the goals must be pursued or debated, but even
though you're prescribing when and how the debate should occur I doubt
that a new maintainer is really going to comprehend what we mean by
"system integrity and package usability" unless it's fleshed out a bit.

If we're going to adopt this concept of "policy must be followed or
debated" I think we need a debian-meta-policy which documents for
newcomers what we think we're trying to do so that they can make
reasonable choices about which is appropriate, and when.

Raul, struggling to avoid long discussion of use-cases and failure modes

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: