From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Darrington Subject: Re: [PATCH] gnu: services: Add redis-service Date: Fri, 13 Jan 2017 15:56:43 +0100 Message-ID: <20170113145643.GA22646@jocasta.intra> References: <20170110072401.6756-1-mail@cbaines.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cS3Hg-0003ku-C4 for guix-devel@gnu.org; Fri, 13 Jan 2017 09:56:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cS3Hc-0003N9-F7 for guix-devel@gnu.org; Fri, 13 Jan 2017 09:56:52 -0500 Received: from de.cellform.com ([88.217.224.109]:55934 helo=jocasta.intra) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cS3Hc-0003MS-6S for guix-devel@gnu.org; Fri, 13 Jan 2017 09:56:48 -0500 Content-Disposition: inline In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: "Thompson, David" Cc: guix-devel --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 13, 2017 at 09:22:01AM -0500, Thompson, David wrote: I'm seeing a trend where people write services with configuration types that don't cover nearly the amount of configuration options to make the service useful. MySQL, and now this Redis server, are examples of this. There are many more configuration options in Redis than this service exposes. Probably what the author of the service does, it to provide just enough configurations to make it useful to him/her. =20 In the kerberos service I took the opposite approach, and provided the full range of options that the underlying daemon has - the trouble is, I have only a very vague idea of what many of those options do - so I have no chance of writing a test which exercises them. What is the worst evil - having a service with limited capabilities, or having a service which is oestensibly fully featured, but we don't know if all those features work or not? I don't know the answer to that question. What do we do? =20 File a bug with an example of how it could usefully be extended? Perhaps one thing we should do is - if we know that the service does not expose a particular feature, then we should ensure that limitation is explicitly noted in the manual. J' --=20 Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3=20 fingerprint =3D 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key. --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlh46qsACgkQimdxnC3oJ7MdvwCcDk8trHLKMZJpBQ+9m1bvHaMJ qREAn1hxTx6P53HTLGOIrbJ6y8hddJnx =jnXN -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf--