[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16



Hi. Almost two weeks ago [1] I  started a discussion on whether we
wanted to increase the strength of our recommendation of the dh
sequencer from debhelper.
This message is a consensus call summarizing my reading of the
discussion.

  [1]
  [🔎] tsla7fqjzyv.fsf@suchdamage.org">https://lists.debian.org/msgid-search/[🔎] tsla7fqjzyv.fsf@suchdamage.org

My approach for calling consensus is heavily influenced by RFC 7282 [2],
which talks about some approaches for evaluating rough consensus within
the IETF.  That document is not normative policy there and certainly has
no force here, but the authors have spent a lot of time thinking about
how to understand what an opinionated group of technologists mean when
writing to a mailing list.  In judging consensus, it's much more about
whether issues have been considered and whether the community believes
the issues have been adequately resolved than numbers of people on any
side of a given issue.

  [2] https://tools.ietf.org/html/rfc7282

Please send any comments by 2019-06-16.
Please distinguish cases where you believe I've misread the discussion
from new contributions intended to change the community's view.

At the core of this discussion are a number of key issues that were
reflected in comments throughout the discussion.

* People who make changes across the archive such as enabling hardening,
  cross-building, bootstrapping, etc benefit significantly from more
  uniformity in packaging practices.  The time they spend working on
  packages that use dh is significantly less.  That is, people working
  on making Debian more reproducible benefit from when we adopt more
  uniform practices.

* People who spend time fixing the archive, fixing RC bugs, etc don't
  like to see churn in areas that are already working.  If it's working
  well, don't break it.  Developers doing NMUs do not always perform
  adequate QA of their changes.

* Traditionally we've valued respecting the maintainer's preference
  above most other factors.  In the limit, short of orphaning packages
  or removing maintainers, we don't actually have tools to get
  maintainers to do things they don't want to.  Per our constitution no
  one in Debian is obligated to do anything besides not stand in the way
  of others.  And yet this discussion is about pushing things towards
  uniformity and in a small way away from maintainer preference.

Recommendation
==============

There are some exceptions where we think using dh is the wrong choice;
see below.  We have a strong consensus that other than in exceptional
circumstances, new packages should use dh.

There's a weaker consensus that existing packages should use dh, but
migrating working packages to use dh is often not the best use of our
resources and can be harmful when it introduces bugs.  A number of
people spoke against choosing dh for existing packages.  I looked at the
reasons expressed.  A number of these focused on concerns about
introducing bugs.  When I read through all the messages I think it was
fair to interpret a lot of these concerns as asking us to be careful
about how we spend our resources.  It is generally harmful to convert a
package to dh without adequate testing.  It often makes sense to spend
time on something other than converting working packages to dh unless
doing so fixes something else or makes something easier.

But if a maintainer asks if in an ideal world should their package use
dh, the rough consensus of this discussion is that other than
exceptional circumstances, "yes".

Exceptional Circumstances
=========================

This is not a complete list of reasons not to use dh.  That list will
likely evolve over time, but here are reasons identified in the
discussion.

* If you're actively working on something new, innovation is still
  something we care about.  We're not trying to close down development
  of the next great thing.

* Cdbs has a few features that dh doesn't have.  The Haskell tools in
  cdbs ar critical to our current Haskell infrastructure.  Cdbs flavors
  don't seem to have a dh analogue.  For examples compare
  https://salsa.debian.org/multimedia-team/snd/blob/master/debian/rules
  to
  https://salsa.debian.org/multimedia-team/soundscaperenderer/blob/master/debia
  n/rules .  If cdbs is doing something for you, then it probably makes
  sense to stay with it for now.  But it sounds like there's discussion
  of retiring cdbs longterm.  So if you're using cdbs for things dh is
  perfectly good at, the cdbs exception is much weaker and possibly may
  not apply.

* Consistency with teams.  If your team is using something else, then it
  might be worth having a discussion within the team about whether
  that's still the best choice, but consistency within teams is
  important.

* We need to go back and check if there are any bootstrapping concerns
  that should affect build system decisions for specific packages.

There was strong consensus that we should have a lintian tag that can be
overridden to indicate why a package is not using debhelper.

I think there is rough consensus (although rougher than some other
things) that individual maintainer preference is not in and of itself a
justification for not using dh.  That is, I think the people  arguing
for how using dh made their jobs either in making large changes to
Debian made a better case than those arguing for maintainer preference.
However Mo Zhou reminded us that we need to keep things fun.  If a
maintainer really wants to use something other than dh there's a good
chance that there is some underlying requirement dh is not meeting.  And
that probably is a legitimate exception.

we're not coming after people with pitchforks if they don't use dh.  It
might simply mean their packages have a bug.  It certainly doesn't mean
they are obligated to fix that bug, although best practice in our
community is to work with submitters of patches to review those patches.

Is Not Using DH a Bug?
======================

It's certainly not an RC bug.  There was some talk of it eventually
being an RC bug if a new package doesn't use DH (and doesn't fall under
an exception).  I don't think there's consensus for that today.

