Packaging grumble for Guix System: State of grumble / Releases

[jgarte]

Hi grumble devs! @mkrautz @actown @davidebeatrici @pcgod @rubenseyer @GrimKriegor ...

I wanted to inquire on the state of grumble development. I ask because we packaged grumble for guix system and one of the upstream maintainers had the following questions for us (original mailing list discussion where we submitted the patch):

1. Are there plans for a release?

2. Is grumble usable in its current state?

3. Is it worth packaging grumble with the features that it currently has?

4. Is grumble still maintained?

I appreciate your work on grumble and I am looking forward to your responses.

[rubenseyer]

I'm not sure I merit the label of developer, but since you asked for my opinion explicitly...

1. I am not the right person to conclusively answer this. But I will guess it is unlikely.
2. Sure, for small workloads like talking with a few friends it should have all the necessary features. But for large server hosts Grumble is not feature-complete: from critical issues (ACLs are broken, I have a PR open since June 2020) to must-haves (most large admins use RPC in some way. Right now configuration is a hex editor, I have a PR open since 2018 but this is a design decision as well) and minor features (bandwidth limiting would be nice for a public server, but that is a week-end patch).
3. Only your distribution can answer such a question based on their packaging policies (and I suppose that is what they are trying to decide by these questions). Grumble does have features distinguishing it from Murmur (see below).
4. In my opinion, no. We haven't had activity on HEAD for a year, both feature and fix PRs lay dormant, lots of issues unanswered... Also, there have been some security considerations raised about the UDP voice cipher (look in the Murmur repo for info about OCB2 issues) that also need a mitigation patch. Anyway, Grumble's relative inactivity was obvious even several years ago, but even if I forked and merged all my changes I am not interested in sole maintainership. Active projects are more fun to work on and over the years my time budget has fluctuated, and although I still like Grumble I can't sit around waiting for my PRs.

As an elaboration on point 3, Grumble has the distinguishing feature of native support for Websockets (because I was a lot worse at C++ back then and so I contributed a patch here instead), and Murmur will probably not have that for the foreseeable future. You could of course just configure a proxy in front of Murmur if you need this. A lot of the plans for work we were making a few years ago pointed towards Grumble being more focused on ease-of-use and these small workloads I talked about above. It makes sense: the Murmur static binary has issues and so a Grumble static (just how Go works) binary that you can download and run, trivially configure and easily negotiate certs over LE (unfortunately never happened due to LE issues, but it would be viable now), accessible over the Web could fulfil a sort of "batteries-included" user-friendly niche.

[jgarte]

Hi @rubenseyer

Sorry for the delay. I appreciate your thorough and informative response.

I mentioned your points to upstream guix and they replied.

I'm going to move the grumble package into a custom guix channel and create a variant of it for the fork made by digitalautonomy. The guix channel will be hosted in a git repo by LibreMiami at this sourcehut page (TBD).

digitalautonomy re-packages grumble as a library for use in wahay.

@rubenseyer Have you considered contributing to wahay?

If upstream grumble development picks up I'd be happy to write a guix service for grumble so that it can be easily deployed by guix system.

For now, we'll concentrate our efforts on supporting wahay with a guix service for easy deployment.

Because wahay is still under active development it is not yet acceptable for upstream guix and therefore, the need for a pre-release channel.