Brokenness of the OpenWrt "packages" repo
ericluehrsen at gmail.com
Tue Apr 27 06:45:23 BST 2021
On 4/26/21 3:58 PM, Alberto Bursi wrote:
> On 26/04/21 16:01, Daniel Golle wrote:
>> On Mon, Apr 26, 2021 at 03:28:22PM +0200, Enrico Mioso wrote:
>>> ... I know you won't like this. But in the end, I guess D-Bus, glib2
>>> and in the end all of MM dependencies will have to be incorporated in
>>> the core.
>>> A stac, of big big software, I know. But supporting 4G/5G in the end
>>> will required that.
>> ModemManager is not the only way to use 4G/5G modems. You can use
>> umbim or uqmi for most tasks.
> In my experience their ability to handle device-specific bugs or "perks"
> is limited, unless your modem is 100% perfect and never crashes ever and
> can actually handle the autoreconnect on its own, you will end up in
> situations where you need to just set up a script that pings Google and
> reboots the router if network fails.
> They also don's support a lot of new LTE features like band lock, band
> aggregation and more, they are way too simple. I have bought a consumer
> modem/router that is like 3 times faster while using the same type of
> CAT6 modem due to band aggregation and the reconnect sequence if the
> connection drops is very fast because I have set the only 2 LTE bands it
> can use.
> MM is so much better than that. But my main issue with MM is that both
> maintainers (package and upstream MM maintainers) have not found a way
> to integrate it well enough with OpenWrt's internals so that when the
> modem disconnects there is nothing that notices this issue and nothing
> that reacts to it. So I had to cobble together a script to do this
> missing link, but it's far from a decent solution. (see the issue thread
> I opened about this)
> Hence why I eventually bought an actual self-contained modem with web
> interface and all, it's just so much better speed and is less painful to
> Both projects are straight forward, well
>> documented code, easy to extend in case you miss anything.
>> Depending on half of the Freedesktop universe in order to initialize
>> a network interface or receive an SMS in a very complicated way doesn't
>> feel justified to me.
>>> On Mon, 26 Apr 2021, Bjørn Mork wrote:
>>>> Date: Mon, 26 Apr 2021 07:51:51
>>>> From: Bjørn Mork <bjorn at mork.no>
>>>> To: Etienne Champetier <champetier.etienne at gmail.com>
>>>> Cc: Rosen Penev <rosenp at gmail.com>,
>>>> OpenWrt Development List <openwrt-devel at lists.openwrt.org>
>>>> Subject: Re: Brokenness of the OpenWrt "packages" repo
>>>> Etienne Champetier <champetier.etienne at gmail.com> writes:
>>>>> Are you trying at the same time to complain about not run-tested
>>>>> updates and possibly having packages not up to date ?
>>>> No. The package was fine before the version was changed. In fact, it
>>>> was in much better shape before it was changed to a development version
>>>> by the very same non-maintainer.
>>>> If you don't care enough to even install the package, then please don't
>>>> touch the package.
>>>>> I would personally mark it as broken or remove it instead of making it
>>>>> work again, but it means removing some other packages.
>>>> I'd be all for that, if you apply that rule to all the unmaintained
>>>> packages in the repo. It's a much better solution than having the repo
>>>> full of arbitrary untested changes to unmaintained packages.
>>>> Wrt dbus I'm pretty sure it would provoke an adoption. There are
>>>> multiple packages depending on it, and as the immediate reports tell
>>>> you: This particualr umaintained package is in active use.
I feel this with a lighter tone, but I philosophically agree with Bjorn.
Here is an example of enforcement concerns. I am an active maintainer. I
have a day job and all, but I do get to at least commenting on PR once a
week. Here committer and merger where separate individuals. The
maintainer wasn't contacted. Neither participant is even a user of
Unbound, self-stated in PR, or tested the work. I realize the change was
trivial, and that is not my point. An automated test-hook could have
checked if the maintainer commented or the maintainer was AWOL before
marking the PR ready. Trivial or complex, maintainers need to be in the
loop or we lose continuity in quality and we discourage their "feeling
of ownership" when we bypass them.
More information about the openwrt-devel