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

Good work with the Status column!
I feel a little bit in the dark editing that column... but I see your point... if there was an image that should be enough. If you figure out what image to use, that is

Lets work on the Status column until it looks clean.

We got
-  five pages (supported, wip, possible, unknown, unsupported)
- a supported column (indicating essentially if there is a download, not how well it works)
- a target column (which is normally empty for unknown/unsupported)
There is some overlap/correlation between these three parameters. I think we could benefit from defining them in a more orthogonal way. Perhaps, getting rid of the 5 pages and relying on the other two might be the best thing to do. And if we can get everything into the wiki-structured-data it would do that.

Thanks to the good service you offer

Status could be:

Status  Meaning
x       not possible
-       not supported, nobody is working on it (default, until proven wrong)
wip     not supported, $somebody is working on it, but no trunk available yet
trunk   supported by trunk only
14.07   supported by official release version (earliest support)
--------
r44666  don't use rxxxxx in this dataentry, put it on the devicepage instead.
        For the average firsttime $user, it's confusing to filter for such a variety of
        possible release versions.
?       support status unknown -> don't use this for productive data, but only to mark
        a device as 'needs to be checked'. 

This way, you can easily filter the data for automatic creation of an "supported" or "trunk" or whatever page.

Edit: What about "no longer supported" devices? Perhaps "7.06 - 10.03.1"?

(Last edited by tmo26 on 20 Apr 2015, 20:23)

tmo26, I agree 100% with Status (x,-,wip,trunk,14.07, ?)

I think it would be great to get rid of the rXXXXX. And, I am the idiot who put links to this forum in the Status column so I think the links should go away too.

For the no longer supported...
I can imagine two types:
a) Those that run BB/trunk, but perhaps better run older (Backfire), i.e. everything with 16MB RAM
b) Those that used to work, but that don't work at all with BB (or even brick BB)
    (i.e. http://wiki.openwrt.org/toh/trendnet/tew-691gr)

How about always (allowing) a range if multiple are supported:
12.09-14.07 (indicating that both AA and BB actually works)
7.06-10.03.1 (indicating that nobody reported success with later versions and bothered to update - use with later at risk)

We should not need to allow
  14.07-trunk (since trunk is always at risk).

An alternative (and I guess it is not popular, but here we go), would be to list the recommended version (not the first/oldest).
For 16MB routers we could give two versions with a comma:
  WDR3600: 14.07
  WRT54GL: 10.03.1, 14.07
First/historical versions can be put in the device page, under a section where success/issues with trunk/current can be collected.

Otherwise I am good with your suggestion too.
We should be able to get rid of the 5 confusing pages this way.

By the way, my single list is updated with nicer links and better performance.

(Last edited by zo0ok on 20 Apr 2015, 21:48)

Yes, the rXXXXX is confusing, and I'd like to make it less visible.

I like the idea of a "recommended" build, which might also handle the "no longer supported" category. I think it could also minimize effort across the full life cycle of the router.

Here's how it would work: a new router comes on the market, somebody (who owns and cares about the router) creates an entry for it in the TOH, then updates it for a few builds (BB, CC, DD, EE, etc). At some point, the router drops from favor, and nobody updates the entry in the TOH again. If there's a "recommended" field, it'll always contain the newest build where someone asserted it worked. If no one updates the info in the TOH, the recommended version stays the same, even if it's multiple versions behind stable.

We could have another "Other Builds" column that contained one or more older builds (10.03.1, 12.09) and/or current (CC, DD...) builds.

Would you re-post the link to the single list? I've lost track of it.

I think the support status should stay compact, but instead of showing the earliest supported version, just keep it at the most recent version that fully supports the device. That might be easiest - it removes the need for listing multiple versions, and it eliminates the problems the 'earliest supported version' practice we use now creates, which doesn't imply whether newer versions still (fully) support it. While I like to know how far back support dates for a historical device, that can always be listed on the device page itself.

Do agree on not using SVN revisions as well. Most people won't want to build OpenWrt first time they want to try it. People who do usually know what they are doing and whether their device is supported or not.

E.g. The WRT54GL could then list 12.09, and others 14.07, ... In that case I would call the column "Recommended version" or something.

Is there a way to pull a list of all the models that have lost support with 14.07?

(Last edited by Borromini on 20 Apr 2015, 23:36)

Uh, thinking of what data to collect and show in which way takes as much time as editing the data. I thought it would be easier...

What's the difference between both?

I would have called it "Latest stable support", which strictly speaking excludes trunk of course.

What I've seen so far:
- Most recent version that fully supports the device
- Latest stable version
- Earliest version
- Recommended version
- Range (7.06 - 10.03.1; first - last_known_working)
- keep history of OpenWrt support on device pages

Need to sleep about that, see you tomorrow 8-)

