all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: swedebugia <swedebugia@riseup.net>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: guix-devel@gnu.org
Subject: Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.
Date: Fri, 29 Mar 2019 14:27:59 +0100	[thread overview]
Message-ID: <5476d986-6fd3-cfa3-fc11-c3a82088ae28@riseup.net> (raw)
In-Reply-To: <87mulg2whj.fsf@elephly.net>


[-- Attachment #1.1: Type: text/plain, Size: 2455 bytes --]

On 2019-03-27 16:00, Ricardo Wurmus wrote:
> 
> Pierre wrote:
>> Finally, as I mentioned above with the completion systems that we have,
>> we've got nothing to lose in having long names.

Reading the arguments of Ricardo I changed my mind and support keeping
the variable names short.

> 
> swedebugia wrote:
>> Good useability is important and cryptic acronyms are not something to
>> expose to the user if possible to avoid IMO.
> 
>> Maybe this is where we need to discuss what our target audience is?
>> Nerds only? […]
> 
> This is a false dichotomy, in my opinion.  Good usability is not at odds
> with using short package names.  I also think that the length of package
> names is not going to be a deciding factor for somebody who is not a
> “nerd”, so let’s not go down this tangent please.  There are different
> interfaces to package managers, and we’re currently not offering fully
> functional interfaces that would be more suitable for people without a
> “techie” background.  If you want to make Guix more accessible *that’s*
> a screw to turn, not the length of package names.

Thanks for sharing this. I regret having written this as a dichotomy.
I'm actually very happy with guix overall and the guix-web frontend is
awesome. :)
I'm sorry if I added tension to this discussion. I will try expressing
myself less confrontationally going forward.

> 
> Completion should not be used as an excuse to use long package names.
> For one, not everyone is using Bash, so not everyone benefits from our
> Bash completions.  (Some shells can reuse Bash completions but this does
> not invalidate the point.)

I agree.

> 
> The package name is just an identifier for command line interaction
> purposes.  There is no reason why it should be descriptive – after all,
> that’s what the package description is used for.  Users can easily find
> the package they are interested in by using the search feature.  That
> will give them the short name by which they can refer to the package.
> Having that short name be long serves little purpose.

I agree.

Would you agree that we try to strike a compromise with short package
variable names, synopsis' and longer descriptions? Should we state this
clearly in the documentation for packagers?

I guess a GUI-search would work like guix-web and search all three for
hits and displaying the results.

-- 
Cheers Swedebugia


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2019-03-29 13:26 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190326131842.7363.84034@vcs0.savannah.gnu.org>
     [not found] ` <20190326131845.1B177209E3@vcs0.savannah.gnu.org>
2019-03-26 14:54   ` 06/15: gnu: wesnoth-server: Rename package to the-battle-for-wesnoth-server Tobias Geerinckx-Rice
2019-03-26 14:20     ` Pierre Neidhardt
2019-03-26 15:18     ` Ricardo Wurmus
2019-03-26 15:32       ` Pierre Neidhardt
2019-03-26 17:53         ` Andreas Enge
2019-03-26 18:25           ` Pierre Neidhardt
2019-03-27 11:11           ` Ludovic Courtès
2019-03-27 11:36             ` Pierre Neidhardt
     [not found] ` <20190326131844.C73EC209E3@vcs0.savannah.gnu.org>
2019-03-27 11:07   ` 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth Ludovic Courtès
2019-03-27 11:46     ` Pierre Neidhardt
2019-03-27 13:20       ` swedebugia
2019-03-27 15:00         ` Ricardo Wurmus
2019-03-27 16:42           ` Pierre Neidhardt
2019-03-28  7:59             ` Ricardo Wurmus
2019-03-28  8:09               ` Pierre Neidhardt
2019-03-29 13:27           ` swedebugia [this message]
2019-03-27 15:15         ` Ludovic Courtès
2019-03-27 18:34         ` Tobias Geerinckx-Rice
2019-03-27 18:26           ` Pierre Neidhardt
2019-03-27 18:44             ` Daniel Jiang
2019-03-27 21:15             ` Tobias Geerinckx-Rice
2019-03-28  8:17               ` Pierre Neidhardt
2019-03-29 14:02                 ` Tobias Geerinckx-Rice
2019-03-29 15:16                   ` Andreas Enge
2019-03-29 16:42                     ` Naming, hacking, and policies Ludovic Courtès
2019-03-29 19:23                       ` Ricardo Wurmus
2019-03-31 16:33                         ` Ludovic Courtès
2019-03-30 13:54                       ` sirgazil
2019-03-31 16:37                         ` Ludovic Courtès
2019-03-31 18:03                           ` sirgazil
2019-03-31 20:31                             ` Ludovic Courtès
2019-03-31 22:59                               ` sirgazil
2019-04-01  0:07                               ` Tobias Geerinckx-Rice
2019-03-29 19:57                     ` 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth swedebugia
2019-03-27 15:13       ` Ludovic Courtès
2019-03-27 16:25         ` Pierre Neidhardt

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5476d986-6fd3-cfa3-fc11-c3a82088ae28@riseup.net \
    --to=swedebugia@riseup.net \
    --cc=guix-devel@gnu.org \
    --cc=rekado@elephly.net \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.