Le vendredi, 26 août 2016, 12.55:56 h CEST Ian Jackson a écrit :
> There has recently been a thread on debian-devel ("Is missing
> SysV-init support a bug?) about the decision by a package maintainer
> to drop sysvinit support from their package. The maintainer has said
> they are reconsidering, which is good.
Yes. There was a discussion, some arguments both ways, and a extensive
blogpost [0] from the maintainer, where they write:
> Conclusions: yes, I will probably reintroduce sysvinit files just to avoid
> any flamewar.
For the case at hand, my reading of the events is that:
* the maintainer removed sysvinit support
* someone asked the wider community (d-devel) whether "missing SysV-init
support (is) a bug?"
* the discussion on the list sparkled, and clarified the various subquestions
(more below)
* the maintainer got convinced to revert his sysvinit support removal (maybe
for the wrong reasons; but still)
The subquestions, as I see them:
A) is it currently acceptable to remove existing sysvinit support?
A.1) … even in absence of bugs in said support?
A.2) … with bugs filed, and help/patches provided ?
A.3.) … with bugs filed, help requested, but no patches?
B) is it currently acceptable to ship a new without package without sysvinit
support?
In my reading, the answers given by the discussion for the various A questions
are _no_ for A.1 and A.2.
For A.3, I think Sam summarized it well enough:
> However if someone is having difficulty maintaining the scripts or they
> are broken, it is reasonable for them to ask for help, and if no one
> steps forward, eventually the scripts will become buggy enough that the
> normal severity bug of a package without an init script is better than
> the state of a package with a broken init script
… that is: _it could be OK_.
The current answer to B), as per our (outdated) Policy is _no_. I feel there
is wide agreement that this should be fixed though.
Ian Jackson wrote:
> But, the discussion on -devel has shown that there are some other
> maintainers who are considering similar steps, and that the project's
> view on this is not settle.
Having this discussion within the project is fine, and I'll need to be
convinced that having the TC emit preemptive opinions on this subject will be
doing more good than harm.
> So: would the TC please clarify that the decision that
>
> For the record, the TC expects maintainers to continue to support
> the multiple available init systems in Debian. That includes
> merging reasonable contributions, and not reverting existing
> support without a compelling reason.
>
> still stands.
It does, I don't see a need to re-state that it does [1].
> and that the answer to this queston
>
> However, that was two years ago. How long should we be expected to
> continue maintaining sysvinit scripts?
>
> is "indefinitely, and specifically until a contrary decision by the
> TC" (subject to quibbles over the exact meaning of "maintaining").
For the record, I don't particularily appreciate the TC being told _what_ to
rule (but I am a non-native-english-speaker, probably misinterpreting your
"would the TC clarify that (…) the answer to this question (…) is (…)").
Furthermore, I (currently) disagree that your proposed answer is a good answer
for the TC to provide to this question. In particular, it would put the TC in
the position of needing to decide of the appropriate timing for phasing
sysvinit support out. (And an MIA TC would default to "indefinitely", by
construction).
This is something I see the Debian developer community figuring out by itself.
The TC will always be available for escalations, as usual; I don't think we're
at an escalation point where preemptively locking the discussion is useful.
> Or to put it another way:
> The answer to "is missing sysvinit support a bug" is "yes, and
> it will continue to be regarded as a bug until further notice".
I disagree, see my interpretations of the answers to the A{1,2,3} questions
above.
> Of course a maintainer is not required to personally fix every bug,
> but a maintainer should not introduce bugs without good reasons, and
> should merge reasonable bugfix contributions.
Yes. This shouldn't need repeating, obviously. Whether "removing untested, not
updated and likely buggy sysvinit support" really consists of "introducing
bugs" should be debated per-package though.
Le vendredi, 26 août 2016, 14.14:25 h CEST Ian Jackson a écrit :
> I think what is really needed is a clear statement from the TC that
> support for sysvinit should not be regarded as transitional or
> time-limited.
That's obviously the crux of the issue. I certainly see the sysvinit support
as transitional and time-limited; Debian just hasn't decided for the shape of
the transition period or its timespan.
It's not OKay for maintainers to preemptively remove working sysvinit support.
But I wouldn't like the TC to say "sysvinit is here forever", because I think
that's simply not true.
--
Cheers,
OdyX
[0] http://ral-arturo.blogspot.ch/2016/08/why-conntrackd-in-debian-is-better-with.html
[1] Ironically, having multiple TC members publicly state that they think it
still stands achieves roughly the same effect, than explicitely re-emitting
the same decision.Attachment:
signature.asc
Description: This is a digitally signed message part.