[Wiki merge] Upgrade of dataentries

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
    
  • Firmware OpenWrt Install URL_urls  / Firmware OpenWrt Upgrade URL_urls
    Firmware OpenWrt snapshot Install URL_urls  / Firmware OpenWrt snapshot Upgrade URL_urls
    

    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 :wink:

    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)
  • Update "the real" dataentries on openwrt.org
  • Adjust datatables to new datafield naming

Not that much interest in the dataentries...

Anyway... for those interested:

  • 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):

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.

1 Like

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.

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

  2. 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.)

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

  4. Typo: on http://tmomas.spdns.org:25080/unsupported/dsl_modem s/DLS/DSL/

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

Thanks!

Rich

Thanks for your feedback! :slight_smile:

Done!

To me, the lower-left button is something different than the bottom button:
grafik

Done!

Typo: Done!

You used the right wording: It's an experiment. No idea how far we will get with this, but it's a step in - I think - the right direction: modularity.

AHAH! I finally understand why you have not implemented my wise suggestion :slight_smile: 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)

Done, dataentries are upgraded now. Yay! :slight_smile:

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.

Excellent! A few random thoughts:

  1. Do we need to publicize this? Or should we keep our powder dry for a more wide announcement of dataentry/device page facilities?

  2. I have totally lost track of the state of wifi drivers. You might ask eduperez for advice on this - https://github.com/eduperez/mwlwifi_LEDE or (@) eduperez

  3. 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/
    
  4. 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.)

Thanks.

  1. 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.
  2. Good idea! @eduperez Can you think of anything to be added to https://openwrt.org/docs/driver.wlan/mwlwifi , in order to make it better describe the support status, capabilities and functional restrictions (if any) of the mwlwifi wifi driver? Would be great if you could crosscheck https://openwrt.org/toh/views/toh_admin_wlandriver?dataflt[WLAN+driver_wlan-drivers*~]=mwl for correct assignment of the WLAN drivers.
  3. Thanks for letting me know! I made this one mistake that is hunting me now...(damn 's') :slight_smile:
  4. Yes, that was me. I temporarily set the hwdata: namespace to read only for the upgrade.

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.

I can do that myself, if you agree with it.

Sure, go ahead! Your help is much appreciated!

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.

tmomas mohl by jsi mi dát svůj email nerad bych pral špinavé prádlo na veřejnosti můj je czjaromir@gmail.com

This topic was automatically closed 10 hours after the last reply. New replies are no longer allowed.