From: John Darrington <john@darrington.wattle.id.au>
To: "Thompson, David" <dthompson2@worcester.edu>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: [PATCH] gnu: services: Add redis-service
Date: Fri, 13 Jan 2017 15:56:43 +0100 [thread overview]
Message-ID: <20170113145643.GA22646@jocasta.intra> (raw)
In-Reply-To: <CAJ=RwfaeuPCE3NYA8rJePhHcGk9L_W8SKjDxAkPyg+v0z1xNvQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]
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.
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?
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'
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2017-01-13 14:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-10 7:24 [PATCH] gnu: services: Add redis-service Christopher Baines
2017-01-12 15:49 ` Ludovic Courtès
2017-01-13 14:22 ` Thompson, David
2017-01-13 14:42 ` David Craven
2017-01-13 14:56 ` John Darrington [this message]
2017-01-13 22:01 ` Ricardo Wurmus
2017-01-14 10:37 ` Hartmut Goebel
2017-01-14 13:40 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170113145643.GA22646@jocasta.intra \
--to=john@darrington.wattle.id.au \
--cc=dthompson2@worcester.edu \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).