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

Re: Bug#207132: debian-policy is missing gcc transition plans



On Tue, Aug 26, 2003 at 12:50:53AM -0500, Manoj Srivastava wrote:
> 	In my view, policy is supposed to represent the minimum set of
>  rules that packages follow to allow the parts to dovetail together.

I don't think that makes sense -- getting packages to dovetail together
isn't something that can be achieved once and forever more; once we've got
libraries and file hierarchies making sense and fitting together, we're
not going to stop, we're going to start working on getting documentation
put together in more consistent fashions, or stop Gnome from spewing
assertions to xterms, or any number of other things.

But doing any of that requires a document that's willing to cover all
the things we're trying to achieve. Having many documents doesn't work,
because packagers coming to Debian need to be able to find *everything*
that affects them; having stuff undocumented doesn't work because
otherwise not only won't new people know it, but those of us who decided
what we'd do are liable to forget.

> 	The developers reference is the best repository of "best
>  practices" -- common techniques that over time have been discovered
>  to be desirable to adopt.

No, it's not. The developer's reference is about procedures; debian
policy is about packaging. And this is utterly appropriate; working
out what to do (packaging policy), and how to do (uploading policy) are
fundamentally different things. Procedures, like when to upload NMUs or
the use of DELAYED queues, change by dictate and mood; technical policy
whether you consider that "best practices" change only when new problems
are noticed, or when new procedures become possible.

Moving these things into other documents is a *mistake* -- it was a
mistake when we did it to the packaging manual, one which continues to
make policy confusing and difficult to follow, and it's a mistake to
extend chapter six of the developers reference.

>  [...] but by and
>  large, the goal is to pare it down to a ruleset _required_ for
>  packages to interact and integrate tightly together.

What, exactly, do you think this means?

It's not required in the sense that the package won't be
allowed in Debian, or in a Debian stable release; that's
http://people.debian.org/~ajt/sarge_rc_policy.txt.

It's not required in the sense that the packages won't work at all,
or even that it won't work for the majority of people; that would be
even shorter than the sarge_rc_policy.

> 	I, however, agree that policy is not a stick to beat
>  developers on the head with, which is another way of stating what you
>  said.

"The Axiom of Choice is obviously true; the Well Ordering Principle is
obviously false; and who can tell about Zorn's Lemma?"

(You did just disagree with me, then restate my comment and agree with it,
right?)

If you're not going to beat people on the head with policy, the only
merit it has *at all* is as a compendium of well thought out advice to
package maintainers about how to do their work. That is the *precise*
definition of "best practices" documents.

By contrast, sarge_rc_policy is a list of requirements, and is something
to beat people over the head with.

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.

       ``Is this some kind of psych test?
                      Am I getting paid for this?''

Attachment: pgpHEuKx8nY4G.pgp
Description: PGP signature


Reply to: