[DISCUSS] Server name consolidation: murmur, murmurd, mumble-server

[sudoforge]

There appears to be a healthy variety of names to choose from, when referring to the server component of this project:

• murmur
• murmurd
• mumble-server

This can cause confusion for new and experienced users alike. It is possible that consolidating the name of the server component would be helpful in this regard, however, it should be noted that name changes are typically a task best completed glacially -- and due to this, it is perhaps not worth the effort to consolidate the name at all.

I'm opening this issue so there exists a place to discuss this, with the ultimate goal of answering these questions:

• How does the community typically use each of the names described above?
  • Answered: [DISCUSS] Server name consolidation: murmur, murmurd, mumble-server #4046 (comment)
• What should be the recommended naming scheme for packages which deliver either the client OR the server?
  • Answered: [DISCUSS] Server name consolidation: murmur, murmurd, mumble-server #4046 (comment)
  • mumble-client and mumble-server respectively

[sudoforge]

Discussion from chat.freenode.net#mumble:

sudoforge | when referencing the server component, is the **proper** name `murmur`, `murmurd`, or `mumble-server`?
@davidebeatrici | `murmurd` is the name of the binary, `d` for "daemon".
@davidebeatrici | `mumble-server` is the name of the package for some distributions.
@davidebeatrici | `Murmur` is the official name.
@davidebeatrici | However, Kissaki expressed some concerns regarding that.
@davidebeatrici | More specifically, "mumble-server" seems to be used more than `murmur`

[Krzmbrzl]

I do like that we (in principle) have 2 concise terms for referring to the client or the server respectively. However as "Mumble" often includes the server and as there are multiple terminologies being used for it, one can't use the terms "mumble" and "murmur" and be sure of everyone knowing what part of the software one is referring to.

Thus I tend to agree with @Kissaki that it might be a good idea to start referring to them simply as client and server and call the framework as a whole "Mumble".

[davidebeatrici]

I renamed the mumble label to client and the murmur label to server.

[sudoforge]

I agree that calling the framework as a whole "Mumble" makes sense, and internally calling the client and server, "client" and "server", respectively.

What about packages which contain either the client OR the server? Should we guide package maintainers to call their packages mumble-client and mumble-server, respectively?

[Krzmbrzl]

Should we guide package maintainers to call their packages mumble-client and mumble-server, respectively?

Sounds good to me. That way it is obvious for everyone what the package contains.

[toby63]

Maybe also rename the binaries? (you could keep copies or links with the old names for a while)

Personal Thought: Even though I always liked the name "murmur", I agree that it is more convenient to use precise names.

[davidebeatrici]

Yes, indeed.

[Krzmbrzl]

Closing this as we agreed on what we wanted to agree upon and afaik the installer now also says "mumble-server" instead of "murmur"

[toby63]

Some questions regarding this:

1. Will you rename the binaries as well?
2. Where exactly will the renaming take place?
   • package names (see 3.) (responsibility of package maintainers/distros etc.
   • names in documentation, readme's etc.
   • names in UI
   • folder names
   • where else?
3. Could we mention this recommendation somewhere? (like a packaging guide or faq or tips)

[Krzmbrzl]

In the long term I think renaming the binaries makes sense.

And I think the name is gradually changed and new stuff usually uses the new naming scheme afaik.

[toby63]

For context: https://bugs.archlinux.org/task/69334#comment195784
Moneyquote:

if upstream manifests this change in their repository as well.

[sudoforge]

I think the users who have posted after its closure are rightfully asking the question, "why wasn't the rename performed across the entire repository at once?". Having been a part of and subject to project renames, I understand that it can sometimes make sense to piecemeal it out, but I'm not sure that I fully understand the limitations requiring this from the Mumble project myself.

[Krzmbrzl]

I guess the only issue is that nobody actually wanted to spend the time renaming everything yet. So from my point of view, if someone was to create a PR, we'd be fine with that 🤷

[sudoforge]

I have some time today and will at least get a WIP CL up (you'll see it in the activity in this thread; I'll reference this issue).

[toby63]

Before you (@sudoforge) do that, I would like to discuss some things first:

• the names: I think that mumble-client is unnecessary long, I would stick with mumble and client (according to the specific situations)
• regarding the binaries: I also think that mumble-server would be too long; so I think we should use mumble (client) and mumbled (server; Mumble Daemon) (or something else if you have a better idea ;) )
• internal names (in code): mumble-client and mumble-server are quite long, I think it is maybe even unnecessary to rename murmur there, we could stick with that. Also there are many things (classes etc.) that are named something with murmur, so it might break if you change that all now.

