Bug#746715: the foreseeable outcome of the TC vote on init systems
Russ Allbery writes ("Bug#746715: the foreseeable outcome of the TC vote on init systems"):
> Steve Langasek <vorlon@debian.org> writes:
> > An Ubuntu developer just brought the following Debian changelog entry to
> > my attention:
>
> > tftp-hpa (5.2-17) experimental; urgency=low
> > * Removing upstart hacks, they are ugly and upstart is dead now.
>
> > Since various members of the Technical Committee argued that choosing a
> > default would not prevent Debian from supporting other init systems, I
> > would like to hear from those members how they think this should be
> > addressed.
>
> Well, one, in the abstract this seems like a bad idea. I certainly don't
> intend to remove upstart support in my packages, any more than I would
> reintroduce a bunch of PATH_MAX expressions and intentionally drop Hurd
> support.
The removed change is presumably what was added here:
tftp-hpa (5.2-9) experimental; urgency=low
* Adding upstart exit codes in initscript.
* Adding slightly modified upstart script from Steve Langasek
<steve.langasek@canonical.com> (Closes: #708851).
-- Daniel Baumann <mail@daniel-baumann.ch> Mon, 03 Jun 2013 06:50:31 +0200
(It appears that archive.debian.org doesn't keep snapshots of
experimental so it isn't easy to see exactly what was done.)
> In terms of what to do about it, I think we need more details,
> specifically around why the maintainer felt that the upstart support was
> "ugly" and involved "hacks." Removing half-implemented or
> poorly-implemented code may be appropriate in some circumstances even for
> things that we do want to support, and may involve some degree of
> judgement call (although I'd hope the maintainer would accept cleanups
> instead of removal). Do you know why the maintainer felt that way about
> the upstart changes?
#708851 does not disclose any concerns from the maintainer about the
version of these changes that were previously applied.
Obviously the patches as they were were tolerable, so it seems
unlikely that there's a compelling reason for removing them now.
In the absence of a reasonable explanation, the TC should overrule the
maintainer. We should do so promptly. I have CC'd the packages@
address for the package.
Ian.
Reply to: