Proposed generic release criterion: service manipulation

[Stephen Gallagher]

-----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).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlO67Z8ACgkQeiVVYja6o6PGwQCfbLP8V00yxRrMt+D52Pmqcr7f
MhMAnje8CKVKBTIYk82OEgopaBMrTCwT
=oB1G
-----END PGP SIGNATURE-----