On Wed, Aug 27, 2003 at 04:50:29PM -0400, Sam Hartman wrote:
> For example if the
> release team did not add some requirement because they didn't believe
> it was a best practice, I would find that problematic.
Let's rephrase that to be even simpler: if there was something in policy
that the release team didn't thing was best practice, that would be
problematic. That's true as long as the release team consists of people
who're fairly clueful about packaging, and applies to any other group
that's fairly clueful about packaging, too.
What I'm claiming is that having things that are considered best practice
be written down in multiple places is counterproductive and confusing; as
is mixing them up with things that aren't really about packaging at all.
> Basically I'm happy if things work together; I don't want a split of
> policy to turn into two competing visions of Debian. I especially am
> uncomfortable with two competing visions of Debian when one of the
> visions is controlled by a roughly consensus-based process, but that
> one that matters is controlled by a small cabal.
Uh, yeah, *that*'s constructive.
You do remember that we tried getting RC policy to be controlled by
-policy, and it didn't work, right? Too many things that shouldn't be RC
getting made RC, too many things getting made RC by accident or default,
too much effort required to convince people that their pet fancy shouldn't
be RC, and the RC policy not being up to date enough when it counts,
and all.
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:
pgpBeh2zQX67y.pgp
Description: PGP signature