Due to the wiki merge, the dataentries and datatables need to be updated.
Several tasks on the to do list are already done. Apart from small changes like adding multi-value capabilities for some datafields and changing download urls from https -> http, I added several new datafields.
Added datafields
Where available : # website without http... and no deep link, just the website, eg. amazon.com. List multiple values comma separated.
Currently the “where” is added only in the change summary. Having a dedicated field for this might help to find a device for purchase more easily out there in the wild.
Seeing where a device is available backs up the naked “Available 2018” and makes it easier to understand why the Available status has been set.
Supported Current Rel : 17.01.4 # Current official release
Current dataentries contain OWrt + LEDE supported current release. With going back to OpenWrt, we don’t need to distinguish any more -> “neutral” Supported current release field i/o LEDE/OpenWrt specific. Old LEDE/OWrt specific fields are still in for checking purposes, but will be deleted for final dataentry.
WLAN driver_wlan_drivers : ath9k # CTRL+click for multiselect
Click on e.g. “ath9k” leads to separate page about the driver, where we can put info regarding support status. These separate pages should give some more information than “WiFi 5GHz not supported”.
Not sure if this should be a single value only field, or if multiple selections are needed -> Your feedback is needed: Which devices need more than a single wlan driver and which drivers would that be?
Currently this field is prefilled based on info from https://wireless.wiki.kernel.org/en/users/drivers -> currently not 100% correct, many “unknown” values. -> You can help to fill this field correctly.
Do you think this is usefull? Please let me know your thoughts on this.
Forum search_search-forum : DIR-505 # url to search for latest forum postings related to this device
Git search_search-git : DIR-505 # url to search for latest git commits related to this device
Forum + git search are experimental. Datafield contains only the search-term (e.g. DIR-505), complete URL will be done by dokuwiki.
Click on Forum search and you will be taken directly to the forum search results. Question: Can this replace the current forum links?
Click on Git search and you will see the latest git commits specific for the device
Do you think this is usefull? Please let me know your thoughts on this.
Datafields for snapshot images added: Some snapshot images were renamed recently or have been moved to new subtarget “tiny”. Since the user can no longer conclude the name of the snapshot image from the existing release image, snapshot images should be mentioned in the dataentry. This also helps me keeping track of such image name changes, which occur in snapshots, but are visible in the releases only with the next stable release (we know that there might be considerable time between implementation in snapshot and implementation in stable releases).
Do you think this is usefull? Please let me know your thoughts on this.
Firmware OWrt snapshot Install URL_urls : # downloads.openwrt.org/snapshots/targets/...factory.bin; If more than 1 file for install/upgrade -> link to download *folder* instead of image
Firmware OWrt snapshot Upgrade URL_urls : # downloads.openwrt.org/snapshots/targets/...sysupgrade.bin; If more than 1 file for install/upgrade -> link to download *folder* instead of image
Firmware LEDE snapshot Install URL_urls : # downloads.lede-project.org/snapshots/targets/...; If more than 1 file for install/upgrade -> link to download *folder* instead of image
Firmware LEDE snapshot Upgrade URL_urls : # downloads.lede-project.org/snapshots/targets/...; If more than 1 file for install/upgrade -> link to download *folder* instead of image
Same as above with “Supported current release”: Current dataentries contain OWrt + LEDE download URLs. With going back to OpenWrt, we don’t need to distinguish any more -> “neutral” field i/o LEDE/OpenWrt specific. Old LEDE/OWrt specific fields are still in for checking purposes, but will be deleted for final dataentry.
Installation / recovery methods: Another attempt to implement these fields (I don’t want to force them into the dataentries, but thinking of modularity, it’s just too tempting to not try it
Installation method(s)_method-installations : # CTRL+click for multiselect
Comment installation : # SHORT (!) comments like "rename image to 'firmware.bin' before flashing."
Recovery method(s)_method-recoverys : # CTRL+click for multiselect
Comment recovery : # SHORT (!) comments like "rename image to 'firmware.bin' before tftp'ing."
Thought behind this proposal: Not each and every device has its very own unique installation prcedure, but shares the procedure with a number of other devices (e.g. TP-Link almost always have TFTP as installation option; almost always D-Link devices have the D-Link Recovery mode) -> no need to explain the same installation instructions again and again.
Dropdown list would contain all available installation methods; selected value would then lead to separate page explaining the selected installation / recovery method. Do you think this is usefull? Please let me know your thoughts on this.
Deleted datafields
Packages download_pkg-dl : # https://openwrt.org/docs/instructionset
Basically the same information as in “Package architecture”, but labeled as “Download”.
I would like to get rid of this double information, hence deleting it. Please let me know your thoughts on this.
Next steps
Script for new dataentry creation: Solve issues with wrong keyfields being generated (should be ready tomorrow)
Get forum feedback on added datafields
Finalize script + let it do its job in the demowiki (Sneak preview available on request)
Access to Demowiki for anybody interested in this topic -> see links below
Added fields
Where available (set to ¿ for Devices with status “Available“, empty for all others)
Forum search
Git search
WLAN driver
Snapshot image URLs
Installation method + Comment
Recovery method + Comment
New functionality
“Unsupported” now links to pages explaining the unsupported status, making it crystal clear what is unsupported and why, what the concequences are and what $user can do about it.
WLAN driver links to pages explaining support status of WLAN drivers @slh that's where I count on your knowledge (from what I see here in the forum I guess you have quite some in this regard)
WLAN driver values to be reviewed by community for correctness
WLAN driver pages to be reviewed by community for correctness + to be filled with life
Forum search: Click on link and you will be taken to the search of the LEDE forum
Content of this field has been filled with simply the model name and certainly needs to be reviewed to get good results for all devices
Git search: Click on link and you will be taken to the git search, in order to see the commits for a specific device
Content of this field has been filled with simply the model name and certainly needs to be reviewed to get good results for all devices
Data updates
Supported Since release updated if pre-LEDE support exists
Supported Current release updated if pre-LEDE support exists, but no LEDE support existent @richb-hanover this should be of interest for you, I think.
Download links updated accordingly
Download links changed from https -> http
Availability: Several devices with unclear availability (e.g. Available 2016?) moved to unknown 2018
Links to demowiki (please be patient while pages are loading):
http://tmomas.spdns.org:25080/toh/views/toh_admin_lede_owrt_support : All support information we have, i.e. from 0.9 up to 17.01.4, including download links. Sorted by "unsupported", so you can easily see all of the "unsupporteds".
Please check if you spot any mistakes in Supported Since, Supported Current and Firmware OWrt/LEDE/Openwrt [install|upgrade] download links (OWrt = old OpenWrt; OpenWrt = new OpenWrt)
If there is no negative feedback or other change requests, I will implement the new dataentries soonish (during the weekend or so).
After implementation of the new dataentries, the datatables (toh:views + on devicepages) will be updated accordingly.
Thank you for all the thought you have put into updating the DataEntry pages. I will also apologize for not having the time to reflect on all this.
In general, all these changes are good. It seems as if you are planning to run a script over all these pages to make changes in a uniform way. If this is so, I offer a few items that could make it better.
Put the ">>>>>>>> W A R N I N G <<<<<<<<" comment right below the NOTOC line, and above the two {{page>meta... lines so it's the first thing (misguided) people see.
I still would like these pages to say "Edit this page only using the Edit button at the bottom of this page" (I never think of that button as being either "left" or "right", but at the bottom. I realize you mean to distinguish it from the "Show/Edit Pagesource" button that lives on the right side of the page.)
I would be tempted to change the heading "Unsupported:" to "Unsupported Function(s)" or "Unsupported Capabilities". Even when I reviewed a DSL modem that I understood, I wasn't sure what the category meant until I puzzled for a while.
I certainly hope the Installation Methods and Recovery Methods are used heavily, to prevent people from repeating the same, slightly incorrect/inconsistent procedures all over the place. This is an experiment worth having, especially if we can curate a few good procedures.
AHAH! I finally understand why you have not implemented my wise suggestion Here's a new suggestion. (I got a million of 'em...)
Let's make both "Edit" buttons go away. We don't need them for the TOC (the page disables it), so we can change ===== Usage ===== to **Usage** (and the same for Dataentry) to get the same visual look without the danger of people discovering the wrong "Edit" button.
PS I really like the Theme dropdown in the prototype/demo wiki. I wonder if it might be better to place at the bottom of the navigation (say, below Contact Us)
I still would appreciate if someone could take a look at the "unknown wifi driver" table: https://openwrt.org/toh/views/toh_admin_wlandriver
If you happen to know what wifi driver to use for a device in this table, either let me know or edit the corresponding dataentry yourself.
The URL on the dataentry page has a typo (s/drivers.wlan/driver.wlan/)
WLAN driver_wlan-drivers : b43 # CTRL+click for multiselect; see https://openwrt.org/docs/drivers.wlan/
Last night, the wiki was not editable, even though I was logged in. Is that because you were making a mass-update? (Not a big deal, and it's good to know that we have the ability to do this on an occasional basis.)
Don't know... do you think we should? There is still some work to be done: The Installation/Recovery method pages need to be written... amongst others.
No, we don't necessarily need to publicize this. I was just checking to see when we might have enough work in place to ask for comments/praise/help. I think the answer is, "Not yet." Thanks.
I would change the page at https://openwrt.org/docs/driver.wlan/mwlwifi to reflect the current status of the drivers (broken features, known bugs, ...) at the latest stable LEDE, latest OpenWrt snapshot, and my own builds. All three are feeding from the same source (https://github.com/kaloz/mwlwifi), so all is needed is to compare commit id's, review the fixes on each commit, and browse open and closed issues.
This would be amazing for all the various wifi drivers. It's hard to figure out what works well and what doesn't. I'd also like to hear which features of make-wifi-fast have been implemented in which drivers.
It would actually be really need for all platforms (wifi, SoC, and full device) to have some sort of semi-automated changelog based on commits. Of course, I have no idea how hard that would be.
@tmomas - great ideas all around. I like the recovery idea, although there are sometimes slight variations among different devices. These could be the result of upgrades or differences in the underlying hardware. They do tend to be similar and I think it's worth the experiment.
May I make one more suggestion - it's sort of silly, but it took me a while to realize that you could actually go directly from the TOH to the device page because the link is in its own column. My brain was expecting the device model or similar to be the link to the device page. If it were possible to do that, I think it would help people coming for the first time.
Ok, actually two suggestions - it may make sense to have the CPU and wifi fields be discrete data instead of free text. Then you can search/sort more reliably by those fields with something like a dropdown menu.
