[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Policy and procedures issue: init package hijacked via hostile NMU (declined by maintainers)

On Sat, 2018-12-22 at 21:03:18 +0100, Andreas Henriksson wrote:
> (Not sure debian-devel is the right place for this discussion, but
> oh well...)

Yeah, this should probably have been brought up on debian-project,
if at all…

> On Sat, Dec 22, 2018 at 08:32:07PM +0100, Guillem Jover wrote:
> > On Sat, 2018-12-22 at 10:11:53 -0800, Josh Triplett wrote:
> [...]
> > I think the summary mischaracterizes the situation a bit TBH.
> [...]
> > > - Dmitry refused to cancel the NMU, which then went into the archive.
> > 
> > Dimitry refused to cancel the NMU *himself*.
> [...]

> He also said the maintainers had to get the CTTE to overrule
> his decision if they did not want to accept his NMU..... 

Not quite. Here are the relevant quotes:

  [2018-11-28 18:48] Dmitry Bogatov <KAction@debian.org>
  > I am worried: freeze is coming, and nothing is happening. I am not going
  > to miss another release.

  Hereby I inform you, that I uploaded NMU into DELAYED/15. Feel free to
  cancel it, providing rationale why it is not "reasonable".

  Quoting from TC (#746715):

          [... ] That includes merging reasonable contributions, and not
          reverting existing support without a compelling reason. [...]

and later on:

  [2018-12-17 12:56] Michael Biebl <biebl@debian.org>
  > It's clear that you are unhappy with the situation, so am I.
  > Maybe we should involve the CTTE and have them work out and define the
  > criteria and interfaces an alternative /sbin/init needs to provide and
  > what behaviour can be expected or not (and have an automated test suite
  > which tests all this).

  Sure. I will write draft summary of disagreement in a week or so into
  this bug.

  But until and unless CTTE overrules my decision, `runit-init' will be
  installable without uninstalling essential packages, either as
  pre-dependency of bin:init or as package, that provides `init'.

So I clearly read there:

 1. The maintainers can cancel the NMU (as is their right really),
    and provide a rationale.
 2. If 1. happens (and I understand, unless a compelling reason is put
    forward), he is stating that unless overruled he'll go forward with
    the plan to add runit support even if that implies adding a
    «Provides: init» on one of the runit packages.

> (which apart from refusing to listen to very qualified developers with
> decades of experience also IMO suggests he has gotten the constitution
> completely backwards.)

So, I've stated earlier, I think the NMU was probably socially rude,
and something I'd not consider doing. Procedurally? I guess it was
OKish, but I guess that's a consequence we get when people involved
the ctte to muddle the social and procedural fabric of the project…

We are also talking about a change that affects only people who might
want to use runit as their init system. Compare that with, I don't
know, the merged-/usr deployment hack, which is the new irreversible
default, and which breaks stuff, and where people have been warning
about for a long time…

> I have only seen a limited amount of Dmitrys work, but my impression
> is that he's not someone who should be trusted with unrestricted
> uploading privileges. I think fast-tracking him through NM was
> a mistake and would suggest he should take the full tour.

Oh, wow…


Reply to: