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 <[EMAIL PROTECTED]> <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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
