@richbhanover:
- https://dev.openwrt.org/ticket/19842
- https://dev.openwrt.org/ticket/17100

If this re-occurs, re-open one of the tickets.

@zo0ok: You can drop the "Dataentry                   : 8devices_carambola1" line.
This functionality is already provided by "Device Techdata Page_pageid : Techdata". Yes, as weird as it seems: this fixed value setting gives you the dynamic link to the dataentry page. You'll see and feel it soon

@zo0ok: The hwdata doesn't belong there:
"Device Page_page            : .toh:hwdata::d-link:dir-505"

It should be
"Device Page_page            : .toh:d-link:dir-505"
-----
"toh:d-link:dir-505" -> That's where the devicepages go
"toh:hwdata:d-link:dir-505" -> That's where the dataentry pages go

Updated the dataentry template: Added comments (#) -> will be shown when editing the dataentry via the *left* edit-button.

For changes see: http://wiki.openwrt.org/toh/dataentry_t … sidebyside

Edit: @zo0ok: Can you please implement in the datapages:
- {{page>meta:infobox:dataentry_permanote&noheader&nofooter&noeditbtn}} as shown in the template
- the comments (#) shown in the dataentry_template
- the following columns in the datapages
  Instruction Set        : ? (default)
  Sub Instruction Set    : ? (default)
  Bootloader             : ? (default)

The more columns we have in, the better (performance evaluation with many columns).

(Last edited by tmo26 on 13 Jun 2015, 02:29)

@tmo26, guess you are not reading now but anyway: do you want the comments in each and every dataentry, just like in the template?

Yep, just like in the template.
The comments will be shown later when you edit the dataentry.
Not sure if we should do it that way. Right now it's just for testing the look&feel.

BTW: No need to align the #'s, since all spaces between value and # will be automatically deleted anyways.

New version coming up.
- #comments not fixed yet
- @richbhanovers questions/thoughts about picture url or picture urls not implemented. How do we want it?

I have tried to make sensible values to Instruction Set and Sub Instruction Set based on:
a) https://dev.openwrt.org/wiki/platforms
b) The assumption that all devices with the same target also have the same Sub Instruction Set
I have done some research to get the most important (numerous) targets correct.

I have also populated Device Type with a simple best effort algorithm. I think I get most of them right. Some devices are perhaps not clear if they are Single Board Computers or Routers (it depends on the chassis and retail packaging, mainly).

Perhaps I will fix the comments later today.

Single value please. This is thought only for a single general picture to identify the device.
All other detail pictures should go to the devicepage.

Reason: Imagine 12 picture URLs in the Pictures_urls field -> hard to read, hard to edit.

What do you as a user expect when you see an input field named "Vendor device" (no further comments given)?

Some observations I mady while jumping around in the playground (http://wiki.openwrt.org/meta/playground?&#tags):
(numbers for toh taken from zo0oks list)

Serial: We have 127 devices tagged with "serial", but in the toh only 62 devices with a definite "Yes" in the serial column.
-> disconnect of toh and devicepage / tags

USB: 217 tagged USB, 34 tagged USB2.0; toh:198 1x 2.0, 92 2x 2.0, 91 USB YES
-> 34 tagged USB2.0 vs. 290 listed with 2.0 -> tags need to be updated

Flash: 63 tagged 16flash; 113 listed with 16MB flash

RAM: 152 tagged 32ram; 307 listed with 32MB RAM

... and so on.

I'm glad to see that we don't run out of work for the future... :-/

Remark: The

{{searchtags&header&tags&nouser&nodate&table}}

is a nice tool, although a bit bulky in appearance.
At least it counts the pages with all the different tags.

I *love* the comment fields. Thanks for adding those.

re: Picture urls: You're right. There should only be one.

re: Vendor Device: Perhaps it could be "Vendor Page_url" - the hint in the comment will give people the right idea

re: Brand vs Vendor:  You didn't respond to this - I still prefer "Vendor"

A couple other thoughts:

- I always have to think twice when I look at "factory" firmware to decide whether it's "OpenWrt factory" or "Vendor factory (stock)". That's why I proposed that we a) include a link to the vendor's stock firmware, since the dataentry is an organized collection of commonly-referenced information, and then b) make the field names reflect the difference, like this:

Vendor image_url
OpenWrt factory image_url
OpenWrt sysupgrade image_url

- In the default URLs for image files, I would be tempted to elide the interior stuff to show the suffix of the URL (to distinguish between OpenWrt factory and sysupgrade images). For example, https://downloads.openwrt.org/...squashfs-factory.bin and https://downloads.openwrt.org/...squash … pgrade.bin

