Release Version 1.3

[EmperorArthur]

I'm creating this issue because I haven't seen it discussed anywhere else. If there is an active discussion please post a link to it.

Mumble version 1.3 has plenty of stable features that many users value. It has a dynamic system to keep plugins up to date automatically, channel filters, per user volume controls, etc. Unfortunately, the long time period between stable releases means many users are on version 1.2.

Many users use sites like mumble.com as their download source (It's the first result in a google search for Mumble), and those only serve stable versions. Barring any regressions, a stable 1.3 release should be nothing but a good thing.

Many users are moving to alternative products (Discord) from Mumble. Part of this is discord's web client, and persistent server. Part of it is their, ugly, UI design and the fact the servers are free. But at least part of it is the features discord has and Mumble lacks, like per user volume control.

Releasing a 1.3 stable release will being many new features to the users, and shows that Mumble has an active development community. Given the long time from the 1.2 release I feel that now is the time to proceed. There are only two main questions that need to be answered:

• When was 1.2 released?
• Are there any regressions when moving from 1.2 to 1.3?

---

See Blocker and Critical issues.

[mkrautz]

Yeah, we need to do a release soon and get on a proper schedule once again.

The way I see it, there are a few features (SRV records, overlay launcher filter) and a few bug fixes I'd like to get in before we cut a beta, and then we can, IMO, do a release.

[EmperorArthur]

Let's see here.

For overlays, that's Issue #2059, #1953, #1954 and pull #2371.

For SRV records that's #1242, which someone attempted to implement via a QT5 only patch, number #1306.

I think that's it for those two features. Which bugs do you see as blockers?

[mkrautz]

Bugs:

https://github.com/mumble-voip/mumble/issues/2199 - We need to verify whether the extra locking that was added fixed the problem

https://github.com/mumble-voip/mumble/issues/1874 - We need to remove NUL bytes in strings exposed via Ice - or mark some fields as deprecated and add sequence properties for them as an alternative.

[Tarun80]

@EmperorArthur 1.2.0 came out in 2009-12-10 according to https://wiki.mumble.info/wiki/1.2.0

[mkrautz]

The predecessor to 1.3.0 would technically be 1.2.4. 1.3.0 was supposed to be 1.2.5, but we changed the versioning to allow us to release patch releases for 1.2.x for security and bug fixes.

Not that that improves the situation dramatically.

[Kissaki]

Relevant 1.3.0 milestone

[EmperorArthur]

There are currently 46 open issues, some of which date back to 2013. Of those, this thread has identified 6 major blockers.

Perfect is the enemy of good enough. To most users the project is stagnant right now. Given that the last stable feature release was 1.2.4 in 2013, I can't blame them.

For example, one feature Discord is touted as having versus Mumble is per channel audio volume. 1.3 has had that for quite a while, but when I checked with everyone I knew who used mumble they were all using 1.2. They didn't even know 1.3 existed, and were wary of trying a "Development Snapshot."

Proposal

I propose that all issues that do not block a 1.3 release be moved from the 1.3 milestone to the 1.4 milestone. This gives everyone a clear indication of things that are major priorities for the project.

[C0rn3j]

Would be awesome since the 1.2.x branch uses EOL version of Qt at least on Linux.

[EmperorArthur]

Wow, I didn't realize QT4's been EOL for an entire year. That's not a happy place for Mumble to be from a security perspective.

http://blog.qt.io/blog/2015/05/26/qt-4-8-7-released/

[jammet]

I can only encourage you to produce a 1.3 stable release. Everybody I know is enjoying the snapshots, currently.

(Also because every single person I point to the download site doesn't seem to simply FIND the 1.3 release I tell them to download. Either that or they don't find the x64 version ... I'm not making this up :). No idea why, the download section seems to confuse a lot of people, and then I get asked why their overlay isn't working)...

[mkrautz]

To provide an update to this, we've created new priority labels on GitHub. See https://wiki.mumble.info/wiki/Issue_Priorities for details.

I've applied labels to all the 1.3.0 milestoned issues. Some of them might be slightly off, but I think most of them are OK.

[mkrautz]

The above rules state the in order to release 1.3.0, we have to fix the following bugs:

1.3.0 bugs with priority P0: https://github.com/mumble-voip/mumble/issues?utf8=%E2%9C%93&q=is%3Aopen%20label%3A%22priority%2FP0%20-%20Blocker%22%20milestone%3A1.3.0

1.3.0 bugs with priority P1: https://github.com/mumble-voip/mumble/issues?utf8=%E2%9C%93&q=is%3Aopen%20label%3A%22priority%2FP1%20-%20Critical%22%20milestone%3A1.3.0%20

[rburchell]

It's now approaching a year since this was filed. As a long term software developer and open source contributor, I understand that a lot of work goes into making a high quality release, but I do wonder if that level of concern for high quality can make one overlook other (more immediate) problems.

I recently noticed that 1.2.x was using Qt 4 on Fedora (which as already mentioned is EOL, but also tends to provide a much worse experience[1] in my opinion than Qt 5 running on top of my own work, https://github.com/CrimsonAS/gtkplatform/), so I attempted to build against Qt 5, only to find that the 1.2 release has problems (since fixed I think, from looking around git) that prevent my doing that out of the box, and then found this issue which appears to be in limbo- and with several of the issues linked dating back a number of years, this doesn't look like it is going to be resolved any time soon.

With respect, I would suggest that it may be doing more harm than good in keeping releases in stasis indefinitely. I can't speak for everyone, but as a user, my first experience with Mumble was not a great one, I think it's safe to say, given the amount of work that has gone in since the last 1.2 release. And on the other hand: this also isn't a particularly encouraging state of affairs to me as a potential contributor: I have no desire to work on a release that has no chance of shipping seemingly indefinitely, but nor do I want to perform necromancy and work on an ancient release way behind the "latest" when it's probably not necessary to do so.

I'm not sure what I'm trying to say here, so I guess I'll just cut to it: my personal suggestion would be that getting a release out relatively soon - regardless of the open bug list - would be a good idea. It may have problems, but nothing is insurmountable, and the appearance of a slightly more "blessed" 1.3 that can make its way to end users wouldn't mean that 1.2 would vanish immediately for those that required it.

To make it clear, I mean no disrespect by this comment, I'm very happy to see that there's something open source in this space. I'm new to Mumble, and just felt that my perspective/$0.02 may be worth offering. I hope it's of some use.

[1]: here's a screenshot of a freshly started, connected but otherwise untouched Mumble instance. note the tiny icons, not-quite-native menus, and small window size meaning that text isn't easily visible.

[stikonas]

Also please note, that KDE will soon release 17.12 version of its Applications which no longer ships any Qt4 based applications. After this, most GNU/Linux distributions will simply start cleaning up other unported Qt4 programs. See e.g.

https://wiki.debian.org/Qt4Removal https://bugs.gentoo.org/631788

[EmperorArthur]

Here's the explicit Debian bug about this issue:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874683

[C0rn3j]

It's now been over a year since this issue was open.

Qt 4 is still EOL, so I will repeat a suggestion in here - how about releasing 1.3 now and moving all current issues to 1.4?

Is there something seriously blocking the 1.3 release?

[ghost]

Remaining issues for 1.3.0: https://github.com/mumble-voip/mumble/milestone/1

[mkrautz]

No, the blockers are the P0 issues.

[killrhythm09]

So what's holding back progress on the blockers? I'm aware I have no right to complain about the state of the project since I'm not a contributor and it's free software, but as a long-time user of Mumble, it's been frustrating to see all my friends migrate to Discord while things have essentially stagnated here with no stable releases for a number of years. This issue itself is almost a year and a half old.

Is there anything volunteers can do to expedite the process?

[tillschaefer]

Gentoo is dropping qt4 packages and thus also mumble: https://bugs.gentoo.org/656826

[malteme]

qt4 support ended two and a half years ago, it's really time to release mumble 1.3.

[C0rn3j]

So there are currently three blocker (P0) issues - https://github.com/mumble-voip/mumble/issues?q=is%3Aopen+is%3Aissue+label%3A%22priority%2FP0+-+Blocker%22

1) #2071 - two contributors agreed to drop a page from the installer, which would resolve the issue. Seems like a quick fix that's easy enough? 2) #2865 - Seems like Mumble isn't using current dependency versions and it looks like it's mostly on @mkrautz, asked for status on the issue. 3) #3409 - which seems to be a duplicate of #2865

[LucasToole]

Gentoo Linux has officially masked mumble < 1.3 and USE=mumble, blocking new installations of any version other than the upstream git repo https://bugs.gentoo.org/656826 https://packages.gentoo.org/packages/media-sound/mumble

[stikonas]

@Ojoesinco Well, upstream git repo version is also not keyworded. There isn't that much difference for users between masked and not keyworded...

But unfortunately it doesn't look like mumble project cares about being removed from distros :(.

[reelsense]

@stikonas I've had a very simple PR open since last year... It's a PR that adds a bot to close all this unimportant crap that they don't just make a decision on after X amount of months.

Their indecisiveness is very off-putting. There must be some politics that we're not clued into. I'm closing my PR because I'm tired of looking at it. They can reopen it if someone takes control.

[AzP]

Hi, I came here as a Gentoo user who's forced his friends to install Mumble for playing a couple of games, that is about to have it uninstalled since Qt 4 is going out the window... I hope you guys can push for a 1.3 release, and then perhaps fix the most critical issues in a 1.3.1 within a couple of weeks.

I appreciate your work!

[reelsense]

I appreciate Mumble a lot as well! I'm just frustrated trying to guess what's happening from the outside.

_{(Sorry off topic.)}

[Kissaki]

Let me just say sorry for the lack of information, leadership and stable releases of this project.

Unfortunately, this is pretty much just as frustrating for us, if not more, than for our users. We contribute our free time and have to manage and prioritize what we can and should work on, also caring for ourselves. Sadly, we currently do not have people committing enough time per week for this, and no strong leadership either. We are not funded. We struggle - as is blatantly visible.

We do hear you, and talk internally about if and how we can improve the situation. We are all limited on time. We did talk about that some kind of leadership role with committed time and decision power could help, but we don't really have someone to fill that role.

While I would like to work on Mumble full time, or part time, that is not the reality I currently live in. I have a full hour week, as a software engineer as well, so in the evenings and weekends, it should be more than chores to work on, and some other stuff as well to stay healthy. Even working on simple features can be a lot of effort and is really frustrating when you realize it is not so simply done - after all Mumble is quite complex already, and there often are multiple things to consider.

When I do reviews I also have the expectation of myself to do it thoroughly. That often means investing time into investigating and thinking about the premise, the implementation, possible issues with our usability or technology, etc. It often feels like a chore.

So yeah, I don't know what else to say. It's frustrating for all of us. We're trying out best, in the time we feel comfortable to spend.

[C0rn3j]

@Kissaki Thanks for trying to stay in touch with the community via the messages and the Px tag system.

I'd however like to highlight something that was suggested here - Why not (at least for one time, since the last proper release is years behind) ignore all the bugs, release 1.3 and deal with the issues that stem from it after?

I think just releasing 1.3 is a way lesser evil than letting the project rot for the following reasons -

Pros:

• 1.3 generally just works. I don't recall having a general usage problem on neither Linux or Windows when using 1.3 development snapshots
• Qt4 has been EOL for years - Distributions have already started dropping Qt4 apps I can't imagine using a long-EOL framework is great from a security standpoint
• 1.3 has lots of new features that many people consider essential, such as per-user volume adjusting

Cons:

• Issues that are only in 1.3 will become a bigger problem, though am not aware of any that would straight out block general usage
• The release process itself takes time, which you did mention that project lead does not have much of
• It will be a while before 1.3 gets into the repositories of stable Linux distributions, but such is the nature of LTS (Only mentioning it because I recall a project member citing this as a problem somewhere)

It's got to the point where Linux users are starting to have issues installing Mumble in the first place, I believe I'm speaking for the vast majority of users when saying that we'd prefer slightly buggy release than a dead project.

---

While this is perhaps a whole another issue, you mentioned lack of funding. Other FOSS projects have managed to stay afloat by simply asking for money and being transparent about their goals and what they want to use the money for.

Namely Krita and their usual kickstarters, RPCS3's Patreon, and GIMP at least has a donation page where they point at their member's fundraisers/donation_pages.

Maybe doing a fundraiser should be considered so the project could hire a lead?

[Kissaki]

Just to drop in some more infos on what I am working on: I want to fix our Ubuntu PPA builds before checking this ticket and it's blockers specifically, and coming to a decision or work here.

For the PPA I did do some analysis last weekend, and… let’s just say it’s more complicated than I would like (see #3433). But I’ll work on that before here on this ticket.

[Kissaki]

I agree that we should "just" release "something". We have to move forward. Even if that means sacrificing some quality or higher risk or missing out some stuff.

[Kissaki]

Just to throw this out here as well: Releasing may be problematic atm though, as part of our build infrastructure is missing, and the developer that hosts them is MIA. We can't use the previous workflow and are missing the binary signing certificate AFAIK. That will have to be worked out as well.

[stikonas]

@Kissaki Does this prevent automatic upgrades from 1.2 (if so then it's more problematic)? Or is it just for GPG signing files, so that people can check if they want.

[Kissaki]

Windows verifies downloaded file signatures. When introducing a new certificate, Windows will deem the file "not safe" until it has some numbers of trusted installs, has seen the signature a few times.

We briefly had this when switching from our previous cert to the current one.

Other than that, introducing a new certificate is not technically a problem.

[marado]

@Kissaki It at time of release the missing certificates are still an issue, maybe we could have 1.3.0 released for the other OSes, but delay the Windows release a bit longer? After all (if I understand correctly) the biggest urgency for 1.3.0 comes from Qt's EOL, and that isn't such an urgent issue on Windows...

[Kissaki]

Yeah, I agree. That would be viable.

As we are technically backwards compatible, using older clients with newer servers is not an issue either.

[hacst]

Before considering not releasing the new version for the platform the vast majority of the users are on we might want to try more active methods of raising said developer. E.g. actually email him or sth. ;)

[hfox]

If there's still problems with this, I'd like to see 1.3.0 released for non-windowses ASAP.

[funkydude]

Mumble is dead, stop beating the poor horse. It served us well, but everything dies eventually. I warned this would happen at least 10 times over the past 5 years, but I'm not here to say I told you so.

WebRTC is the future, if you don't like that, tough luck. We already have 2 great and popular clients that implement both security and ease of use well (Slack & Discord). Skype has moved to WebRTC, virtually every phone app is implementing calling via WebRTC. You can even find free to use web platforms such as https://meet.jit.si/ (yes, even the old "skype alternative" is now using WebRTC)

Let this die. If you're obsessed with having something fully OSS or self hosted, make a new project based on WebRTC, you could easily and quickly whip something up using Electron for the client, and work on the server side of things for people who basically want a "self hosted Discord".

Alas this advice will probably be ignored/yelled at as my previous warnings were but perhaps someone with a passion will read this and be interested in pursuing such a goal. It is literally the ONLY advantage you could use as a selling point over Discord - privacy.

[reelsense]

@funkydude You are mistaken.

@Kissaki Could you soft-launch the Windows binary signed with the new key? Let all the people in the know install it to try and get the signature recognized?

[funkydude]

@reelsense Haha, déjà vu Give it another 2-3 years and we'll see the download stats, if it even exists.

[LEW21]

@funkydude There is Mattermost, and I hope it will add voice support soon.

[main--]

@funkydude Isn't it a bit hypocritical to decry anything that isn't WebRTC as outdated, dead even, while you're still here using IRC which is literally 30 years old and also threatened by newer web-based solutions?

[VwieVendetta]

WebRTC? You mean that protocol which still features IP leaks?

Slack and Discord? Just a bunch of average proprietary messengers lacking security/privacy. Here's a list with dozens of messengers and you'll immediately notice that neither Slack nor Discord are secure or special in any way: https://docs.google.com/spreadsheets/d/1A3xz8NFWjebuMbGWvy2yUBKcnAmuZSs5JmKq9-JDss8/edit#gid=140745845 (I know it's ugly, but secured.fyi is getting a facelift right now)

Slack The crypto-messenger Wire - recommended by Snowden - portrays Slack's shortcomings in a small table: https://wire.com/ Slack is definitely not suited for professionals.

Discord Just another one of Jason Citron's schemes. It's amazing people still fall for his money making methods. Asphyxia from r4p3.net has taken a closer look at Citron and his past business practices: https://linustechtips.com/main/topic/586044-why-discord-sucks/

Discord is nothing more than a badly programmed messenger for children who are not tech-savvy. You can't tell me the childish texts, the GUI and the lack of customization are geared towards adults or power users. Besides, Discord doesn't protect your privacy in any way. Everything is saved openly forever on their servers and the data can be searched with ElasticSearch. I do admit that Discord is popular among hackers: https://www.symantec.com/connect/blogs/attackers-use-discord-voip-chat-servers-host-nanocore-njrat-spyrat Causing damage has never been so easy.

Did I mention that Discord is unusable every couple of weeks due to server problems? That happens when you're making yourself a slave of a greedy corporation with a centralized platform. In order protect the sensible Discord users, they censor inappropriate content. Now they even want to use machine learning in order to get rid of "potentially harmful" pictures. In a time in which censorship and fascism arise, the future lies in decentralized (HubZilla, Mumble etc.) or even distributed (Ring, Tox etc.) platforms.

Mumble is not a universal messenger and doesn't want to be. It's the messenger for smart gamers which need lowest possible latency, excellent scalability and minimal resource usage. There are several reason why the big EVE guilds with 1000+ members are using Mumble: it's lightweight (powerful and performant C++ + Qt instead of Discord's slow and bloated JS + Electron), much more secure (perfect forward secrecy) and features lower latency as well as better audio quality than the competition. Did I mention the fact that Mumble is perfectly geared towards guilds? You can link channels and create a fine command over several hierarchies. Besides, Mumble is free, open source, can be improved with plugins, bots and themes and it features positional audio which increases immersion. Now those are killer features Discord can't compare with. Murmurd even runs well on a weak Raspberry Pi 3.

Mumble is here to stay if no serious competition arises. I'm going to laugh so hard at the Discord kiddies when the investors (for example infamous Time Warner) want to see cash. Discord still hasn't any business plan and some stickers or Nitro (who pays money to be robbed and to get access to basic features good messengers offer for free?) just won't cut it.

[ALRBP]

Well. Discord is working perfectly fine on my Gentoo system. When I installed Mumble, the Push-to-talk (mandatory for me) was not working and now, Mumble is planed to be removed from Gentoo due to it depending on long time deprecated Qt4 (it was the last blocker for Qt4 removal on my KDE Gentoo system). Discord may be proprietary (at least they are using Opus) but it seems that it is presently more Linux-friendly than Mumble! I can't tell my co-players to use Mumble instead of Discord because FOSS is better if Mumble actually works much worse on my FOSS Linux OS than Discord! Maybe I should try running the Windows version of Mumble with Wine?! For me, if Mumble is not updated to use Qt5, it will die as it deserves. I can't advocate for an out-of-date software. I am convinced that Discord will reveal itself as a bad choice in the future. The company being it will not provide free server without counterpart forever. But for now, Mumble is not enough actively developed and Discord is working (and privacy is not critical for gaming voice chat ; it is not the same for other applications). I hope either Mumble will be more actively developed or a new FOSS voice chat client-server will be created and ready on time to replace Discord in the future.

[funkydude]

@ALRBP The only real issues with Discord are privacy and centralization (entire regions go down)

There's next to 0 proprietary code in the client, it's a web view using WebRTC via Electron, the bulk would be the server code which we can't read. Him calling it "badly coded" is also laughable when you're talking about running JS and HTML in a sandbox vs Mumble. When was the last time Mumble was audited exactly? Let's best hope that never happens =P

It's also far more secure than Mumble, using superior voice encryption. It will also soon be moving to TLS 1.3 for non-voice, good luck seeing that in Mumble in any reasonable time frame. The current release of Mumble doesn't even implement Forward Secrecy hahaha.

But there's no convincing people that write a post about how they are superior human beings for their software selection whilst at the same time thinking revealing an internal IP address is an issue (welcome to IPv6).

[main--]

Can someone mark all of this as off-topic? It's really not relevant for the 1.3 release.

[Kissaki]

Yes, please keep this on-topic. Not sure how to handle these that have already been posted, but I will remove any off-topic replies that will follow. So put that effort somewhere useful instead.

[Kissaki]

From the issues linked to in comments two and three in this thread, only #2199 is open and critical/important (also labeled critical; see below).

In the 1.3.0 we currently have one blocker, and seven critical.

I think two are mislabeled. They are not critical. I raised that concern in them.

We should take a look at PR #1765, which mkrautz raised issues for final fixup before merge. So finishing that up should be fairly simple/reasonable.

We should check on #2865 #2199 #1679. I’d like to at least evaluate these before tackling a release.

[Kissaki]

For #2199 changes were made, but the issue was not reproducible in old or new version, so we are still missing a test case. But nobody else reported it since. So not a blocker.