But these are just ideas; I also don't know what scope you had planned for your PR, so no offense.

[sudoforge]

The CL won't be ready for merging for quite some time due to the goals:

• Rename all internal references of mumble and murmur to client and server, respectively. This includes things like classes, files, etc.
• Rename all "external" references (e.g. build outputs) of mumble and murmur to mumble-client and mumble-server, respectively.

[sudoforge]

The names mentioned in my previous comment are based on the decisions made earlier in this thread; if you'd like to open the conversation again and suggest the names mumble and mumbled, I think that's fair, and up to the maintainers.

[toby63]

The names mentioned in my previous comment are based on the decisions made earlier in this thread; if you'd like to open the conversation again and suggest the names mumble and mumbled, I think that's fair, and up to the maintainers.

Yes sry 😅. I should have mentioned that earlier, it is just a thought, because esspecially commands are mostly kept as short as possible.

And before you have much work renaming everything, I wanted to post asap 🙂 .

In general I would use:

• Mumble and client for everything related to the client
• Mumble-Server just for package names and descriptions, readme's etc.
• server for internal stuff (classes etc.)
• mumbled for server binaries (and scripts (user-wrapper etc.) maybe)
• rename murmur.ini to server.ini

---

Rename all internal references of mumble and murmur to client and server, respectively. This includes things like classes, files, etc.

That makes sense, you are right 👍.
I guess you already know what you are doing, so I will trust in your capabilities 😉.

[TerryGeng]

I would be very cautious about any renaming since Mumble has a huge community and a sudden renaming will confuse a lot of people. I have been working for the Mumble community for a while and, in my mind, mumble is the client and murmur is the server, or rather, an implementation of mumble's server.
I know there's a lot of other implementations of mumble servers like grumble. Calling the official one mumble-server makes things... just strange for me.

I think before rushing for a quick PR or anything, we'd better leave this issue to the whole community and see the reactions of other people.

[Krzmbrzl]

First to the naming:

• For internal uses (e.g. class names) we should use Client and Server
• For the binaries we should use the full mumble-client and mumble-server since client and server would be too unspecific there.
• I really dislike mumled. I would be fine with leaving the client's name as mumble and only rename the server to mumble-server
• The ini file should be mumble-server.ini again since server.ini is too unspecific

I would be very cautious about any renaming since Mumble has a huge community and a sudden renaming will confuse a lot of people.

Some packages are named mumble-server instead of murmur already. Plus the big benefit of naming the packages mumble-* is that both components will be found when searching for "mumble" in the repositories.

I have been working for the Mumble community for a while and, in my mind, mumble is the client and murmur is the server, or rather, an implementation of mumble's server.
I know there's a lot of other implementations of mumble servers like grumble. Calling the official one mumble-server makes things... just strange for me.

While older members of the community are used to these terms, new ones will be very confused when all of a sudden they hear something of murmur whereas with mumble-server it'd be immediately clear what it is about.

I think before rushing for a quick PR or anything, we'd better leave this issue to the whole community and see the reactions of other people.

The issue has been open from April to December 2020. I consider that to be enough time for folks to put share their opinion. I don't see a benefit in re-opening this discussion.

[toby63]

Discussion:
@Krzmbrzl

The issue has been open from April to December 2020. I consider that to be enough time for folks to put share their opinion. I don't see a benefit in re-opening this discussion.

I agree with @TerryGeng that we should give another chance for discussion.
Because you only had few participants back then (of which two were team members of mumble).
So I think there are some ways going forward:

1. Announcing a renaming in the next release (this way at least package maintainers will see it and comment)
2. Write some emails to maintainers.
3. Stick this topic so it's better visible.

Renaming:

