I've been adding things to that page, I noticed we have a few package arcs that are not used by any target.
I removed their entries when jow confirmed that they are indeed useless and will be purged from the download page here
Looking at the full view, at the end are "Firmware LEDE Install URL" and "Firmware LEDE Upgrade URL".
Currently there is only trunk and the url points to the snapshots folder. Eventually (soon?) there will be a stable release. Do we need 2 more fields and add some text "Trunk" and "Stable" (or similar) to the descriptions?
Do you have a plan around the future of the OpenWrt fields and contents? Long term does it make more sense to add a field and link to the device or techdata page at OpenWrt.
In the past the directive was: Show the stable version in the firmware download fields. Only if no stable version exists, use trunk instead.
No plans. For now, they are there and didn't cost anything 
If they stay in the dataentries, they need to be updated... hm... extra workload.
I wouldn't mind throwing them out.
That's already available: https://wiki.lede-project.org/toh/views/toh_available_864
I updated the dataentries:
- subtargets added as far as possible
- LEDE firmware download urls corrected as far as possible (some targets do not exist in LEDE, some moved to different subtargets, ...)
Please take a look at https://wiki.lede-project.org/toh/views/toh_fwdownload2
Please check for correctness: Subtarget, LEDE instructionset, Firmware LEDE Install URL, Firmware LEDE Upgrade URL. Should you spot any errors, please let me know.
Dugh, I knew that, sorry.
There are some targets coming from OpenWrt that are not in jow's list
avr32
atheros
cns21xx
cobalt
orion
There are some tagets on jows list that appear to not have devices
malta (4 sub-targets and only 1 device)
mediatek\generic (none)
apm821xx (none)
au1000/au1550 (none)
gemini (2 subtargets and only 1 device)
There are about 60 devices with no targets, so there still may be a need for these.
I am struggling with the "Platform" field. It seems like a level at or below target\sub-target. I was looking for a wiki page and found your ToDo list with the note to change it to CPU.
I am concerned this is a free form field in the dataentry form. The current values do not match the OpenWrt platform list (exactly). If it's selection worthy, does it make sense to split off the brand?
Are these values some how tied to the build process?
I updated https://wiki.lede-project.org/templates:template_dataentry to the latest status (=the status of the imported OpenWrt dataentries).
I also updated https://wiki.lede-project.org/meta/create_new_dataentry_page
Feel free to create new dataentries as you like (they will be lost after the tryout period, though).
After creation, edit the dataentry via the LEFT edit button below the dataentry box to see the editor with all datafields.
Please review the dataentries as described in the first posting. Special attention should be paid to some newly introduced datafields, and there especially at the dropdown values:
Dropdown review needed
- CPU Cores
- Installation method <---- I added basic ones; new ones welcome! let's play around with this for some time and see if it is useful.
- LEDE Instructionset <--- Is this the right naming for this field? @jow called it "Package arch".
- Packages download (=LEDE Instructionset + "|Download")
- Serial connection parameters <--- what other common parameters like 115200 8N1 are needed?
- GPIOs
Comment review needed
Take a look at the rightmost column, the "Comment" column. This column provides basic help on what is expected in the datafileds. Datafields which need some input here are marked with "--------> Description goes here". Any help is welcome!
Note to self: "Flash MB" is currently unusable (too small) -> to be improved via CSS
LEDE Instructionset <--- Is this the right naming for this field? @jow called it "Package arch"
IMHO it is better Package arch/architecture, as that is more an architecture thing, also "architecture" is more well-known.
"instructionset" is just some of the features of an architecture/ISA. 32bit or 64bit are instructionsets of x86 architecture for example.
EDIT: but it is also true that tere are quite a bit "package architectures" that are the same actual achitecture with different instruction sets enabled (like say NEON or VFP)
Thanks for your feedback. The "instructionset" was a leftover from the OpenWrt wiki.
Changed it now to "Package architecture"; dataentries + datatables updated accordingly.
Regarding dropdown "LEDE Supported Current Rel"
How do we express the current LEDE support status?
Available dropdown values (made up by me): "-, 16.12, 17.06, 17.12, snapshot"
Could also be "Pre-Release" or something like that.
Anything will be better than the current status, i.e. nothing shown in the dataentries.
Your input, thoughts and comments please.
[quote="tmomas, post:31, topic:48, full:true"]
Regarding dropdown "LEDE Supported Current Rel"
How do we express the current LEDE support status?[/quote]I'd rename it to "last supported release", and use it to show the last release LEDE has for the device.
For most devices it will have to be mass-edited each LEDE release to change the number, discontinued devices will keep the last LEDE version supporting that device.
I think this is how OpenWRT field with the same name was supposed to work.
Regarding field "LEDE Unsupported"
As a first shot, can I set 'LEDE Unsupported=OpenWrt Unsupported' ?
[quote="tmomas, post:33, topic:48, full:true"]
Regarding field "LEDE Unsupported"
As a first shot, can I set 'LEDE Unsupported=OpenWrt Unsupported' ?
[/quote]yeah, it seems to list unsupported hardware of the device, it's likely the same.
Silly me: I declared some styles too generally. Making them more specific solved this problem, and besides that, also the problem of the edit summary extending into the "Minor edit" checkbox.
To do:
In the Next router? ath10k or mwlwifi based? something else? thread, @hnyman noticed that there's no entry in the LEDE ToH for the Netgear R7800, despite the fact that there's a nice juicy build for it in LEDE. (I didn't see it in the OpenWrt ToH, either.)
As we approach a final ToH, we need to find a way to ensure that the set of router detail/dataentry pages matches the actual set of binaries.
[quote="richb-hanover, post:36, topic:48"]
@hnyman noticed that there's no entry in the LEDE ToH for the Netgear R7800, despite the fact that there's a nice juicy build for it in LEDE. (I didn't see it in the OpenWrt ToH, either.)
[/quote]And that is the reason why it is not in LEDE ToH, either. The device it not supported by Openwrt, as it has been added later, only for LEDE.
As long as all device data here is deleted regularly and "master data" is imported from Openwrt, the device will not exist here. I have created R7800 twice here, so far, but it has been deleted since then. I can create that device again, after the final import has been done and it won't get deleted any more.
I do not think that there is any perfect way to automatically check for devices to be added and devices to be removed. Using e.g. snapshot download dirs as the reference point is risky as that would make the last buildbot run as the reference point. And there are deviations between build runs (due to new errors breaking a device etc.)
But there could be a script comparing/listing the contents of the snapshot download dirs for firmwares. Only the changes to the previous similar list would need to be checked. But that will require some manual checking in any case.
I think that removal needs always human eyes for checking.
The same for adding, as a device may just be a country variant of an existing one. Or something like that.
Oh dear... I know @tmomas has been experimenting with the best way to import the OpenWrt data with the best formatting possible. Sorry that your R7800 data got overwritten by subsequent imports.
My intent with this "to do" item was to remind ourselves that the OpenWrt data is not complete, and find a way to add in new devices that are LEDE-only. Perhaps (once we do the final import) we can have an announcement to solicit the LEDE-only devices be added. That would be your cue that it's safe to add (for one final time) info about the R7800. Thanks.
You can expect the "final" to happen between 30.11. ...18.12.2016.
[quote="hnyman, post:37, topic:48, full:true"]I do not think that there is any perfect way to automatically check for devices to be added and devices to be removed.[/quote]GIthub allows to use wget to download only makefiles (or any other file in the source, as long as you have it's folder tree), you can then parse them with a script if needed.
I'm using that for my ToP script to read CATEGORY and SUBMENU entries that are of course missing from package lists.