It's obviously not a bug if one of the exceptions applies, but once the
lintian tag exists, overriding that tag sounds to me like best practice
to document the exception.  (Presumably for things like Haskell we'd
want Lintian to be smart enough to figure that out on its own)

To some extent I'm extrapolating from implications of the rest of the
consensus call for the rest of this section.  There was some discussion
of whether not using dh should be a normal bug, but the comments about
that were inconsistent with the rest of the discussion.  But if the
consensus call above that existing packages (absent exceptional
circumstances) should use dh stands, that's approximately the definition
of a normal bug.  So my reading is that absent exceptional
circumstances, not using dh is a normal severity bug.

It doesn't mean you should file that bug and it doesn't mean that you
should go fix that bug.  We definitely didn't get the kind of support
we'd be needing for a mass bug filing or anything like that.  It
wouldn't serve a point.  This isn't atypical.  There are a lot of things
lintian flags that are technically bugs, but we wouldn't want to mass
file all lintian tags (even if we could filter out false positives) as
bugs.

This paragraph is very much my interpretation.  I'd personally say that
if you're going to file a bug that a particular package doesn't use dh,
have a good reason and document it in that bug.  Your reason might be "I
want to contribute; I'm willing to dedicate time and updating the
packaging would make it much more appealing to work on."  Often your
reason will be that there's some other problem, migrating to dh will fix
that problem, and between the time you're willing to spend and the time
you hope the maintainer will spend it's worth doing a good job of that
migration.

My interpretation of our standard practices is that maintainers have
wide discretion in which bugs they work on.  That said, if someone
submits a patch, it's good if you review it.  It's fine to ask them to
do the necessary testing work and it's fine to hold them to the same
high standards that you hold yourself to.  If they are less experienced
with the package it might make sense for them to do tests that make up
for that experience gap.  None of this  changes any of that or asks
maintainers to treat bugs about dh differently than other bugs.

Best Practices for Testing DH Conversions
=========================================

* Run a debdiff of the binaries to see what has changed

* Use diffoscope

* Run autopkgtests

* Test piuparts

Generally look at the packaging and explain any changes carefully.

So I should Go NMU the Archive to DH
====================================

ABSOLUTELY NOT!

We had a long discussion of NMUs and dh that was probably my fault and
unnecessary.

Through a round about set of messages we seemed to come to a consensus
that is roughly the same as our existing NMU policy.

I don't see a consensus to change how NMUs regarding dh are handled.

Generally doing an NMU to change packaging style is not a good idea.
There are cases where it might be appropriate.  Feel free to read the
longer discussion and to look at discussions of NMUs in Developer's
Reference.

Why are We Doing this
=====================

[🔎] 20190513173542.GA24063@espresso.pseudorandom.co.uk">https://lists.debian.org/msgid-search/[🔎] 20190513173542.GA24063@espresso.pseudorandom.co.uk

is fairly typical of this.  There was also some discussion in the
initial message.

Attachment: signature.asc
Description: PGP signature


Reply to: