I guess we need to (manually) set up a few test-dataentries, to validate our model. That sounds what @richbhanover wants to do.
I think the "dataentry_template" is very good! If there are problems with it (and perhaps there are) the best way to find out is to actually put it to real use.

I think we should set up 6-12 data entries that corresponds to 2-3 device pages and see what happens.

That brings us into the NAMING of data entries (the txt-files that will later become the url for them).
I did
1) Brand+Model+Version
2) Replace and eleminate various characters
3) In the case of QEMU, adding target/platform to make it unique
This generated long and ugly data entry names!

Alternatives would be
a) 00000001, 00000002, 000000003, ... (not nice)
b) a hash (worse)
c) Asus-00001, Asus-00002... (also not nice with SFR (Société Française de Radiotéléphonie))
d) Model+NNNNNN (even models are not nice: TEW-632BRP & TEW-652BRP)
e) We think of something sensible for 910 device pages and write guidelines (just joking)

Avoiding the question. After Big Bang (that is when all data entries are created and the old ToH is retired, sorry for not being clear)... what is the procudure when "anyone" wants to create a data entry? Can we have a form for that? How then is the name of the data entry created?

Perhaps this is the right way to start (with an add-data-entry-instruction), then @richbhanover can add a few (test) data entries and try it?

Yes, a form would be helpful for creating new dataentry pages -> can be done with the "bureaucracy plugin".
I will try this out beginning of next week.

Yes, but... I want to make sure that my detail page looks good using the new datatable facility, but can't do that without having (test) runs of the dataentry pages.

Or have I missed something else?

Agree! https://forum.openwrt.org/viewtopic.php … 96#p277996

I worked a little bit yesterday on reviewing http://wiki.openwrt.org/toh/dataentry_template
There is still some work to do, and perhaps some things to decide. And the data entry naming question. Then we should create a few test data entries.

I did some more work on: http://wiki.openwrt.org/toh/dataentry_template

The "Data Entry Section" and the "Conventions for dataentry values" should now be in sync.
Apart from that I made some changes that you might not agree with

Two questions:

1) To make test data entry pages, am I correct that we should a) create a new [[techdata:brand:model]] page, then fill it in with the data from the template (above)

2) I'm going to recommend again that we make a few trial runs at creating all the data entry pages at once. No computer program works properly the first time, and the data-entry-creation program is not going to be an exception. (Sorry @zo0ok - I know you're good, but I would still like to have the chance to have updates if we find the need for them :-)

Thanks.

PS I realize this is a third question, but... Is there an easy way to create a new page without simply adding a link to it on it to a dummy page, then clicking the link, then clicking "Create this page"

@richbhanhover

1) I think so, I suppose @tmo26 should/could produce guidelines for the rest of us
2) I agree. I only dont want your work with the device pages to be delayed because I dont have a 100% tested tool ready
3) You think about device page or the data entry? Anyway, I dont know.

The plan ahead should be something like:

a) Agree on data-entry-fields
b) Create a few data entries and device pages to validate the data entry template and our ideas
c) Create a new dynamic ToH based on data entries
d) Possibly go to (a) and reiterate
e) Automatically generate 9XX data entries form old ToH
f) Import 9XX data entires
g) Possibly go to (f) and reiterate (can we do this?)
h) Replace old 5x ToH with new dynamic ToH
i) Start working on the Device Pages

What is missing?

;-)

1) Factory Image_url / Sysupgrade Image_url  vs. Factory Image Name /  Sysupgrade Image Name
I think I see the reason behind this change: precise url would need maintenance with each new openwrt release.
However, if you look at 15.05-rc1, the OpenWrt version is also included in the image name, hence requiring maintenance.

Example: https://downloads.openwrt.org/chaos_cal … actory.bin

My opinion on this:
- Maintenance effort would be small per device and could be done either by the devicepage-maintainer (if there is one) or by the community
- Starting with 15.05-rc1, the OpenWrt version is included in the image name (useful addition!) -> imagename needs maintenance, too.
- Direct link is unambiguous, saves time and searching for the user

My vote: Stay with URL/direct link i/o imagename.

2) Flash Chip / Type / RAM chip moved out
I found these on some of the devicepages and moved them in for completeness. Since I'm no developer, I'm asking the questions: Could this info be useful for a developer for searching / comparing devices with the same chip / type of flash?
Could this info be useful for users who want to enlarge flash/ram memory?

Edit:

3) Why did you move out Identical to / AKA / Similar / OEM-firmware_url?

(Last edited by tmo26 on 1 Jun 2015, 19:46)

Not my best day, it seems

1) Image names... I give up, given what they did in 15.05 I have no case.
I have a horrible new idea: in the data entry, can we have
- 14.07 factory image
- 14.07 sysupgrade image
- 15.05 factory image
- 15.05 sysupgrade image
- trunk factory image
- trunk sysupgrade image
?

