Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16
Firstly, I want to say that I think this is an awesome way to conduct
this discussion/decisionmaking/whatever. Thank you.
Sam Hartman writes ("Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16"):
> 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.
I would use the word "unusual" rather than the word "exceptional".
Legalistically they have nearly the same meaning, but they convey a
difference of emphasis: a difference in how strong a reason is good
enough for not using dh; or, in what proportion of exceptions we are
expecting.
I haven't systematically reread the thread as you have, but my
impression is that we have a "strong consensus" as you put it that dh
should be used unless there is "some reasonable reason" not to.
I don't think we have "strong consensus" that these exceptions are
going to be rare. "Exceptional" conveys both that there is some
reason, but also an expectation of rarity.
So I would write "Unusual Circumstances" etc.
> Exceptional Circumstances
> =========================
...
> 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.
Having said that, I agree with you here. We *do* have rough consensus
that pure maintainer preference is not a good 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.
I agree, but this will need some delicate handling.
> Is Not Using DH a 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.
My personal position is that I agree with your conclusions here.
I don't feel confident to say what the consensus was. I have often
experienced serious difficulty even communicating clearly with people
about these matters, let alone coming to agreement on practical steps
in edge cases.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These 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.
Reply to: