-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DISCUSS] Server name consolidation: murmur
, murmurd
, mumble-server
#4046
Comments
Discussion from
|
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". |
The community of Mumble/Murmur maintainers, contributors, distributors, and users refer to the server component of the Mumble project by three names: * `murmur` * `murmurd` * `mumble-server` This patch renames the image to `mumble-server` internally, as an attempt to better convey what the image is packaging. closes sudoforge/docker-images#96 refs mumble-voip/mumble#4046
The community of Mumble/Murmur maintainers, contributors, distributors, and users refer to the server component of the Mumble project by three names: * `murmur` * `murmurd` * `mumble-server` This patch renames the image to `mumble-server` internally, as an attempt to better convey what the image is packaging. closes sudoforge/docker-images#96 refs mumble-voip/mumble#4046
The community of Mumble/Murmur maintainers, contributors, distributors, and users refer to the server component of the Mumble project by three names: * `murmur` * `murmurd` * `mumble-server` This patch renames the image to `mumble-server` internally, as an attempt to better convey what the image is packaging. closes sudoforge/docker-images#96 refs mumble-voip/mumble#4046
I renamed the |
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 |
Sounds good to me. That way it is obvious for everyone what the package contains. |
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. |
Yes, indeed. |
Closing this as we agreed on what we wanted to agree upon and afaik the installer now also says "mumble-server" instead of "murmur" |
Some questions regarding this:
|
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. |
For context: https://bugs.archlinux.org/task/69334#comment195784
|
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. |
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 🤷 |
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). |
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. |
The CL won't be ready for merging for quite some time due to the goals:
|
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 |
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:
That makes sense, you are right 👍. |
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, 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. |
First to the naming:
Some packages are named
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
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. |
Discussion:
I agree with @TerryGeng that we should give another chance for discussion.
Renaming:
Transition:
|
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.
We'll see about that if it actually happened until then
Feel free to do so. I don't have their email addresses, though.
I don't think that this is important enough for pinning the issue I don't see an issue with the name
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) |
The |
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 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. |
Just for the record, it is used by many other programs, so it is absolutely clear and established.
Some people here seem to missunderstand.
I almost see that as an insult, this is of course not about any ability.
And thats exactly what makes things complicated. 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. |
|
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. |
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 |
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:
murmur
,murmurd
,mumble-server
#4046 (comment)murmur
,murmurd
,mumble-server
#4046 (comment)mumble-client
andmumble-server
respectivelyThe text was updated successfully, but these errors were encountered: