-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/07/2014 02:51 PM, Adam Williamson wrote:
On Fri, 2014-07-04 at 12:22 -0700, Adam Williamson wrote:
Still working on Fedora 21 release criteria. It seems to me that there's one area currently lacking in the criteria which all the Products would probably like us to have, hence I'm proposing it as a new 'generic' criterion, not Product-specific. We still haven't figured out exactly how to present the criteria, so for now I'm proposing this one be added as a new Fedora 21 Alpha criterion, i.e. it goes to https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria (under "Post-install requirements"). Here's the proposed criterion:
System service manipulation
It must be possible to start, stop, enable and disable system services using the initialization framework's standard commands.
I don't think it needs any footnotes beyond standard 'References'.
Does this seem reasonable to everyone? Thanks!
So two or three people read this differently from how I intended, indicating that I wrote it unclearly. Here's a second attempt:
The default system init daemon (e.g. systemd) must be capable of starting, stopping, enabling and disabling correctly-defined services.
Footnote:
"Correctly-defined services" means that this criterion is not intended to require there are no broken services in the distribution, but that the init daemon itself works - therefore, the criterion is not violated by a buggy service script, only if the init daemon itself is broken. A sufficiently-important service being broken might constitute a violation of another criterion - for instance, a service for a logging daemon being broken might violate the requirement that logging works - but not this one.
Thank you very much. This is much more clear. Looks like a good phrasing to me.
One thing that we might want to decide is whether we want to block on SysV service compatibility, and if so, for how long. If we want to make that blocking, we can define "correctly-defined services" to include those native to the init daemon and sysv ones.
Yes, we should make this decision. I suspect this needs to be a FESCo-level decision, but my gut reaction is this: A regression in systemd's support of SYSV init scripts should _NOT_ be release-blocking (it can be considered a bug, but we shouldn't stop-ship for it).