Re: Bits from the DPL (April 2019)

[Russ Allbery]

Sean Whitton  writes:

> ISTM that dh is a special case because it basically tries to implement
> as much of Policy as is automatable, either in its own code, or by
> calling other tools in the right way.

> In particular, even if dh were used by every package, we would not want
> to replace all the parts of Policy it implements with "use dh".  That's
> because maintainers still need to understand all the rationale for the
> things dh does, and also because they need to get things right when they
> write their own override_ targets, bypassing bits of dh's logic.

Yes, I definitely agree with this.  I think this is one of those cases
where we need to continue to dig into exactly what is being done under the
scenes, because almost everything in the dh sequences have to be
overridden in at least one package somewhere, or at least further
modified, and Policy has to provide the context and understanding required
to make those modifications.

I would say this is akin to shlibs and symbols files.  You *mostly* just
need to create a configuration file and then run dpkg-gensymbols,
generally via dh_makeshlibs, but Policy does need to provide some of the
details of what's going on under the hood here both because it's required
to understand when to use some of the optional features of those
configuration files, and because sometimes dpkg-gensymbols needs to be
guided or overridden.

That said, just as a matter of style and usability, we should describe the
common case first and make it clear that one doesn't have to open up the
details unless something isn't working right.

> This is why it seems odd to me to have "You should use dh." in Policy,
> in a way that does not arise for the idea of Policy
> recommending/requiring other tools to implement its requirements.

> When I say "layering violation", I'm not trying to stand on principle in
> any sense.  Moving the interface boundary such as to have Policy
> recommend using dh_shlibdeps, say, is not odd in the way that the
> possibility of Policy recommending/requiring use of the whole dh
> sequencer is.

Yes, this objection makes a lot of sense to me.  I think I see why that
bothers you.

The path that, to me, navigates out of that difficulty is to focus on
Policy's role as an instruction manual.  Rather than thinking of Policy as
a comprehensive description of one layer of the packaging ecosystem, we
can instead switch (and it is a switch -- this isn't what we've done in
the past) to thinking of Policy as a technical instruction manual for
packagers.  And like a good instruction manual, it can document both the
common path for most people, and then have an "advanced usage" section
that digs into the details for special cases or difficult problems.

The larger problem here, and what I think is a bit of the elephant in the
room, is that doing all of that requires resources, specifically time and
energy to do all the necessary writing and editing.  Which we're
chronically short on.

-- 
Russ Allbery (r...@debian.org)   

Re: Bits from the DPL (April 2019)

[Sean Whitton]

Hello Russ, Sam, others,

On Mon 13 May 2019 at 03:24PM -07, Russ Allbery wrote:

> The mandate of Policy is to specify the rules that packagers need to
> follow (plus the rules they should follow even if they're not required to
> follow) to integrate a package properly into Debian.  In other words, its
> function in Debian is an instruction manual, not a technical
> specification.  The goal is to convey to packagers the information they
> need to know, the API that they need to follow, and the rules about
> software behavior that they need to convince the software they're
> packaging to conform to.

This is useful, thanks.  It is good to keep in mind that the Policy
Manual is a whole is just that, a manual, not a spec (even though some
subsections are, correctly, more spec-like than manual-like).

> I think it's important for Policy to be comprehensive and try to deal with
> the edge cases.  But if the answer for all packages is "run this command,"
> I think Policy should just say "run this command" and not get into the
> details of what that command does unless that's really something a
> packager needs to know to understand the behavior of their package.  (But
> if there is such a detailed specification, and I too would love for one to
> exist, Policy can certainly link to it.)

ISTM that dh is a special case because it basically tries to implement
as much of Policy as is automatable, either in its own code, or by
calling other tools in the right way.

In particular, even if dh were used by every package, we would not want
to replace all the parts of Policy it implements with "use dh".  That's
because maintainers still need to understand all the rationale for the
things dh does, and also because they need to get things right when they
write their own override_ targets, bypassing bits of dh's logic.

This is why it seems odd to me to have "You should use dh." in Policy,
in a way that does not arise for the idea of Policy
recommending/requiring other tools to implement its requirements.

When I say "layering violation", I'm not trying to stand on principle in
any sense.  Moving the interface boundary such as to have Policy
recommend using dh_shlibdeps, say, is not odd in the way that the
possibility of Policy recommending/requiring use of the whole dh
sequencer is.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bits from the DPL (April 2019)

[Russ Allbery]

Bill Allombert  writes:

> Note that policy does not actually require that dpkg is used. Instead it
> goes to great length to describe what is the interface to dpkg that
> packages must relie on. This makes sense since this allow dpkg to evolve
> without breaking package policy compliance.

Personally, I think this sort of thing is more of a bug than a feature
given the role that I believe Policy should serve in the project.

I would like there to be a detailed technical specification of the exact
contents of Debian packages and the exact mechanics of how they work.  I
*don't* think that Policy is that document, or should be.  One good place
for such a specification to live would be dpkg.  There are probably
others.

The mandate of Policy is to specify the rules that packagers need to
follow (plus the rules they should follow even if they're not required to
follow) to integrate a package properly into Debian.  In other words, its
function in Debian is an instruction manual, not a technical
specification.  The goal is to convey to packagers the information they
need to know, the API that they need to follow, and the rules about
software behavior that they need to convince the software they're
packaging to conform to.

Given that goal, one of the primary risks of Policy is that it's
overwhelming and impossible to navigate.  Fewer and more straightforward
rules leads to broader adoption and therefore better and more consistent
packages.  Adding a complete technical specification of the artifacts used
behind the scenes by Debian components, however worthy of a goal in its
own right, mostly makes life *harder* for the packager reading Debian
Policy if what they are actually supposed to *do* is "run this command as
part of your build."

