Around 90 devices where we have an existing changeset which adds some kind of support, but the "supported since release" and "supported current release" status is unclear:

http://wiki.openwrt.org/toh/views/toh_a … ince%20rev

Something to work on...

BTW: I like the new ToH for it's flexibility. Arrange the columns as you need them, sort them as you like, and gather new insights. Nice!

What are the criteria to give a device the label 'Possible to support'?

For instance the Vonets device i'm adding. Vonets themselves have a few documents regarding OpenWRT RAM and ROM are large enough, but is that enough to label a device as possible to support?

And i have a Unbranded device coming my way that has a AR9331 but that's all i know at this point.

Is there a page that lists these criteria? (I have not found it yet)  If not, then should one be created?

A checklist.. 
What about an automatic checklist that uses the ToH itself.
If a device
- has a supported SoC
- enough RAM
- enough ROM
- and all other criteria...

Then flag it as Possible to support. 

This way we would have to fill out the ToH, the flag can not be forgotten by accident, we don't have to check manually, etc.

I had a look at the Bootlog and how the ROM is organised. and wondered if it would be an idea to also add some of that data to the ToH.  If there is some kind of pattern in this data, that would make it also easy to check and compare this data.

I'm not sure if all devices that use the same ROM have a similair structure or not, or if there are other things in the configuration that are identical. That could perhaps save the devs some time or give someone new insights.   

....Thinking out loud again. Simplify and recycle at will.

Please add the brand 'Domino'

I asked GL.iNet about this. Domino is indeed a separate brand name. (Domino is Open Hardware)

I will correct all the pages and also make subfolders for the models and move the images etc.

Done.

Thanks,

Is it possible to move / rename

http://wiki.openwrt.org/toh/hwdata/gl.i … _domino_pi                                     to domino/domino_pi
http://wiki.openwrt.org/toh/hwdata/gl.i … no_qi_mini                           to domino/domino_qi_mini
http://wiki.openwrt.org/toh/hwdata/gl.i … omino_core  to domino/domino_core

and also the device pages

the domino_core and m9331 are the same device should they both have a page or only one of them and then the other a link to the 'main' device?    I don't know what device is the actual clone in this case.   I think the Domino core existed before the GL-M9331. 

GL.iNet now has all model types starting with GL  (also for the GL-AR150 and GL-AR300)
and the device currently listed as GL.iNet Also known as 6416A now goes by the name GL-inet6416.

I'm not sure if we should follow all the growing pains, but since this now seems to be the default naming i like to suggest to do this update. 

I will do all the corrections to the media library, and the pathnames in the wiki.  And try my best to not cause any chaos. 

Building this wiki is a lot of hard work, and it's stuff like this that makes me realise how much work already has been done.

I dont know how renaming/moving is done. There are probably standard answers available for DokuWiki somewhere, but nevertheless it would make sense that we talk about it first, and perhaps produce a little renaming-guide (if possible).

What to rename, in what order:
1) Media Files
2) Device Page
    - may contain links to media files
    - may use/present data from Data Entry
3) Data Entry
    - contains link to media files
    - contains link to Device Page

I think it is rather important that device models and page names are consistent within a brand. I think looking for consistency between brands is unrealistic.

I cleaned up the Pogoplug devices (just the Media files the Data Entries) a little while ago. I just changed the model names, but now they are not consistent with the page names. Renaming also the pages would make it cleaner.

I don't know if somebody noticed: I cleaned up the media namespace some weeks ago.
Pre-cleanup we had media in ":toh:[brand]", ":media:[brand]", ":media:toh:[brand]".
After cleanup we have media only (mostly) in ":media:[brand]".

In addition to moving images from one to the other namespace, I removed doubles, renamed "img1234.jpg" to something meaningful, depending on where the picture is used, and created some sub-namespaces for models with many pictures.

The naming of media files is not 100% correct, but correct enough to work with, and anyway better than the chaos we had before.

How renaming / moving can be done:
1) Brute force (no need to be admin to do like this): Edit page A, copy&paste to page B, remove all contents of page A; adapt links from A->B manually, for all pages affected.
-> Error prone, much work if many pages are affected. You don't want to do this, unless you only have one single page to edit (or unless you are impatient like me and can not wait for a bug in a 'move' plugin to be fixed ;-).
2) via admin: there are some move plugins, doing the above link adjustment automatically.

Moving media around and renaming it is no problem for devicepages: Links are automagically adapted by the "move" plugin. In dataentries however, links to images may need manual rework.
The same applies for moving devicepages: Links are automatically adapter, except maybe in dataentries.

Consistency is nice, and wherever possible dataentry and devicepage should have consistent naming. However, it's currently not my top priority. When I stumble upon inconsistencies, I try to clean them up (e.g. yesterday: we had two namespaces, 'gl-inet' and 'gl.inet'), but I'm not searching for them.

I'll take a look at that, although I'm not looking forward to do so, due to the wonderfully confusing naming scheme of pogoplugs.

My scheme for renaming media:

