Re: Do we want to Require or Recommend DH

[Mo Zhou <lumin@debian.org>]

Hi Ben,

On 2019-05-13 15:10, Ben Hutchings wrote:
> On Mon, 2019-05-13 at 06:08 -0700, Mo Zhou wrote:
> [...]
>> In brief:
>> * if maintained by person: no restriction, given that
>>   the maintainer is not MIA
>> * if team-maintained: recommend dh
> 
> I would suggest almost the opposite.  If a team is happy to use an
> unusual tool, that's OK because there is (usually) at least one team
> member available to work on the package.  But when there is a single
> maintainer, it is more likely that the maintainer will be absent at
> some time (even though they are not completely MIA), and NMUs will be
> required.  Then it's important that other random developers can do the
> NMU.

The argument is fair enough from a different view point from mine.
However:

Assume that we only target on "maximizing our chance to survive when
an unusual package goes wrong", then clearly enforcing debhelper
everywhere is the best choice. The probability that a random Debian
Developer could not fix the unusual thing is approximately 1.
For any maintenance work, whatever personally maintained or team
maintained, the best choice to maximize the probability that "another
random DD can help original maintainer fix some issue", is to enforce
what most people use. Further more, the probability that "there are
more than one people in a team that understands the same unusual
thing" is exponentially less than the probability that "only one
member understands it". This is the mathematical/statistical fact.

My view point doesn't start from the cruel fact, but the original
maintainer's will. Given that

* The original maintainer understands what maintaing package under
  personal name instead of a team means.
* The original maintainer understands what utilizing something
  unusual means to collaboration.
* The original maintainer is not MIA.

Then a personally maintained unusual package means that the
original maintainer had fun in his/her unusual choices, and
had a strong reason in doing something unusual.

My updated suggestions:

* if personally maintained:
      if MIA:
          One can overwrite the unusual stuff through ITS
      else:
          We respect the original maintainer's joyfulness.
          Everybody has (initiative or passive) off-line time.
          Short absence should not be the reason to override
          original maintainer's will.
* if team-maintained:
       We do things democratically. When there is no preference
       on unusual stuff among team members, we recommend/enforce
       debhelper generally, in order to maximize our chance to
       survive when something goes wrong.