On Wed, Apr 04 2018, Adrian Bunk wrote:

> This ensures that policy will always be horribly outdated.

Policy is meant to lag behind practice.  One of the reasons for this is
that it ensures that no-one feels they have to update Policy before

The extent to which it lags is a function of how many people are willing
to produce patches to the text of Policy (if you look at our bug lists,
this is the main area in which we are lacking manpower).

>> This is the standard way to make changes to Policy. The alternative is
>> releases of Policy rendering many packages buggy, and that is undesirable.
> A new debhelper compat level making packages buggy according to policy
> is what is desirable?

Yes.  It's okay for packages to break Policy that is thought to be
outdated, when the break that they introduce is an attempt to move
forward.  It's not okay for Policy to change first, except in those
exceptional cases where the only way to make sense of the change is to
change Policy first.

> Let me repeat what I already wrote earlier in this bug:
> IMHO the way forward is to find a consensus text for a policy change,
> Cc debian-devel on the proposal, and if no objections are raised release
> a new policy with these changes.

I would like to suggest that you do exactly that, but insert the
debhelper change before your final step of releasing Policy.

> The Policy Editors are a delegation, and the debhelper maintainer is
> just a random person who happens to maintain this specific package.

I don't see how that's relevant.

> Precedent is also that the Policy Editors do use their powers to
> push through even a change that makes thousands of packages buggy
> after an objection has been raised:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844431#334

Thank you for bringing up that example.

We would not have made that change had, say, less than 70% of the
archive already been reproducible.  Right now, without an implementation
in debhelper, this change would be making far, far more of the archive
buggy, and it would stay buggy for longer.

Further, we do not have a consensus on this bug in the way that we did
in the case of reproducible builds.

> I begin to wonder whether I should take this personally.

You absolutely should not.  As I said, I'm grateful for your interest in
working on this.  Moreover, I want to see this bug closed as much as you

Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply via email to