Deprecation: Rework "isDeprecated"

[margau]

The decision if an device is deprecated need major rework.
Currently, it's based on a simple list - maybe it should be extended by Regex, and needs more verification.

[maurerle]

I think that the current list does not miss anything and includes all devices since 2594f03

I think it can be closed therefore?

[MyIgel]

We could close it but imho being able to create an "easier" list might be eventually beneficial too?

[maurerle]

It is currently possible to extend or modify the list in the config.json.

A possible move to a more unified direction would be to generate a single source of truth for support status as discussed here:
freifunkh/ffh-packages#7
which is worth a visit: https://github.com/freifunkh/ffh-packages/tree/ffh-support-status/ffh-support-status

In either case, a central source of truth is needed.
Possibly generated from the json data from openwrt:
freifunk-darmstadt/gluon-firmware-selector#98

But that still need investigation and a PoC.

My suggestion to this would be something like this:

erDiagram
    FIRMWARE_BUILD ||--|{ GLUON-STATE: "creates"
    GLUON-STATE ||--o{ "MESHVIEWER": "is available to"
    GLUON-STATE ||--o{ "FIRMWARE_SELECTOR": "is available to"
    GLUON-STATE ||--o{ "SERVER-API": "is available to"
    ROUTER ||--o{ SERVER-API : queries

Loading

which might cover all use cases.
Of course, this does not respect:

Meshviewer n'acked similar requests with the valid argument, that the meshviewer would only be a data viewer, and not a datasource.

But meshviewer ffm already contains this dataset (which creates a huge benefit).

Next steps into this direction would be:

1. investigate why device names in meshviewer are sometimes different from the image file name or name used by the gluon-firmware selector (which is why device aliases are needed here: https://forum.freifunk.net/t/mithilfe-aufruf-aktuelle-firmware-selector-bilder/23821/4 )
2. investigate how the CONFIG_JSON_ADD_IMAGE_INFO=1 and resulting json can be made available in gluon output (maybe @mwarning can help here..?)
3. move to a devices.json in the gluon-firmware-selector instead of the devices.js based on a unified concept
4. generate support state from a single source of truth based on the latest release of a community.

That escalated quite well, but is probably the most coherent way for the future..?
@AiyionPrime - just mentioning you, as you already spent some time on this as well..?

[maurerle]

If CONFIG_JSON_ADD_IMAGE_INFO=1 is set when building gluon, the profiles.json in openwrt/bin/targets/$TARGET/$SUBTARGET is created.
One can aggregate these into a single file running:
cat $(GLUON_BUILD_DIR)/openwrt/bin/targets/*/*/profiles.json | jq -s > output/images/devices.json
which needs to have jq installed.

This information includes a list of all supported devices, as well as their names for a given build.
This should be postprocessed to be usable as the centralized state, and all devices which are not part of this generated list are not supported (not necessarily because they are outdated)

[mwarning]

hm, I am not sure what this is about. Do you need help to get a list of models from OpenWrt that are not supported anymore?

[maurerle]

Hi @mwarning - this is about a better way to keep track of which devices are currently supported in meshviewer - by looking at the list of devices with available firmware.

As the author of freifunk-darmstadt/gluon-firmware-selector#98 and https://github.com/mwarning/openwrt-firmware-selector/blob/master/misc/collect.py - you seem to have experience with aggregating device data from an openwrt build.
But my last post summarizes how the openwrt CONFIG_JSON_ADD_IMAGE_INFO feature works, so that is clear for me now.

[mwarning]

But every device that would show up in meshviewer would be "supported" by the freifunk community - is that not? Or are you looking for a finer differentiation? Anyway, feel free to ignore me :)

[maurerle]

@mwarning sorry for actually ignoring you :D
If you create the json from the latest release (e.g. v2023.1) but still have 4/32, they will not be part of the json from the latest build anymore - as they are unsupported.
So are experimental builds, for new devices which are not part of stable.

So everything, which has a "stable" firmware available is "supported".
But to have a current list of supported devices per build/release, we could use the JSON which is provided by the flag CONFIG_JSON_ADD_IMAGE_INFO

One can even join the jsons per target/subtarget together with cat $(GLUON_BUILD_DIR)/openwrt/bin/targets/*/*/profiles.json | jq -s > output/devices.json - but I did not get any further yet.