search

mumble-voip / mumble

Mumble is an open-source, low-latency, high quality voice chat software.
https://www.mumble.info
Other
6.28k stars 1.11k forks source link

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

Closed sudoforge closed 3 years ago

sudoforge commented 4 years ago

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

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:

sudoforge commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

sudoforge commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Yes, indeed.

Krzmbrzl commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

if upstream manifests this change in their repository as well.

sudoforge commented 3 years ago

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 commented 3 years ago

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 :shrug:

sudoforge commented 3 years ago

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 commented 3 years ago

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

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

sudoforge commented 3 years ago

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

sudoforge commented 3 years ago

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 commented 3 years ago

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 :sweat_smile:. 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 :slightly_smiling_face: .

In general I would use:

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 :+1:. I guess you already know what you are doing, so I will trust in your capabilities :wink:.

TerryGeng commented 3 years ago

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 commented 3 years ago

First to the naming:

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 commented 3 years ago

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:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

toby63 commented 3 years ago

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 (https://github.com/mumble-voip/mumble/discussions/4699), we will see if someone has something to say.

ghost commented 3 years ago

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.