My bad, that was a cut and paste error while reworking my own post. Corrected it.

Here is the link (same as always):
  https://dl.dropboxusercontent.com/u/906 … index.html

It is not particularly easy to download a list of all images and try to match them with data in ToH. A few problems are
- inconsistencies when it comes to the target column and subfolder/subtarget folders
- naming of model in ToH does not match image names
- there are some generic images that work with many routers
And, this would just say that there is an image, not that it works for any real purposes.

I think some kind of very simple survey where actual users of BB report what model they run it on and answer a few questions about to what level it is supported would be the most practical way.

Status  Meaning
x       not possible
-       not supported, nobody is working on it (default, until proven wrong)
wip     not supported, $somebody is working on it, but no trunk available yet
trunk   supported by trunk only
14.07   supported by official release version (earliest support)
--------
r44666  don't use rxxxxx in this dataentry, put it on the devicepage instead.
        For the average firsttime $user, it's confusing to filter for such a variety of
        possible release versions.
?       support status unknown -> don't use this for productive data, but only to mark
        a device as 'needs to be checked'. 

Perhaps also:

Status      Meaning
unofficial  Only external/inofficial builds exists or manual patches are required

Here's a question that has been a concern for me:

I commend all the effort that has gone into improving the TOH. It's fantastic that the info has been regularized/factored/harmonized to this format. The survey sounds like a worthy part of a one-time effort to collect all the info and organize it.

But I'm worried: Are we setting up a maintenance hassle? Will we have to rely on some good hearted person to keep this up  for the rest of time?

Or can we create a sustainable system for keeping this information maintained automatically, or at least by the community?

Well... that is why I have focused on improving and cleaning up the existing data. Because it has a value anyway.

But if we
1) clearify how the ToH should be filled out/used (if nothing else by good examples)
2) create/leave a struture that is more clear and consistent
then corruption in the future will happen more slowly, and quality may remain better for longer.

The current situation with 5 different pages is very hard to maintain in a good way.
I think the structured-data-wiki-format is very promising. But if, for some reason, we dont go there, I would suggest
- one page for each of the major brands
- one page for all the others
And then some short, well edited lists, with routers that are known to work well with current release and that are also available for sale.

As long as all we do is improving data quality and data structure the work is not in vain as long as OpenWrt lives. I think

Please don't come up with arbitrary symbols that only have meaning in the context of the table. Use "supported", "not supported", "not viable" (or similar) instead of "x", "-", and "thumbs up symbol".

Also, I agree, the support status should be a separate data item from the "support started with revision" data item, and the latter should only go into the details pages. It's valuable info, but only for people who are in the know.

We would need some explanatory page or legend for the table anyways, but I agree: It's best when it works without.

Agreed!
- > keep history of OpenWrt support (7.06 - 10.03.1) on device pages *only*

Regarding meaning of 'Status' when OpenWrt Version is shown:
14.07 = ...
- Most recent version that fully supports the device -> ok for me
- Latest stable version -> ok for me
- Earliest version -> no, show this on device page only (support history)
- Recommended version -> no, show this on device page only. Some explanatory words will be needed anyways (why older version is recommended while newer one exists).
- Range (7.06 - 10.03.1; first - last_known_working) -> no, show this on device page only

Comments are welcome.

