Toggle quote (141 lines)
> Hi jgart,
>
> Am Sonntag, den 18.04.2021, 17:25 +0000 schrieb jgart:
>
>> Hi Leo,
>>
>> I know you mean this somewhat jokingly, but is there anything
>> (apart
>> maybe from the name of the binary), that would keep you from
>> reusing
>> murmur-service-type?
>>
>> See here:
>>
>> https://github.com/mumble-voip/grumble/issues/21
>> https://github.com/mumble-voip/grumble/pull/26
>>
>> There are more sources related to the grumble config that's currently
>> implemented that I can't locate at the moment.
>>
>> I remember reading that they didn't necessarily want to maintain
>> feature parity with the grumble config format.
>
> That's… disappointing.
>
>> 1. Is this package in its current state usable?
>>
>> I would say yes. We packaged grumble while talking over grumble. It
>> feels pretty solid.
>>
>> Grumble also has an active fork as a library and being used by wahay:
>> https://wahay.org
>>
>> It is currently 16 commits ahead of upstream:
>>
>> https://github.com/digitalautonomy/grumble
>
> This doesn't really look active to me either. It appears as though
> they diverged at some point and simultaneously came to a halt. Now
> wahay is still active, but that's a different beast.
>
>> 2. Is it still maintained upstream? It is a little stretch to say
>> Grumble is undergoing active development after a year of no
>> activity.
>>
>> It sounds like the project maintainers of the upstream grumble
>> project are very slow to review pull requests. It sounds like they
>> are too busy with other projects/work.
>>
>> See the complaint here by one of the contributors that chimed in when
>> I opened an issue:
>>
>> https://github.com/mumble-voip/grumble/issues/76
>
> I take that as a "Maybe, but actually no".
>
>> 3. https://github.com/mumble-voip/grumble#project-statuslists quite
>> a
>> few features that are lacking, but does it maybe contain features,
>> that
>> would make it worth packaging?
>>
>> See https://github.com/mumble-voip/grumble/issues/76
>>
>> "... 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."
>
> W.r.t. ease-of-use I don't think it should be too difficult to get
> murmur + certbot working in Guix. All I can recall from the Debian
> (yeah, I know) server, that I currently run murmur on, is that you need
> to get your hook for restarting murmur right.
>
>> If the answer is "no" to any of the above, I'm not too sure whether
>> it
>> would be wise to have this in Guix upstream. If LibreMiami wanted
>> to
>> host grumble instances on Guix regardless, perhaps a channel might
>> be a
>> better fit?
>>
>> We can put this in a LibreMiami channel with a service for it if you
>> insist it not be included in upstream guix.
>
> It is not so much me insisting rather than me thinking, that channels
> fit such "niche" uses better. As far as I can tell, Guix tries to make
> system services as secure as possible and having a service with glaring
> security flaws is not really a good fit in that scenario. See also the
> recent removal of mongodb.
>
>> If upstream grumble picks up development then I can send a patch
>> again for review.
>
> Please do so.
>
>> That said, can you take the patch for go-github-com-gorilla-
>> websocket?
>>
>> We will need go-github-com-gorilla-websocket for many other packages
>> that we're working on. One of them being the hugo static site
>> generator that we're working on with Ryan Prior.
>
> While the package description itself LGTM, the patch inadvertently
> version bumps some Go protobuf package. If it's okay with you and
> Ryan, I think the better solution would be to send a clean patch along
> with hugo or perhaps separately.
>
>> Relatedly, we're planning on packaging wahay (https://wahay.org).
>>
>> wahay depends on the fork of grumble that I linked above.
>>
>> Should we package only the fork of grumble in that case and not
>> upstream grumble?
>
> Again, since wahay has no public release and LibreMiami might want to
> tail upstream, I think that this would be a better fit outside of Guix.
> As for the differences in their versions of grumble, I honestly don't
> know what to do. Guix usually tries not to vendor packages and this
> might mean using upstream grumble for wahay, but the grumble fork might
> also implement features, that are necessary for wahay.
>
> This is just my personal opinion, but right now Guix seems to have
> about 70 "no release" comments, some of which are actually "no release
> since". I don't think there's a reason to bump this number unless the
> developer has a good reason not to assign version numbers (other than
> "it's not ready yet", which is a perfect reason not to assign version
> numbers, but also a perfect reason to refrain from packaging it), which
> does not seem to hold here.
>
> Regards,
> Leo