- Use '-' within the model name (TL-MR3020)
- Use '_' to separate model name from description (TL-MR320_case.jpg)
- Within the descriptive part, use '-' and '_' as you like. Some devices use '-', some use '_' in the description, and I wasn't up for correcting this minor issue.
- Use only model name, leave out Brand (ie. "tl-mr3020.jpg" i/o "tp-link_tl-mr3020.jpg"). If images are nicely sorted into :media:[brand], this helps keeping the links short and avoids redundancies.
Again, I wasn't too eager to get 100% consistency here, especially between brands. Some images still have brand and model in the name, while others only have the model in. It depends on both brand and model: TP-Link doesn't need the brand in the media's name, since their naming scheme is mostly unique and easily recognizable (TL-.....). On the other hand, there are models like "7001". I don't like names with numbers only, since I have seen too many of them (img00203.jpg) leaving me clueless which brand/model this image was about. I don't mind having the brand in the name in this case.

I need to come back to this:

Yes, it makes sense to do it in this order.

1) -> done (unless you have some more requests)
2+3) Do you know of more devicepages / dataentries that need a renaming?

Done for the dataentries, devicepages to follow.

I like the default naming, too.

Yep, a lot of work. I'd be interested in how many edits we have done so far to make it like it is today. My edits alone must be several thousands...

Just found out: 5357 Edits + 1504 minor edits so far. I hadn't thought it would be *that* much.

Some statistics about wiki contribution: http://wiki.openwrt.org/wiki/stats/authorstats

Thanks, 

The devil is in the details. I wish i could have done more (my 3G connection is extremely slow at the moment)
5000+ edits is indeed a huge number. 

For potential new brandnames ant model numbers it might be an idea to put a bit of a structure in place.
I think the media directory structure is key here. Looking at the structure (or absence of structure in some cases)
is partly the cause of the number of edits.  If i had realised sooner how that worked i could have saved tmo a lot of work.  A lot of brands don't have the model types in subfolders, growing pains i guess. Form now on i will take extra care to do this better, and i hope other newbies will not make the same mistake like me. 
I think tmo's 'Grundlichkeit' is helping a big deal here. 

I'm a good example of a bad example. :-) There should be a structure in place that prevents people like me from causing chaos. Some things i just did not see when i got started, so that ignorance caused a bit of chaos. I could have asked more questions, but then i most likely never would have got anything done. 

Looking back at the past weeks i can imagine that there are more people that want to help but just don't have the time to figure it all out. what do you guys think about that assumption? 

It's good to see this wiki improve. And i hope more people see how much effort you guys have put in. 

Thanks a lot!

...and probably don't need to have them in subfolders.
I only moved into subfolders, where we have *several* pictures of a certain model.

Reasons pro subfolders:
- keep the brand namespaces clearly arranged
- avoid "flooding" a brand namespace with many pictures of a certain model

Reasons against subfolders:
- keep the hierarchy flat, since with growing number of subfolders, it's getting harder to see the complete path in the mediamanager

Therefore: If you are simply storing pictures in a brand namespace, without subfolders, you are not doing anything wrong. Maybe over time the number of pictures grows, and someday there are enough to put them into subfolders.
With the pagemove plugin now working as it should (it wasn't some weeks ago), moving media around while maintaining the media links is quite easy.

Ok, so a good filename then is key to keep things organised.

something like:
brand_model_(front,rear)pcb_(top,bottom,pinout,ttl).png

Then for future additions it will be more easy to navigate.

If every filename starts with brand_model_ that would make a big difference

But if there is a standard rule then it also would be possible to generate a standard wikipage.
Upload images with the name rule and they magically pop up in the wiki as soon as they are uploaded.

Would that make sense? Maybe for the future, but if we can agree on some kind of file naming then a lot could be 'future proof' to some degree.  And the wiki can be more uniform. What makes the wiki itself more userfriendly. Less work to add data. And images are more easy to verify

Clearly: YES!

http://wiki.openwrt.org/meta/adding_ima … iki#naming

Will anybody miss the QNAP devices?

https://wiki.openwrt.org/toh/views/toh_dev_platforms?dataflt[Brand*~]=qnap

There's no info about the platform, neither do we have any signs of OpenWrt support.

I will miss them a little. I have a TS 109, and if you remove them my last hope of it ever being supported will go away.

Get rid of them. I'd say. I was thinking the same a few weeks ago.

I don't have much love for the QEMU entries either. First they don't fit the template well. Second, an article on OpenWRT on QEMU would be much more useful than a ToH-entry.

There are just 113 devices: http://wiki.openwrt.org/toh/start
I tried a few other views too...

No idea what happened. Anyone?

We had a database corruption, which made it necessary to delete the database and rebuild it. Rebuild is currently running. Should be finished in 20min.

Sorry for checking out the wiki at this inconvenient time then

Hmmm... having problems getting the ToH back to the state it was before the database corruption.
Despite re-building the wikis search-index several times (this normally adds all techdata pages to the ToH database), the number of devices increases only very slowly.

I'll keep on trying... :-/

If it just takes long time, dont worry... sorry about the problems.
Guess there is not much I can do to help?

Nope, I'm helpless myself... tried everything that might/should help, but..... hmpf.

Info: ToH seems to be fully working again. At least we're now at 1038 devices in the ToH, which sounds more familiar than the previous numbers (100...300 devices).

Thanks tmo26!

I sometimes get a 404 errorpage in the wiki, a refresh fixes it so it isn't a big issue, But just to let someone know that I occasionally see a 404 page..