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

Re: Bug#139957: period at the end of short description?



On Sun, Mar 31, 2002 at 09:40:42AM -0600, Manoj Srivastava wrote:
> >>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
>  Anthony> No, policy does not become optional with a note in the
>  Anthony> README. Policy becomes optional only when what it suggests
>  Anthony> is technically wrong in the given situation. We're not here
>  Anthony> to codify random opinions, we're here to document ways of
>  Anthony> packaging that are technically _better_.
> 	Is there a difference? Who decides that the policy is wrong?

Who decides policy's wrong right now?

>  If I can unilaterally decide policy is technically wrong, and say so
>  in the README, and proceed to ignore policy, then policy is indeed
>  optional. 

Can you do this right now? What happens if you try?

> 	What are the checks and balances proposed? 

What checks and balances already exist?

You do realise that saying something in policy doesn't automatically
mean everyone understands it and gets it right, don't you? Take lmbench,
for example, which managed to get into main in spite of a maintainer
who should've noticed that its license wasn't free, and an ftpmaster who
should've done likewise. It got in anyway. Now a bug report's been filed
on it. If that doesn't get the appropriate resolution, we can educate
the appropriate people. If that doesn't work, we can forward it to the
mailing lists to get a second or third opinion. If that doesn't work,
the technical committee or ftpmaster can do something about it.

None of this changes.

> 	Well, I still see no reason here that contradicts the
>  statement that this makes policy optional, and largely irrelevant
>  when it comes to tough or controversial decisions, since no decision
>  is likely to convince everyone, and if people can just ignore policy
>  when they disagree with it, the cooperative infrastructure is
>  damaged. 

"Cooperative"? There seems to be very little "cooperation" to be damaged.

"Everyone must read policy and do what it says. If they disagree with
policy, rather than just doing the right thing, they must come to
the policy mailing list, convince everyone that they're right, make a
patch against policy that's not too specific nor too general and get
some seconds, then wait a couple of weeks for it to be approved, then
however much longer until a new release of policy comes out, then they
can go ahead and upload their package."

That sounds more like policy wonks dictating the law, and everyone
else obeying.

Having the policy group put in the effort to browse packages and look
for exceptions, and take responsibility for fixing mistakes in policy
themselves seems a lot more cooperative and in the spirit of things
to me. Expecting developers to participate in the policy formulation
process isn't particularly reasonable.

Policy doesn't gain it's authority because it's called "policy". It
doesn't gain its authority because it's backed by the moral righteousness
of the mighty Manoj. It doesn't even gain its authority because the DPL
or release manager says so. It's authoritative because it's full of good
solutions to packaging problems, and good advice on packaging issues.

If one of its solutions isn't right for a particular package, or some
of its advice isn't so good in some situation, that's a shame, but it's
not a bug in the package. And if you want to consider it a bug in policy
and go about fixing it, that's fine, but it's *your* job to go and do it,
not anyone else's.

Anyway. There's no chance I'm going to get through to you on this,
so I should stop wasting your time or mine.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

                        Vote [1] Bdale!


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



Reply to: