Policy and procedures issue: init package hijacked via hostile NMU (declined by maintainers)
[Please don't CC me on responses, and please follow up solely to -devel rather
than cross-posting.]
Please note in the following mail that I'm raising this *exclusively* as a
policy and procedures issue, *not* a technical issue. I would request that
people *please* focus on the policy and procedures issue, and keep any proposed
technical solutions to the specific problem at hand (or comments on init
systems) to another thread. There is already another thread on -devel regarding
technical approaches to handling init systems, and if people wish to help debug
issues a specific init system they should do so in an appropriate bug report.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838480 . Rough
summary of events:
- Dmitry Bogatov requested that the init metapackage depend on
runit-init (to enable runit as an alternative init system).
- After a few months of back and forth, runit was updated to include
appropriate scripts for compatibility with expected interfaces of
init.
- Dmitry popped up again after two years, in October, and then in
November said that he'd upload an NMU to DELAYED soon.
- Martin Pitt promptly responded with a report that a system installed
with runit-init appears broken, and in particular appears to hang
without any ability to log in.
- Dmitry reported back that it "works for him", and no further debugging
appears to have taken place.
- Dmitry uploaded an NMU to DELAYED/15.
- One of the maintainers of the init metapackage requested the cancellation of
that NMU, on the basis of Martin's report of brokenness and the lack of any
debugging. The maintainer suggested some possible paths forward (as well as
further testing).
- Dmitry refused to cancel the NMU, which then went into the archive.
- *After* the upload went through, Dmitry started proposing a mail to
the tech-ctte.
As such, the Essential init package seems to have been hijacked by a
hostile NMU refused by the maintainer. This NMU and its hijacking of the
package was not discussed anywhere else (such as -devel or -ctte), was
not approved by anyone else, and appears to be effectively a unilateral
action on the package regarding a wishlist bug.
I am making the assumption that, in the 11 hours between that refusal
and the hijacking NMU entering the archive, no entirely unforeshadowed
behind-the-scenes discussion between the maintainer and Dmitry took
place in which the differences were settled amicably and the debugging
of this critical package was completed to everyone's satifaction.
There are times that it can make sense to take over a package or upload
an NMU without the agreement of the maintainer. Those circumstances
normally occur 1) when the maintainer has provided no feedback or
response (not the case here), 2) when some further discussion has
occurred in a broader body to seek consensus (which was not done here),
or 3) when a developer has been overruled through the proper processes
and channels within Debian (which has not occurred here). And in any
case, those circumstances do not normally occur in a hurry.
Reply to: