Bug#835507: Please clarify that sysvinit support decision is not going to expire
Sam Hartman schreef op 28-08-2016 1:37: I'm nervous of going too far down the path of legalisms. Asking those who need the scripts to prove (or even say) they still need them is not what we want. 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. Similarly, if the community of people who care about sysvinit is unwilling to spend the time keeping it working, eventually sysvinit as a whole will be unmaintained and buggy. True, but I don't think those conditions are there. I mean that the statements: a) the scripts need (urgent) maintaining and b) in the context of the actual maintaining they do need, the help that is necessary isn't there. Are not true. I think the "maintainership requirement" of those scripts are currently being exaggerated, and if you exaggerate what is needed, you will also look for more help than is available, and then conclude that the community isn't there. Don't forget that SystemD is this warehouse of troubles that need a million hours of employment each year to keep it going, and SysV is that small house in the desert that needs a bit of plumbing now and then for the water that is not there (currently). SysV didn't do all that much and so still also doesn't need to do all that much. If anyone uses those scripts and finds they are broken, they can fix them (for their own systems) and supply patches. If no one does, then perhaps they still work, or the time hasn't been there for them to be tested yet. And that time may come when it is the time for it. They are not in harms way and they are not harming anyone. I only mentioned the legal thing in order to stay rational: - where is the harm in keeping those scripts around, if most systems do not use them, and the systems that do, would be able to change/fix/maintain them for their own, most likely. - where is the benefit in getting rid of them, if they only achieve people having less choice? So there are four questions: - qualify and quantify the benefit of not having them - qualify and quantify the harm of not having them - qualify and quantify the benefit of keeping them around - qualify and quantify the harm of keeping them around. - Surely the harm to SystemD users is minimal - Surely the benefit to SystemD users can only be measured in more hours of employment for SystemD people - Surely the harm to SysV users and SystemD users alike who like having an alternative, can be abysmally large - Surely the benefit for them to keep them around can be substantial. I don't see how the benefit to SystemD users can ever be called "substantial". Ideological, yes, but not quantifiably rational. You won't be able to quantify those benefits. So I say skip the qualifying and stick to the quantity. - the only thing that can tilt that scale towards SystemD benefiting more is if their numbers would be hge compared to the SystemD and SysV users alike who would benefit from having those scripts around. - but just because I (for instance) qualify as a SystemD user (by choice, or by install) doesn't mean I see any benefit in having SystemD being the ONLY THING so please don't include me in those measurements. - you will hate the day when you discover you've been scammed and you need something to fall back to and it's no longer there, when it didn't cost anyone anything to keep it around and the only dumped it so you wouldn't have a way back. So you must take care to ask the right questions and actually inform with those SystemD users as to their actual opinions. Just because they have a SystemD system installed doesn't mean they like for it being the only thing ever. One day you will find you need something and you'll be happy you kept it around. That's all I can say. From life experience ;-). If you are going to ask questions like: - Do you feel SysV scripts are very necessary these days seeing that SystemD handles most of everything for most applications, and most applications have good and functioning SystemD service files? You will get answers like "Well, maybe not. Maybe you're right." But if you ask questions like: - Do you feel it is important to have a fallback measure in case something doesn't work and it is easier to make it work with a simple SysV init script, that you would still have at your disposal? They will say "Sure, why not. I'm all for that." Also, SystemD often lies to you about the startup times of programs. Often times no delay or timeout has been specified in the service file and you think it will hang forever. The actual startup script then times out after all, or sometimes it doesn't. SystemD often hangs for my systems for no reason at all that I c
Bug#835507: Please clarify that sysvinit support decision is not going to expire
]] Bart Schouten > > I agree on this too. To the extent it should be considered > > time-limited, it should be «until N releases after sysvinit is > > removed» or somesuch, if that happens. > > In legal terms, in law, it would be considered that the burden of > proof lies with those who want to remove it. As Sam writes, this isn't law and so this isn't terribly relevant. We routinely remove support for no-longer-supported infrastructure. For a very similar situation, there was no disagreement about removing upstart jobs once stretch is out. (IIRC on the timing.) Similarly, if sysvinit is removed and we don't have other bits of the distribution needing sysvinit scripts, we should stop shipping them. This isn't true today, so we're not going to remove sysvinit scripts. > The burden of proof would be laid with the ones who want to remove it. There's a balance that needs to be struck here: the needs of those who need those scripts against the cost of maintaining them. > I think any kind of time-limited removal that you pronounce in > advance, is irrational. I did not do this, though. > "My grandmother used that" is not a good reason. Good thing nobody used that as an argument, then. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#835507: Please clarify that sysvinit support decision is not going to expire
> "Bart" == Bart Schouten writes: >> I agree on this too. To the extent it should be considered >> time-limited, it should be «until N releases after sysvinit is >> removed» or somesuch, if that happens. Bart> In legal terms, in law, it would be considered that the burden Bart> of proof lies with those who want to remove it. Bart> Asking the supporters of those scripts to prove that they Bart> still need them would be considered an unreasonable burden. I'm nervous of going too far down the path of legalisms. Asking those who need the scripts to prove (or even say) they still need them is not what we want. 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. Similarly, if the community of people who care about sysvinit is unwilling to spend the time keeping it working, eventually sysvinit as a whole will be unmaintained and buggy.
Bug#835507: Please clarify that sysvinit support decision is not going to expire
I agree on this too. To the extent it should be considered time-limited, it should be «until N releases after sysvinit is removed» or somesuch, if that happens. In legal terms, in law, it would be considered that the burden of proof lies with those who want to remove it. Asking the supporters of those scripts to prove that they still need them would be considered an unreasonable burden. The burden of proof would be laid with the ones who want to remove it. I think any kind of time-limited removal that you pronounce in advance, is irrational. "My grandmother used that" is not a good reason.
Bug#835507: Please clarify that sysvinit support decision is not going to expire
]] Josh Triplett
> On Fri, 26 Aug 2016 14:14:25 +0100 Ian Jackson
> wrote:
> > Sam Hartman writes ("Re: Bug#835507: Please clarify that sysvinit
> > support decision is not going to expire"):
> > > I don't want to make a blanket statement that it's a bug not to include
> > > an init script. The systemd package includes a number of daemons and
> > > services and installs no init scripts, and no really, that actually is
> > > the right answer for that package. Policy should basically means bug of
> > > normal severity. (I've always wished that the policy people would be a
> > > bit more nuanced especially when taking a term from RFC 2119, which
> > > more-or-less already includes the nuanced language they need, but
> > > people seem to do a fairly good job of accepting the nuances even though
> > > that's not quite what policy says.)
> >
> > You could say that missing sysvinit support is a bug unless there's a
> > good reason why this particular package ought not to support sysvinit.
>
> This seems like a completely reasonable thing for Policy to say. It
> actually doesn't say that today (see Policy 9.11), but I think it
> should.
This sounds pretty reasonable. Trying to enumerate the various reasons
why (or why not) a package does/doesn't support sysvinit doesn't seem
like a great way to spend our time.
> Assuming Policy does say that, then that seems like a sufficient
> justification to 1) file a bug and 2) provide or seek out help fixing
> that bug. (Right now, Policy provides enough justification to file a
> "Severity: serious" bug, but that doesn't seem reasonable; a
> normal-severity bug does, though.)
Maybe important since it's removing existing support, but I'm more
interested in fixing bugs/preventing them being created in the first
place than discussing severities.
[...]
> That's a question of available volunteer time. I don't think sysvinit
> support should be regarded as "time-limited"; I don't, for instance,
> think "that was two years ago" in isolation serves as a reasonable
> argument for ignoring sysvinit. However, I do think it's reasonable to
> expect people who want it to work to provide assistance keeping it
> working. For instance, if someone filed a bug on the sysvinit support
> in a package, it seems reasonable for the maintainer to tag it "help".
I agree on this too. To the extent it should be considered
time-limited, it should be «until N releases after sysvinit is removed»
or somesuch, if that happens.
> And if upstream of a package starts requiring systemd and drops support
> for sysvinit, I think it's reasonable for a maintainer to send a note to
> debian-devel and similar asking for volunteers to maintain a version of
> that software with sysvinit support, and to talk with those volunteers
> about what shape that maintenance should take (e.g. working with
> upstream, providing a new upstream, providing patches to the existing
> pakage). Dropping such support the moment upstream does without any
> warning seems unreasonable.
Somewhat depending on the package and level of integration with
sysvinit/systemd, but I'm pretty much in agreement with you here as
well.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Bug#835507: Please clarify that sysvinit support decision is not going to expire
Vincent Bernat writes ("Re: Bug#835507: Please clarify that sysvinit support
decision is not going to expire"):
> Maybe sysvinit users (and advocates) could answer to the current RFA on
> src:sysvinit (#811377). None of the people who volunteered half a year
> ago seemed to have carried on despite some good will. Latest uploads are
> all NMU from systemd people.
Hrm. Thanks for the prompt. I have subscribed to the PTS for
sysvinit, at least.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#835507: Please clarify that sysvinit support decision is not going to expire
On Fri, Aug 26, 2016 at 10:05:46PM -0700, Josh Triplett wrote:
> The reaction to every single instance of someone finding it a pain to
> maintain sysvinit support should not be "as a reminder, the TC has a
> giant hammer and will hit you with it". The reaction should be "are
> there people willing to *help* maintain sysvinit compatibility, who
> actually use it, who will notice when it breaks, and who will send
> patches?"
I agree.
> I do think that developers (*not* the TC) with an interest in sysvinit
> support should explicitly say that if anyone needs help maintaining
> sysvinit support for their package, they'd be willing to volunteer to
> provide such help.
I agree.
> Anyone willing to volunteer for that?
I haven't found anybody personally volunteering for that. I just have
seen people saying that (other) people should (or will) do that.
So: do we have anyone, someone(s) who are volunteering to fix any bug
with init scripts in any package? Please raise your hands.
btw, somebody should also do something about #832508 ("O: systemd-shim)
I believe.
--
cheers,
Holger
signature.asc
Description: Digital signature