- In the comments, all URLs might be prefixed with "www." just so that readers understand that it should be a URL (but "http://" not needed

Thanks for all this good work!

I'm a bit hesitant with those. On one hand, they are really usefull. On the other hand, they can not be modularized and have to be present on each dataentry page. We keep them in for tryout.

What about "Vendor's device page" or "OEM website"?

No preference on my side.

Vendor image is mostly referred to as "Stock FW", AFAIK.

Should be doable (see https://forum.openwrt.org/viewtopic.php … #p272662), however, not by myself, I'm no CSS guy.

Great!

Those are good suggestions. I would lean toward a combination of both - "Vendor website_url", that goes next to "Vendor image_url"

Let's use "Vendor" instead of "Brand"

I think we should use the same word for firmware/image everyplace we can, to minimize confusion. "Vendor image_url" or "Vendor Firmware_url" would be fine with me, as long as we use the same word for links to the OpenWrt firmware/images.

I actually meant something simpler: that we could use "..." in the example URLs so that people can see the desired *ending* - sysupgrade.bin or factory.bin

(Last edited by richbhanover on 14 Jun 2015, 01:30)

Good discussion you have had... but I dont know what updates you want

1) The comments, we want them, but we are reluctant. That is ok. I add them and I can remove them later.
2) Brand vs Vendor: Belkin bought Linksys. Belkin is the Vendor, Linksys is the Brand. Should we file the WRT1900AC under Belkin?
3) Vendor Device Url => ? (lets wait until we resolved Vendor vs Brand before we rename this one)
4) Vendor Firmware Url (missing today, lets see what we come up with)
5) factory-img_url (?)
6) factory-img_url (?)

Those are the 6 "open" questions, as I see it...

Here are my suggestions that you can complain with. Comments are "in". Then:

Brand                             : Asus        # a comment to Brand
OEM Device Homepage_url           : ...
Firmware OEM Stock URL_url        : ...
Firmware OpenWrt Install URL_url  : ...
Firmware OpenWrt Upgrade URL_url  : ...

When you change/complain about this: can you please quote the 5 lines and edit them to your preference?
And if you want anything else, just add it.

Brand                             : Asus        # a comment to Brand
OEM Device Homepage_url           : ... # yourbrand.com/yourdevice
Firmware OEM Stock URL_url        : ... # yourbrand.com/yourdevice/stockfirmware
Firmware OpenWrt Install URL_url  : ... # downloads.openwrt.org/... factory.bin
Firmware OpenWrt Upgrade URL_url  : ... # downloads.openwrt.org/...sysupgrade.bin

factory + sysupgrade.bin are a bit problematic, since there are devices that do not use .bin, but I think, .bin is true for most of the devices (correct me if I'm wrong).

(Last edited by tmo26 on 14 Jun 2015, 09:47)

I agree. I know there are at least the following variants for installing OpenWrt:
1) A disk image (RPi, x86), several different ones actually:
- https://downloads.openwrt.org/chaos_cal … 8/bcm2708/
2) A device specific factory image, but a generic upgrade image:
- https://downloads.openwrt.org/barrier_b … xx/legacy/
3) Just a sysupgrade image that also works for flashing from Stock (Archer C20i):
- https://downloads.openwrt.org/chaos_cal … ps/mt7620/
4) Separate device specific factory and sysupgrade images (WDR4900 v1):
- https://downloads.openwrt.org/chaos_cal … x/generic/

There are probably other options with vmlinuz+rootfs images to load via UBoot and tftp.
And we dont know about the future
So I think the data entry should be quite generic.

About the Status_ field... as it is now we have supported/wip/possible/unknown/unsupported, based on the current page.
When we do the 900+ migration... it would be a good opportunity to define the meaning of those different status values:

Unknown
- newly added device, default value
- information about hardware is insufficient

Unsupported
- the specifications (flash/memory) are simply insufficient, or
- that Platform is highly unlikely/impossible to support in OpenWrt and/or Linux, or
- for other reasons unsuitable for running OpenWrt

Possible
- the device meets minimal requirements, and
- the device Platform matches an existing OpenWrt target

WIP
- the device is known in buildroot, and
- there is an image in trunk, or
- it is possible to build an image using buildroot
- the device is confirmed to boot/run OpenWrt

Supported
- there exist a working image in a stable release
- some features may not be working (WiFi, USB, Modem, etc)

As I see it, separately from this "Status", there could be other OpenWrt-like builds:
- A community project (like McWrt)
- The OEM provides some OpenWrt-derived/like system
- Manual patches of the buildroot are required
Wouldn't it be good to have some way to represent this in the data entry?

