Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16
On May 25, 2019 5:26:47 PM UTC, Sam Hartman <leader@debian.org> wrote:
>
>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.
...
>
>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.
>
>...
>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.
On what basis is it a bug of any kind?
A lintian check does not a buggy package make.
Assuming a package that is otherwise working correctly, you have a policy compliant, fully functional package. That seems to me like the very definition of not a bug.
If we want to make not using dh except in certain situations a bug, it seems like something for a policy should kind of item. We have an existing process for updating policy, so this should probably be kicked over there for further evaluation.
Scott K
Reply to: