Steve Langasek wrote:
> 1. get more eyeballs on the proposed change, to spot problems which the
> added pre-dep may cause
>
> 2. inform the wider Debian developer community about the change, so they
> can factor it into any plans they have for changing their *own* package
> relationships that might subsequently cause a problem for system
> upgrades.
>
> A discussion on debian-release partly satisfies the need for 1) and
> addresses 2) not at all.
Good point. In this example it sounds like a useful discussion to
have on debian-devel, anyway. Sorry for the overreaction.
As for policy §3.5 in general: I have a lingering fear about policy
drifting from reality (and our procedures becoming less obvious as a
result). How policy §3.5 works in practice also seems worrisome to me
(since pre-depends often are added without discussion on -devel), but
maybe that says more about debian-devel than about the policy.
Discussions on -devel are hard to wrap up nicely, probably because
people are afraid of spamming each other.
So, new proposal. Before adding new Pre-Depends,
A. there should be a discussion on debian-devel or debian-release,
to get eyeballs on the change and spot problems and easier
alternatives;
B. debian-devel or debian-devel-announce should be at least notified,
so other Debian developers can factor it into any plans they have
for changing their own package relationships.
In particular, this proposal would drop the requirement of consensus.
Package maintainers generally know what's best; if not, there are
other ways to deal with that (e.g., convincing them, or referring the
issue to the ctte if the maintainer is beyond convincing).
Thanks for some clarity.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
