Hi. Last month[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 describing how I as the discussion
facilitator see the project consensus.
After the original discussion, I published the first version of this
consensus call on May 25. Comments were due by June 16.

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


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 unless there is some
reasonable reason to do something else, 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 unless there is an adequately justify reason to do something else, "yes".

After the initial consensus call, a few people raised additional
concerns about this recommendation. No new issues were raised; the
points raised during final comments had been adequately addressed during
the body of the discussion. The comments were not numerous enough to
make me think I had misjudged the community's values when considering
the various trade offs. In addition, there were also new comments in
support of more uniformity in packaging.

Reasons to Do Something Else
============================

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. See
my next steps at the end of this message.


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 reason not to use dh.

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.

Again there were some dissenting final comments, but my reading is the consensus stands.

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 there is a reasonable reason not to use dh,
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 adequate
justification) should use dh stands, that's approximately the definition
of a normal bug. So my reading is that absent adequate justification,
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.

Next step for this section is to have a policy discussion; see below.

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.

Next Steps
==========

I will go open a bug on debian-policy asking the policy editors to
document this consensus following their standard process as the
debian-policy lists sees best. Some early discussions with the policy
editors suggest they have ideas and are well up to the challenge of
proposing something for the community to consider.
Thanks Russ and Sean!

I'll see whether the Lintian maintainers need a bug filed and file one
if necessary.

I'll make sure that people involved in bootstrapping have an opportunity
to comment in the policy discussion if they have input.

A Closing Word from Our Sponsors
================================

Thanks everyone for helping out with a great discussion. I hope that we
can use this approach for exploring other issues and reach similarly
productive outcomes.

While I'm writing to -devel-announce, I could use your help with another matter. In preparation for a meeting with the Antiharassment team,
account managers, former DPL and myself, I am soliciting feedback on how
well the Antiharassment team is meeting the project's needs. I've
received very little feedback from people who have actually interacted
with our antiharassment team either as reporters or respondents. I
regret sticking something this ephemeral onto a long-lived message, but
I'd regret a second post to debian-devel-announce more. I could really
use your feedback; see https://lists.debian.org/msgid-search/tslmuivstkr.fsf@suchdamage.org for
my questions.

Thanks,

Sam Hartman
Debian Project Leader

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE9Li3nMNy++OFgPTCQe7SUh/WssoFAl0IIg0ACgkQQe7SUh/W sspjnQgAlqKPiay++CXRIG/OaxF9ZvuSaPli5Un763ngN2wrPzSoqQhIbWw2Tz2R fu7I1wkoc4WQ6To2ttqWA+R+owfBcrUZN2mGrun8pxoBUONrfgvW1TDlC/cIPuEs Flc6QYAi0DAOOg/fJvMSRu4EEqn5j6xwP6wn4jq/52OvUnO5vVZjpPpGgW6nuBbN Dph2fjohRwlNLvTvKy1jpK/BrUZ98x7x4YvzwgSfnpT5Q+Bd/tX8hWMEmiisfnCF SXI76MvdlMwCqPDvjw2tpW6twdPxyH92zi7etPAC8atBrDPAGYpZJqrUSr/lfEwa 0tngQ1ndAlej6vRM56yG7WGX1O6HKA==KUje
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)