I think it's important for Policy to be comprehensive and try to deal with
the edge cases.  But if the answer for all packages is "run this command,"
I think Policy should just say "run this command" and not get into the
details of what that command does unless that's really something a
packager needs to know to understand the behavior of their package.  (But
if there is such a detailed specification, and I too would love for one to
exist, Policy can certainly link to it.)

-- 
Russ Allbery (r...@debian.org)   

Re: Thinking about Delegating Decisions about Policy

[Ian Jackson]

Sam Hartman writes ("Thinking about Delegating Decisions about Policy"):
> Why the TC?
> A couple of reasons.

I'm going to go off on a rant about the TC now.  I've been told that
this mail sounds like sour grapes but I think it's important.

I think it would be a bad idea to use the TC to push forward technical
change.  I think the TC as an institution[1][2] lacks:

1. wide enough political legitimacy

2. enough sensitivity to the concerns of those other than
the maintainers or teams whose decisions are being impugned

3. even, sadly, enough of a grip on detailed technical matters

4. structured communication and decisionmaking processes, which would
IMO be needed to: systematically capture the facts, and the
implications of the options; help the "losers" feel heard, and
feel that the decision was properly made; deliver clear
conclusions, but compassionately.

I also think that the TC is far less conservative than it ought to be
and is much more willing to risk damaging (or is blind to the risk of
damaging) the project's social cohesion, in the name of what is called
technical progress but often seems to me to be a narrowing of the
project's focus.


Rather than see the TC's role enhanced, I would like to abolish it and
replace it with something completely different.

Right now it is almost useless as a tool to overturn bad decisions by
maintainers: the costs of invoking it are far too high.  This is
partly because it always implies a public flamewar[1] and partly
because the TC itself generally seems to strongly prioritise the
emotional comfort of maintainers, and the notion of "progress"; it
disregards the emotional comfort of people who want their existing
stuff to keep working, and the autonomy of a package's users.

As a tool to make project-wide decisions on the desirability of a
mandating certain kind of progress, it lacks legitimacy amongst
significant proportions of the community, because of the way it made
decisions in the past and also to an extent because of the content of
those decisions.


Ian.

[1] I should say that I think the individual members of TC are and
have been people of generally very high caliber.  IMO the failings are
emergent properties of the structure, context and framing.

[2] Much of this is, I think, ultimately my fault.  I invented this
setup.  All I can say is that I was young and naive.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Thinking about Delegating Decisions about Policy

[Ian Jackson]

tl;dr:

 IMO a better way is for the policy editors feel more empowered to
   - lead practice rather than follow it (e.g. to follow
   rough consensus on desirable changes to Debian, rather
   than only document what is already widespread)
   - make judgement calls
 This could be done by encouraging the policy editors to amend the
 policy process, and by giving them political cover as they change
 their practice.


Sam Hartman writes ("Thinking about Delegating Decisions about Policy"):
> I imagine it won't be uncommon to get to a point where the right next
> step is to develop technical or non-technical policy about something.
...
> So, if I want to delegate deciding on a policy, who should I send it to?

Do you mean you as the DPL or you as a maintainer of some program or
sub-policy or something ?

I think you mean as DPL.  As the DPL you do not have any power to set
policy so you cannot delegate that to anyone.  An attempt do so ([1]
for example) is beyond the powers of the DPL, and therefore void.
("ultra vires" as a laywer would say. [2])


> we delegated managing the process to the policy editors, but not the
> actual policy decisions.  They make consensus calls.  They use their
> judgment in a lot of ways.

That is a decision *of* the policy editors.  When the constitution was
first adopted, and for some time afterwards, the policy editors
themselves made judgement calls about merit, rather than simply trying
to assess consensus.

Note that debian-policy is only one of the packages containing
technical policies.  Many other packages have bits of policy in them.
It is only debian-policy whose maintainers have decided to adopt this
consensus scheme and to lag practice.

IMO the biggest problem is the principle that policy should always
follow practice rather than lead it - even if the project has rough
consensus about the direction.  I really don't think that is best.

There is a missed opportunity here.  The policy editors and the policy
list have a good reputation and a lot of legitimacy.  That comes from
their practice of caution, of consulting widely, and seeking rough
consensus.

I wouldn't want to change that dramatically but a small change from
the policy editors would go a long way.  For example, to be willing to
countenance making recommendations which have rough consensus, and
seem to the editors like a good way forward, but which are followed
only occasionally or patchily.

That would not involve goring anyone's ox, so it would not undermine
the policy team's political capital.  Obviously any change might be
opposed by someone but I doubt such a change in policy practice would
meet much opposition.


Additionally I think the formal proposer/seconder scheme can be
awkward.  Again I think the policy editors adopted it because they
didn't want to be in the line of fire when difficult decisions are
being made, and perhaps because they didn't want to try to become
experts in everything.  But it means that uncontroversial changes can
languish.


> But at least under the current process, the policy editors cannot  just
> use their personal judgment to decide what policy is absent a consensus.

The policy editors collectively could decide to change the process.
The process is a creation of the policy editors, not of the DPL nor of
the rest of the project.


Ian.

[1] https://lists.debian.org/debian-devel-announce/2017/06/msg5.html
[2] https://en.wikipedia.org/wiki/Ultra_vires

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Bits from the DPL (April 2019)

[Sam Hartman]

> "Bill" == Bill Allombert  writes:

Bill> For package where upstream do not use the autotools, using dh
Bill> can be quite inconvenient compared to plain debhelper.

Bill> Cheers, -- Bill. 

I've started the discussion on debian-devel about whether we want to
recommend/require dh.
I think your comment belongs in that discussion not on debian-policy.
Please consider contributing there.