Attempt to summarize the comments of today:
- don't use symbols
- unofficial added
- changed 14.07 to simply supported (we are free to chose both, supported + 14.07 in the final toh; it's easy once the data is there), following the dd-wrt example. Keep it simple, give a clear message to the user.

Status         Meaning
not possible   not possible (Hardware, software, etc. restrictions)
not supported  not supported, nobody is working on it
               (default, until proven wrong)
wip            not supported, $somebody is working on it,
               but no trunk available yet
trunk          supported by trunk *only* (no release version available)
supported      supported by official release version
unofficial     supported only by external/inofficial OpenWrt builds
               or manual patches are required
                  -> man patching: isn't that wip?
--------
r44666  don't use rxxxxx in this dataentry, put it on the devicepage instead.
        For the average firsttime $user, it's confusing to filter for such a
        variety of possible release versions.
?       support status unknown -> don't use this for productive data,
        but only to mark a device as 'needs to be checked'. 

Check out http://dd-wrt.com/site/support/router-database and filter e.g. "tl-w"; in the results, click on a line. Nice, fast.

Comments please!

(Last edited by tmo26 on 21 Apr 2015, 19:45)

Who can make this survey really happen?
If there's software needed to organize the poll: Who can install it here in the forum?

I guess wip = unofficial.
However... wip, in practice may mean abandoned and most likely never to reach any good level of support.
Unofficial (as in the current case of WRT1900AC) can be pretty good.

The advantage of 14.07 over "supported" is that if nobody edits/updates, the data degrades in a correct way, rather than a false true.

About the survey...

Someone mentioned a few weeks "Google Forms" i think, and indicated the survey would be very quick to put together.
I could also (as mentioned before) build a survey the same way I build the "single list", and people could either post the result as a single line to this forum or email it somewere (in both cases I would have to manually put it together, but it would be quite easy).
I prefere Google Forms, if we can get the Vendors/Routers/Versions into the survey... but I guess it can be done.

If you all think a survey is a good idea, we can start (here in the forum) to suggest/work on questions and answers. We can do that without a technical solution. Then, we can implement it in Google Forms, and test it.

In the long run, perhaps we want a "continous survey". Right now I think if we run it for 2 weeks we can hopefully get a few hundred answers, and that would be very valuable, for now. Then we can evaluate the whole thing and see what we can do different.

If anyone wants to install survey software on openwrt.org-server, there is something called LimeSurvey which is pretty nice. I think it would be very easy to install on the same server that hosts this forum.

(Last edited by zo0ok on 21 Apr 2015, 19:24)

Something to ponder: Let's just have the status in the status column, keep versions completely out of it. Meaning: A device currently supported in trunk would get "supported" status, and "trunk" in the "supported from" info item.

"Supported" does never degrade, it should only be qualified. "Supported in 10.x only" is still "supported".

Ideally, every device would get four data items:
- Status: supported, not supported, wip, supported by 3rd party
- First supported release: "CC trunk", "12.09", "14.07"
- Current (or last) supported release: "12.09", "14.07", "CC trunk" for devices that don't have major release yet
- Supported since revision: r12345

With these data items, it would be easy to compile the table into an easily understandable format, and also generate "12.09-14.07" or "10.x-current", "CC trunk" support strings.

(Last edited by metai on 21 Apr 2015, 20:11)

Some thoughts on "Survey":
- Let's make it continuous from the beginning and then take snapshots in 4 weeks interval.
- Manual survey -> user enters data manually on webpage
- Automatic survey -> after openwrt install (and if network available), send automatically initial ping to openwrt server; user configurable: off / initial ping only / 4weekly ping; ping contains Maker/Model/OpenWrt version (rxxxxx)/...

What hardware/software do you use?
- Maker/Model/OpenWrt version
- for manual + automatic survey
Who are our users?
- ASL (Age, Sex, Location)
- OpenWrt Experience: noob, advanced, pro, ...
- for manual survey only

That is debatable. If your device is supported by OpenWrt version X, but is not maintained (at least receiving security patches), how 'supported' is your device, really? At that point, you might as well stick with your vendor's firmware, from a security point of view.

Backfire, for example, hasn't seen any commits in almost three years now.

(Last edited by Borromini on 21 Apr 2015, 20:41)

I played around with Google Forms:
  https://docs.google.com/forms/d/1bLTEU1 … =send_form

It is a pain to do router selection! (Thats why only 4 router brands are available right now)
The other questions work just fine, or course.
This was just a quick attempt - you can tell me it sucks if you like. I know it does. It was just to get you started and thinking.
I hope it is not (partly) in Swedish...

Try it and let me/us know what you think!

(Last edited by zo0ok on 21 Apr 2015, 20:56)

Indeed it is. Maybe an additional status is needed. Something like "support ended", "limited support" or "legacy"?

Yay, it's a start!

About the survey...

We need to know what to do with device versions. Often it is critical to get the right information here. V2 may be fine and V3 does not work at all. Sometimes several versions are listed on the same line in TOH, sometimes on different lines. I would like to produce a survey where all versions (same line or not) show up in a list, together with "Don't Know" (after the user selected Brand/Device). On the other hand, I have a WDR4900. It is either 1.0 or 1.3 (I don't know), but I know it is NOT 2.0.
If, on the other hand, there are no relevant/known different versions, we might not want to annoy the user with it. This requires some thinking.

It would simplify the Form a lot if the first page was: Fill out Brand, Model, Version, and we asked the user to consult the ToH (or another purpose-generated list) to find the information. Or even just a (row/model)number. On the other hand, if I build the form myself in the same technology that my single hardware list is build in this is not an issue at all. Then we just need to figure out how to gather that answers.

I did some more (small) cleanups -> update please!

Enjoy!