2) Problem with Flash Chip Type is that if there is two types of flash (16MB+128MB NAND) then the Flash Type gets complicated. Ram type... if anybody wants it we put it back.

3) OEM Firmware Url... was thinking that a) links change, b) firmwares get updated and we will point to obsolete factory firmware, c) we already have a link to the device itself.
If we are going to have it: should it point to the downloadable image itself, for a page where the image can be downloaded?

3) Identical to / AKA / Similar...
- Is parent going to point to child AND/OR child going to point to parent?
- What will we reference to (Brand+Name, a device page)?
- Was it searchable the way we talked about?
- Does this entirely replace the need for a Data Entry for a "copy"?
This is a little too confusing and ambigous for my taste. If we can get it clean and useful I am fine with it.

Edit: Ran an update to at least do something useful: https://dl.dropboxusercontent.com/u/906 … index.html
Good night!

(Last edited by zo0ok on 1 Jun 2015, 21:50)

I like the Brand+Model+Version scheme. Can these long names be shortened?
In the case of TEW-632BRP & TEW-652BRP -> decide for one of them as currently in the wiki, or alternatively create 2 pages, one for 632, one for 652; the latter could make use of the "Identical to" or "Similar to" characteristics in the dataentry_template.

Only now I realize the importance of this question.
Need to take that into consideration when playing around with the bureaucracy plugin in my demowiki.

Well, there's not much to explain:
- Create new page
- Copy dataentry template to the new page
- Fill in the device data
- Save
- Done

I just saw a note on the forum (https://forum.openwrt.org/viewtopic.php … 65#p278565) where someone misinterpreted the ToH entry for the Archer C9 - the newcomer thought the router was supported. They cited the router details page at:

http://wiki.openwrt.org/toh/tp-link/archer-c9

Perhaps we should be more clear and assertive and change the "unknown" status to say  "Status: Unknown - Not currently supported"

This could be the default for all new equipment, and any developer who gets it going can take delight in changing it to something new.

@zo0ok: I would put this step - "Automatically generate 9XX data entries from old ToH" - as the first item, then start the iterations...

That's because this tests the actual data we have (from the current ToH) instead of the data we think we have (if we create our own dataentry pages).

(I realize that we all would need to keep private/local copies of any modifications we made to the small number of dataentry pages that we experiment with (say, links to vendor pages/firmware, etc.) while we test out the broader procedure.)

My preference would be something like:

a) Automatically generate 9XX data entries from old ToH
b) Create a few device pages to validate the data entry template and our ideas
c) Review (and update, if needed) the data-entry-fields and/or the template for the detail page
d) Possibly go to (a) and iterate until we're happy

When we think that that things are pretty stable, then:

e) Automatically generate a "final set" of 9XX data entries from old ToH
f) Create a new dynamic ToH based on data entries <== not sure of the order here...
g) Import 9XX data entires
h) Possibly go to (f or g) and reiterate (can we do this?)
i) Replace old 5x ToH with new dynamic ToH
j) Start working on (all the rest of) the Device Pages

Whether we do the automatic generation first or not, I will take a shot at one of the detail pages this week to move the process forward.

Status = supported -> Device is supported
Status != supported -> Device is not supported

Taking "unknown" as "supported" is whishful thinking, but not logical.

@zo0ok: Please note that for datapage creation, datapage names / folder names must be all lowercase, i.e. '_va1' instead of '_Va1'

Background: Your first run of datapages contained uppercase letters in folder names, which lead to very little devices being shown in my demowiki siteindex (=only devices w/o version info).
After I lowercased the folder name for all devices, they showed up in the siteindex.

I'm glad that it was such a simple solution. I already thought we would have some weird issues with character encoding and such... :-D

(Last edited by tmo26 on 2 Jun 2015, 20:06)

...and 'v-' / 'v_' (ending in '-' / '_' without any following character) is also a bad thing, will not be recognized by dokuwiki.
-> If no version present, then add no version ;-)

(Last edited by tmo26 on 2 Jun 2015, 20:26)

Including some more, I summarize:

Restrictions for datapage creation:

* all lowercase folder / filenames; no uppercase characters allowed
* no folder / filenames ending in '-' / '_' allowed
* no '__' (double underscore) allowed, only single ones
* no ' ' (space) allowed; replace ' ' by '_'

If any of the above restrictions is violated, the page will not be existent / accessible for the wiki.
-> Needs to be considered for creation of new datapages via forms (bureaucracy plugin).

(Last edited by tmo26 on 2 Jun 2015, 20:43)

Ok, I get it, you want me to start generating 912 data entries... I will, but it will take a few days before I find time.

I appreciate the naming requirements from @tmo26. I will try to keep it simple, short and concise. Should the data-entry-filename also be a field in the data entry?

