Web lists-archives.com

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@xxxxxxxxxxxxxxxxxxxxxx>   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.