On Wed, Mar 08, 2006 at 12:49:58AM +0000, Ian Jackson wrote:
> Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> > WHEREAS
> I'd like to expand somewhat on my `no' vote. Many of the questions
> here were addressed by my earlier messages and I will try to avoid
> repeating myself.
> > 5. The technical policy in this matter states that: (debian-policy
> > 3.6.2.2, section 2.2.1)
> As I have said before, this is not `technical policy'. I don't know
> where you get the phrase `technical policy' from. Even if the Policy
> Manual is largely technical, that doesn't mean that everything in it
> is technical.
6.1. Powers
The Technical Committee may:
1. Decide on any matter of technical policy.
This includes the contents of the technical policy manuals,
developers' reference materials, example packages and the behaviour of
non-experimental package building tools. (In each case the usual maintainer
of the relevant software or documentation makes decisions initially,
however; see 6.3(5).)
I accept that there may be things in the Debian policy manual (i.e., the
"technical policy manual") that you feel don't belong there. But if you
agree that the distinction between main and contrib belongs in Policy, then
I don't see how you can argue that it's at the same time non-technical; and
if it doesn't belong in Policy, then where does it belong?
> Whether a question is technical or political doesn't just depend on
> the outcome, and it doesn't depend at all on what you call the
> documents (if any) that form the basis for the decision. It depends
> on the _reasons_ which will govern the decision.
So by this reasoning, any decision in which one or more options are
eliminated from consideration due to the social contract is necessarily
political and therefore not technical? That doesn't sit right with me; as
long as we're not attempting to change political policies, I don't see any
reason it's out of scope for us to make technical decisions (or I guess you
would say, decisions about technicalities...) that are informed by the
established political policy.
> Can you explain to me why anyone might think that there was a
> _technical_ reason for ndiswrapper to be in either main or contrib ?
> That is, a reason to do with making the system function better, or be
> easier to install, or less buggy, or some such ? That's what a
> technical reason is, and if there were technical reasons in this
> question then it would be a technical decision (and we would be
> spending our effort establishing the facts, not chopping semantic
> logic). But there aren't.
Technical arguments why ndiswrapper should be in main:
- availability to users with the default sources.list
- availability from within the installer
- availability from the unmodified Debian CD images
Technical arguments why ndiswrapper should be in contrib: ?
So there certainly is a technical decision to be made; the major question is
whether the social contract *allows* us to make it. In this way, I think I
agree with you: I don't think it would be appropriate for us to overrule the
maintainer on the grounds that we think the social contract requires the
package to be in contrib, because it's not our place to interpret the social
contract. But that doesn't mean it's disallowed by the constitution: 6.1.4.
says that the committee may overrule a Developer to force a particular
technical course of action, and it does *not* say that the committee's
motives in doing so must be limited to purely technical considerations.
> One possible view of the situation is that policy states a political
> decision in terms of technical properties of programs, but it's quite
> clear that the part we're relying on trying to interpret is at least
> badly ambiguous or underspecified given that different people think
> that it `clearly' means quite different things !
> > 11. The committee endorses the existing policy on the suitability of packages
> > for the main and contrib components; and
> Surely the existing policy is vague and definitely needs to be
> clarified. Otherwise why are we having this conversation at all ?
> If the policy needs to be clarified, and it is within the committee's
> power to clarify it, then the committee should do so ! So, please
> suggest your proposed wording.
Well, I suspect that any wording we would suggest as a replacement would
have its own subtle ambiguities, so I'm not convinced the benefits outweigh
the costs of doing so. I'm interested to see what AJ thinks here, though,
as the drafter of the resolution that I agree with; perhaps he has some
ideas on improving this wording. More likely, IMHO, is that we'll be able
to get a majority to agree on where the ndiswrapper package should be, but
not on a particular policy wording that should replace the current one to
make this clearer. :/
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature