search

mumble-voip / mumble

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

gRPC (WIP) #4180

Closed toby63 closed 4 years ago

toby63 commented 4 years ago

This issue is intended to summarize the issues & improvements of gRPC. Its also intended to be the first place for discussions about gRPC.

For recent development progress see:

Open Issues with "grpc"-label: https://github.com/mumble-voip/mumble/issues?q=is%3Aopen+is%3Aissue+label%3AgRPC

Related:

Todo (only for this issue):

Krzmbrzl commented 4 years ago

What exactly do we need this for? Given that #3947 basically rewrites gRPC completely I don't even think that collecting the old issues is worth it as they'll probably be irrelevant after the merge. Therefore I think we should look into potential gRPC issues once the new system is in place :thinking:

toby63 commented 4 years ago

@Kissaki asked for it in https://github.com/mumble-voip/mumble/issues/2569#issuecomment-629772284

Kissaki commented 4 years ago

This ticket is non-telling though.

When I look at issues labeled gRPC I want to see what is still open and an issue. It should be obvious why we can not default-enable it from that list of open issues.

Segfaults were mentioned in the referenced issue. So I would expect an issue ticket for segfaults. That may or may not point to current efforts to remedy this or replace these (rework?). But none exists.

Thank you for making the effort to create this ticket, but I do not think it is focused and actionable enough. It basically rewords what is already visible; namely two PRs and linking to the issue label.

I added the gRPC label to the two PRs, which IMO were missing.

I do not think creating a ticket for potential discussion on gRPC is helpful. We can create one once there is something to discuss. And they should be as specific as possible so they stay on-topic rather than talk about multiple areas [of gRPC].

I am not aware of what the issues with the current gRPC implementation are. I was told in the past we can not enable it yet, but I do not remember why, and am not the person with the knowledge in this area. But what I would like to be obvious is why we can not enable it from the list of gRPC tickets.

The somewhat generic title of this ticket is another indicator to me of it’s unclear purpose/focus. At least that’s my impression when I read that as a ticket title.

There may be value in a general planning, discussion or summarization ticket - as in a management ticket. But I am not sure I currently see that. If you created this in preparation for more information then it should be actionable and clear who has to do something and add information here. Because otherwise it will just continue to sit like this, without the information I was looking for (and arguably any significant information).

toby63 commented 4 years ago

@Kissaki Well I am no programmer so I can't really do much. You are free to change the content of this and ask the people involved (especially @McKayJT and @Krzmbrzl ) specific questions. Otherwise I only wanted to add a Feature List, to see what is already possible via gRPC in terms of server management and what is not and what will or should be added.

Besides I don't see so much value in "stealing time" right now from @McKayJT and others working on this, to write a detailed documentation of progress etc. I would simply wait, it seems that there will be results very soon. After that a more detailed summary could be written.

Krzmbrzl commented 4 years ago

I would simply wait, it seems that there will be results very soon.

I agree that atm this seems to be the best alternative.

In principle of course I agree with @Kissaki that existing bug should have an open issue to track them. Creating them in hindsight will probably not worth it though - especially given that there is active work in fixing all/a lot of issues.

Thus I'll close this for now :point_up:

Kissaki commented 4 years ago

to write a detailed documentation of progress etc.

You’re misrepresenting what I asked for. Creating a ticket with a title or list of open issues is not detailed documentation of whatever.

If a PR is created that supposedly fixes issues that issue list would have to be known and documented either way.

At the moment we have code landed in master that is, apparently, not stable, or at least not stable enough to enable it by default. Supposedly there are critical or at least important open issues. But those are undocumented.

If there is active work for fixing issue then we are simply lucky. We and I wanted to default-enable it quite some time ago once it was implemented, and one person mentioned that critical stuff is still open. Again, just lucky that that person knew, read and responded.

Only few people knowing about issues and only knowing these privately is not a good base for managing a project.

toby63 commented 4 years ago

Only few people knowing about issues and only knowing these privately is not a good base for managing a project.

Ok, thats valid, but as you said, those would be put into seperate issues anyway. But to solve the situation, the main question would be, who knows it?