[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.