On Wed, Apr 04, 2018 at 12:00:29PM -0700, Sean Whitton wrote:
> Hello Adrian,
> Thank you for your continued effort to get this bug resolved.
> On Sat, Mar 10 2018, Adrian Bunk wrote:
> >> Please expand on why you think this is the way we have to proceed.
> >
> > you skipped the part of my email with the explanation:
> >
> >   with such a piecemeal approach
> >   we risk fragmentation based on debhelper compat level used, with every
> >   new compat level installing different files in different locations.
> This is not inevitable.  What I am envisaging is:
> - we hash out our preferred solution either in this bug or in the
>   debhelper bug, with the debhelper maintainer having the final say on
>   what gets implemented
> - debhelper implements all of that solution at exactly one compat level
> - the archive starts to use that compat level
> - Policy is updated.

This ensures that policy will always be horribly outdated.

> 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?

> Our delegation gives the Policy Editors editorial authority over the
> contents of the Policy Manual, but by means of the Policy Changes
> Process we delegate that authority back to the body of DDs.
> That means that changes have to establish consensus.  How do we
> establish consensus on an issue like this, just by talking about it
> where everyone has a view?  That's extremely hard.  There's no way to
> bring the discussion to a close, and so the bug is still open after 10
> years.

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.

> What we can do in this case is shortcircuit that process of establishing
> consensus by means of debhelper.  The debhelper maintainer has authority
> over what debhelper will implement.  So he implements something.  If
> it's basically a sensible convention, almost everyone will start using
> it, even if it is not their number one choice of solution.  But then we
> have enough of a consensus, so it's no longer problematic to change

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

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:

I begin to wonder whether I should take this personally.

> Sean Whitton



       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply via email to