Brand                             : Asus  # a comment to Brand
Unofficial OpenWrt Support        : ...   # Unofficially supported via external patches or images
OEM Device Homepage_url           : ...   # yourbrand.com/yourdevice
Firmware OEM Stock URL_url        : ...   # yourbrand.com/yourdevice/stockfirmware
Firmware OpenWrt Install URL_url  : ...   # downloads.openwrt.org/... factory.bin
Firmware OpenWrt Upgrade URL_url  : ...   # downloads.openwrt.org/...sysupgrade.bin

Unsupported
To make it crystal clear to the user, I set "Status" to "unsupportable" for some devices with low flash / low RAM.
Should we change "Unsupported" to "Unsupportable" or "Impossible" (in contrast to status "Possible") or make otherwise clear, that it is impossible to support these devices?

WIP
- the device is known in buildroot, and
- there is an image in trunk

-> I would call this supported.

Supported
- there exist a working image in a stable release <or in trunk>

Unofficial OpenWrt Support        : ...   # Unofficially supported via external patches or images
Uhm... patches may change faster than you can update the information...
I'd say: Status = "3rd party" or "external", and leave the details to the devicepage.

Different approach:

Supported    there's an image available for download
    Release
    Trunk
    3rd party
   
Unsupported    there's no image available for download
    unsupportable
    WIP
    unknown
    possible

I think "Unsupportable" or "Impossible" is better than "Unsupported".
"Unsupportable" describes reality better, but it is a strange word, so I prefer "Impossible". Both good with me.

Does WIP disappear?
Or was my definition wrong?
I got an Archer C20i the other day and flashed the OpenWrt sysupgrade image from Stock Firmware. It worked. But it is unclear if I was the first person to ever do it, and there was no information saying that the (trunk) image actually works on actual devices. Shouldn't this be WIP?

Status = 3rd party OR External OR Inoffical
I am ok with that, but, then we lose track of the "official" status. But that is perhaps ok. So, right now, for WRT1900AC, we set status to "3rd party" rather than WIP or Supported, because this is the most sensible thing to do for a user. When it gets good support in trunk/stable, we change from 3rd party to Supported. Ok with me:
- 3rd party?
- External?
- Inofficial?

Back to:

Brand                             : Asus  # a comment to Brand
Status_                           :       # remains to decide "Inoffical" label
                                                              "Impossible" label
                                            and if I should do any intelligent rules
OEM Device Homepage_url           : ...   # yourbrand.com/yourdevice
Firmware OEM Stock URL_url        : ...   # yourbrand.com/yourdevice/stockfirmware
Firmware OpenWrt Install URL_url  : ...   # downloads.openwrt.org/... factory.bin
Firmware OpenWrt Upgrade URL_url  : ...   # downloads.openwrt.org/...sysupgrade.bin

- Impossible: Let's take it!
- 3rd party: I like it (better than the other options)
- WIP: depends on how we define WIP

zo0ok's WIP:
- the device is known in buildroot, and
- there is an image in trunk, or
- it is possible to build an image using buildroot
- the device is confirmed to boot/run OpenWrt

-----

tmo's WIP:
- not known in buildroot (i.e. WIP to get it into buildroot)
- early stage: someone opened thread in the forum with hardware information and is working on openwrt support.
- early stage: someone got an OEM bootlog via serial
- later stage: it is possible to build an image using buildroot, no trunk support yet
- later stage: tries to get openwrt to boot
- later stage: the device is confirmed to boot/run OpenWrt; openwrt bootlog available, no trunk support yet

Supported
- patch for support submitted (birth of official support), known in buildroot
- there exists a working image in a stable release or in trunk
- some features may not be working (WiFi, USB, Modem, etc)

What do you think about the different definitions? Pros/Cons?

@tmo26, you are on 1023 now, just telling

I am confused about the WIP thing. Someone else should decide.
Thing is, the "Status" field by itself does not do/mean anything. If there is a working image there is. And if the target is unknown then it is. And so on.

I think of it like:
- Unknown: just added / not enough information
- Impossible: forget about it
- Possible: may require a lot of work
- WIP: developers only
- Supported: end users welcome

Are those useful definitions?

Thanks for the reminder, 2^10th posting!

What confuses you about WIP?

If you look at changesets, you notice the usage of the phrase "support added for device xyz".
I would call this "Birthpoint of OpenWrt support".
Everything before this changeset is WIP (at best - if someone is working on it).
Everything after this changeset is supported (at least supported in trunk, if image available).

Hmmm... don't understand your point. Can you explain more detailed?

Sure, why not. Except: "Possible" would be also "Developers only"

Except Possible would have no image

A lot of work can happen in both "Unknown" and "Possible". And in "Supported" also.

Should we simplify to:
1) Impossible
2) Development (with or without trunk image)
3) Supported (end users should stay out of trunk, so at least a RC is required)

I think, the "stage of development", the Developers keep track of pretty good themselves, without the Wiki.

In case we (@tmo, @richb) agree on this... who else need to approve it?