• Package names: I think that is very important to change, as I remember finding it confusing to have mumble and murmur with no obvious connection.
• binary names: These are often different in many packages, so a change is not mandatory. But if we change them I think that mumble-client and mumble-server are very bad binary names. So a different solution should be found.
  • I guess we can assume no on would object keeping mumble as binary name for client
  • For server binary: I think it is important to have the term mumble in it (otherwise we could also keep murmur, it wouldn't make much difference).
    • I like mumbled, it is short and established (in many other projects as well)
    • another idea: what about mumble-srv (also an established naming scheme) ?
• internal naming: I agree that client and server are a very good way to go forward.
• murmur.ini: Well, debian also named it "mumble-server.ini", so it would be ok to use that. Nonetheless server.ini is much shorter and other software is also not making much effort naming it individually.

Transition:
We could probably ease transition with some measures:

1. We could keep a second binary with name murmur and show a message which says: command murmur is deprecated and will be removed in the future, use [whatever] instead.
2. We might advise maintainers to implement steps for transition:
   • finding the package by it's old name (murmur)
   • include notes about this
   • include the second binary (see 1.)

[Krzmbrzl]

Because you only had few participants back then (of which two were team members of mumble).

So? That's how 99% of all issues here end up looking. And I don't expect more voices here if we re-open this issue now.

Announcing a renaming in the next release (this way at least package maintainers will see it and comment)

We'll see about that if it actually happened until then

Write some emails to maintainers.

Feel free to do so. I don't have their email addresses, though.

Stick this topic so it's better visible.

I don't think that this is important enough for pinning the issue

I don't see an issue with the name mumble-server It makes it very clear what it is about and it is also not excessively long to type (plus basically all shells have auto-complete anyways).

We could keep a second binary with name murmur and show a message which says: command murmur is deprecated and will be removed in the future, use [whatever] instead.

Keeping a second binary is way too complicated imo. We could however encourage package maintainers to add a symlink for now.

If you feel like this discussion should be held anew, feel free to open a discussion ticket for it (for some reason it seems I can't convert this issue into a discussion)

[davidebeatrici]

The d suffix is not clear, the only reason we have been using it for the server's executable (murmurd) is because it can run as a daemon on Linux.

[sudoforge]

Announcing a renaming in the next release [...]
Write some emails to maintainers.
Stick this topic so it's better visible.
We could keep a second binary [...]

I maintain packages for several projects, and while I'm sure other people have different processes and methodologies for keeping their packages up-to-date, a simple read of the changelog would indicate the change. I don't see a reason to make any extra effort to notify consumers of this project, such as package maintainers.

Regarding your concerns about downstream users being able to type mumble-server -- I think this is a non-issue. Most users likely run mumble-server as part of a systemd unit, docker container, or other such mechanism. It is unlikely that they are sshing into servers to manually execute the daemon. Additionally, the cost of typing mumble-server instead of murmurd is negligible, especially when you take into consideration shell completion.

If they really care, they can create a shell alias or symlink (creating a symlink is something the package maintainers could do, too, as part of the package installation). This is not a problem the mumble project needs to solve.

[toby63]

The d suffix is not clear, the only reason we have been using it for the server's executable (murmurd) is because it can run as a daemon on Linux.

Just for the record, it is used by many other programs, so it is absolutely clear and established.

I maintain packages for several projects, and while I'm sure other people have different processes and methodologies for keeping their packages up-to-date, a simple read of the changelog would indicate the change.

Some people here seem to missunderstand.
I suggest some kind of message before the change, so more people will participate in the discussion.

Regarding your concerns about downstream users being able to type mumble-server

I almost see that as an insult, this is of course not about any ability.
This is about usual workflow.
Many people (and here we are again with arguing about what people like and dislike and how to prove that) dislike complicated syntax.
And writing mumble-server is obviously longer than murmur or mumbled.

If they really care, they can create a shell alias or symlink

And thats exactly what makes things complicated.
Software projects do something people don't like, so they start to make custom modifications of some kind, which potentially results in problems in the future.
I'm just sayin: the best solution is to take the best name in upstream directly, not doing something and telling people "if you don't like it *** ".

That being said, I hope that no one see's this as a big fight, I only want the best solution.

mumble-server is kind of ok (as emergency solution), but I would like a different binary name better.
If no one see's it like me, well then it is how it is.

[Krzmbrzl]

mumbled is actually way more complex than mumble-server since it requires knowledge about certain naming conventions instead of being self-explanatory.

[toby63]

mumbled is actually way more complex than mumble-server since it requires knowledge about certain naming conventions instead of being self-explanatory.

I admit, thats a point, at least for windows users (For clarity: No insult intended, just stating a fact, that we will have more inexperienced users on windows).

My point was more about commands being as short as possible.

---

I started a new discussion (#4699), we will see if someone has something to say.

[ghost]

I'm going to present a slightly different idea and position about this topic. Since these references to Mumble including the client and the server seemed to mostly benefit Windows installs and we will no longer build the installer with both components, we could use mumble for the client and murmur for the server explicitly. mumble-client and mumble-server are package names and should perhaps have the prefix updated to mumble-voip-... to specify the org name. This way when we describe mumble or murmur we know we are referring to the binary and not the package name.