Yes... but if you Google for "Archer C9 OpenWrt", and you end up in the page mentioned (which is clearly an OpenWrt page about the Archer C9 device)... if you are new to OpenWrt, that page could give you the impression that the device is supported. And "status=unknown" could mean anything (like "don't know if it is discontinued"). That said, I think anyone who wants to install OpenWrt should do much more research first! But it would not hurt if every Device page had it very clearly printed "Supported: NOT supported by OpenWrt (currently WIP)", not just "Status:Wip". And the 5 different ToH pages are also confusing. There was someone the other day who thought the ASUS RT-N10U was supported (listed under possible), probably because ASUS RT-N10+ was supported. Seriously, you could think that the + was part of a "regular expression" and that all N10* were supported. Anyway, it will be so much better when we are done with this work!

Take time, no need to hurry. There are still things to be sorted out and the dataentry template to be brought into shape. I'm working on this.

Yes, this way it can easily be used in the devicepages.

More tomorrow, I'm already late...

Instead of coding I keep asking questions...

In the 5 ToH pages, there are today one table per brand. Not all tables have all columns (I have been faking default values without telling you). Also, some tables have unusual columns that are not normally found (Modem, Power Line, etc).

What is your opinion about those unusual columns?
More specifically - please tell me which ones you would like my migration tool to take into account, and in case it is not obvious, what field in the data entry should the value go to?

I have found the following extra columns:

serial, serial console, RS232/TTL -> Serial
jtag -> JTAG
modem, powerline -> Modem
misc, notes -> Comments
gpios, uext, phone sockets, BDM, other -> proposal: Other IFs
HDD (IDE/SATA), SATA, mPCI, mPCI-e -> proposal: Other IFs
3G, GSM, bluetooth, gps -> Comments
sdio, micro SD, SD, cardreader -> Comments
battery -> Comments
tft, display -> Comments
Related finished product -> Comments (I'd delete this column from the table and put that information on the devicepage.)

"Other IFs": Proposal to cover all that stuff that's not widely available (HDMI, UEXT, ...).
Alternatively to this, we could simply skip some information that is only rarely available.

Please feel free to ask more questions - that will decrease the number of false starts, and improve the quality of the final work

This sounds like a good idea to me. (Could it be automatically generated with [[techdata:brand:router-version]])?

I don't know if I'm allowed to second a motion that I originally made, but I agree.

Another way to address this might be in the detail page template. The default could list all the possible status values as a bullet list, with a one-sentence description of each.

Then a newcomer's search through the wiki would take one of these three paths:

- No detail page for the router - no info. "Hmmm... I guess no one has tried it"
- Someone starts a detail page using the template: Default is unknown, and the bullet list shows "Unknown: Not supported by OpenWrt"
- A developer has actually got it running. They update the status to say "Supported" and can then remove the other bullet list items.

I noticed that Zyxel P-2812HNU-F1 + P-2812HNU-F3 are present in both "supported" (Status 15.05, which can't be correct since we're only at 15.05-rc1 now) and "wip" (P2812HNU-F1 + P2812HNU-F3; note the missing dash compared to the supported entries).

Changeset https://dev.openwrt.org/changeset/43987 suggests that there should be support for this device.

However, I can not find a suitable image, neither in https://downloads.openwrt.org/chaos_cal … c1/lantiq/ nor in https://downloads.openwrt.org/snapshots/trunk/lantiq/.

IMHO this device is still WIP, as long as there's no prebuilt image available in the download section.

Thoughts?

ARV7519PW is missing in the toh, while there's a devicepage available: http://wiki.openwrt.org/arv7519.

https://dl.dropboxusercontent.com/u/906 … index.html

I have created a column: dataentry, that currently holds the suggested name for the dataentry.
My idea is that when I start generating the dataentries themselves they can be accessible for us by making that dataentry column into links.

At some point you will want them all in one directory structure in a tgz-file. We'll get there.

For now, are the (dataentry) names good?

The names are generated 90% rules based (i.e. toLowerCase()), but there are also some hard coded exceptions for some Brands and Models. So if we start renaming brands and models that can cause some confusion. I think it will be ok for the time we work with this.

@tmo26, dont know if you did anything with that Zyxel you asked about a few days ago.
We need a "shitlist" of rows/devices/dataentry that needs improvement. The Zyxel devices in particular has been on my private shitlist since long.

How about the brands:
  Atmel
  Atmel AT91SAM
These must be the same?

And then there are devices under
  Allwinner Axx
  Olimex
that looks pretty related, possible duplicates. This "Allwinner Axx" breaks the entire concept of "brand". Allwinner is a Platform rather than a Brand (as we usually use those).

Then we have the "Evaluations Boards / Unbranded". I put those into "other_" when it comes to dataentry name.
Perhaps if the brand of Allwinner is not clear we should put those into "other_" too?

When I get more time I will start generating data entries themselves.

(Last edited by zo0ok on 7 Jun 2015, 11:30)

Returned today from the Maker Faire in Hannover. Many MR3020s and 703Ns in use there!
Will look into the dataentry names today.