Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecation: Rework "isDeprecated" #2

Open
margau opened this issue Apr 12, 2020 · 8 comments
Open

Deprecation: Rework "isDeprecated" #2

margau opened this issue Apr 12, 2020 · 8 comments

Comments

@margau
Copy link

margau commented Apr 12, 2020

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
Copy link
Member

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

I think it can be closed therefore?

@MyIgel
Copy link
Member

MyIgel commented Sep 10, 2023

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

@maurerle
Copy link
Member

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
Copy link
Member

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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link
Member

maurerle commented Oct 8, 2023

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants