I think I still don't get your point...

Supported    there's an image available for download
    Release    -> suitable for the enduser
    Trunk        -> developers only
    3rd party   -> we don't know how suitable this is, we list it just for reference
   
Unsupported    there's no image available for download
    Development
        WIP         -> developers only
        possible  -> developers only
    impossible   -> suitable for no one
    unknown     -> developers only

I like this idea. I suppose trunk could be for advanced users, but those users will figure this out anyway.

I like this as well. I don't know who else would need to nod their head(s).

I agree with these choices shown above for these reasons:

- Brand - it's the name printed on the box (your point re: Belkin vs. Linksys makes sense)
- OEM home page and firmware as shown
- OpenWrt firmware (I looked further, and there is huge variation on the suffix: .bin, .image, .trx, .mumble, so we don't need to spend a lot of time on that.)
- The comment fields are good.

Thanks!

(Last edited by richbhanover on 15 Jun 2015, 01:31)

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

I have not done anything to the Status field because you all seem enthusiastic and agreeing, but I dont know about what

The only thing I think about Status is: Newbies/end users should stay out of trunk => Trunk is not "Supported"

IMHO it's obvious, but you don't want to see what we're agreeing on ;-)

OK, I think now I get it.

Supported:    suitable for the enduser (i.e. there's an official release image available for download)
   Official release

Unsupported:    not suitable for the enduser (i.e. there's no official release image available for download)
    Development
        WIP         -> developers only
        possible  -> developers only
       Trunk        -> developers only
    unknown     -> developers only
    impossible   -> suitable for no one
    3rd party   -> we don't know how suitable this is, we list it just for reference

Example http://dd-wrt.com/site/support/router-database:

"For the supported status the following shortcuts apply:
    yes - the router is supported
    wip - work in progress, router support is in the works, but please don't ask how long it takes,
           we cannot give you a schedule in the most cases.
    no - the router can be supported but is currently not and is not in the works
    not possible - because of technical issues router support is not possible"

(Last edited by tmo26 on 15 Jun 2015, 19:59)

The DD-WRT people seem clever!

(Last edited by zo0ok on 15 Jun 2015, 20:06)

Since you are so eager for this change ;-): Is there anything against this change? Why don't we just implement it for a test run?

These categories seem almost right. But I'm stuck on one (common) use-case. What should the ToH say about a router that works fine on BB, but is being tested/also works with CC?

1) Should it be characterized as "Supported"? (That would be correct).

2) But should it also be mentioned as "Trunk"? How can we inform people about the fact that they could live a little closer to the bleeding edge and try the trunk?

3) And then how do we survive the change when CC becomes the stable release and DD becomes trunk?

For #3, I am leaning toward saying "Supported in BB" (or "Supported in 14.07") This will remain true for all time. If a developer/wiki-maintaner verifies that CC works, and updates the dataentry, with "Supported in CC" and a link to the new CC images, the ToH will rebuild itself and continue to be true.

(Last edited by richbhanover on 15 Jun 2015, 20:56)

I had a suggestion about images a while ago about having separate image links for different releases:
https://forum.openwrt.org/viewtopic.php … 06#p278506

But (as I think @richbhanover was suggesting), having just status fields:
AA Status: no
BB Status: supported
CC Status: ?
That would be nice

Argument against the interpretation: "Supported = Official / stable release available = Enduser suitable":
- An official release doesn't guarantee 'Enduser suitability' for a specific device (correct me if I'm wrong)
- A trunk image is not per se 'Enduser unsuitable'

That leads to the question: What are the criteria for defining a device 'supported' or 'enduser suitable'?

That's all I'm after: Defining criteria for the ones who come after us and who have to decide clearly if a device is supported or not.

The criteria "Enduser suitability" is kind of soft, since this can not be derived from the availability of a stable release. The "stable" is related to OpenWrt overall, not the specific device (again, correct me if I'm wrong).
The criteria "Image available" (be it trunk, stable releas or 3rd party) is a hard one - yes or no.

Yes, would be nice, but this would result in changes in the dataentry structure (i.e. adding new lines) for each new release.
Changes to the structure are only possible when you edit the wikisource ("edit this page" or right "edit" button), but I think we want the users to edit data via the dataentry editor (left "edit" button).

Reason for preferring dataentry editor over wikisource editing:
The dataentry editor provides a convenient and foolproof mask, i.e. he can not accidentially do something stupid in the left column of the dataentry and render the functionality of the data plugin useless.

I would like to avoid the listing of the status for each release, at least in the way shown above.

Alternative: List all releases.
If AA = No -> Do not mention it
If BB = Yes -> Mention 14.07
If CC = Unknown -> Mention 14.07 as last known working release
If CC is finally released: Mention 14.07, 15.05
If DD = Unknown ->leave it at 14.07, 15.05

That would mean combining

Supported Since Rel     : (14.07)
Supported Current Rel   : (15.05)

into

Supported Releases : 14.07, 15.05

An argument pro the interpretation: "Supported = Official / stable release available = Enduser suitable":

https://forum.openwrt.org/viewtopic.php … 34#p270434

This can be boiled down to the question: What is the criteria for "run with enough stability"?

BTW: We're amateurs here, aren't we?

Regarding the "supported" definition, I would like to hear the voice of a pro, e.g. Jow.

Isn't that what we already have defined today?

Supported Since Rev     : (R12345)               # https://dev.openwrt.org/changeset/xxxxx
Supported Since Rel     : (14.07)
Supported Current Rel   : (15.05)

Last thoughts before bed:
If we decide to go on like "Supported = Official / stable release available = Enduser suitable"
we have to set the Status to "?" by default and check individually for each device, since we can only know if an official stable release is available when we can name the url to the image.

Or in short: Unless we can name the url to an official release image, the status needs to be "?"

Responses to @tmo26 before I go to bed...

- Yes, we're amateurs, but we can still come to conclusions about what "supported" means, in particular with regard to newcomers.

- My belief: "Supported" means that someone can install the image and expect it to work as well as or better than the stock firmware. (Otherwise, what's the point?)

- I would argue that, contrary to @danitool, "supported" means that *both* wifi and adsl work. (Consider the contrary... "Oh, I just spent an hour reading wiki pages, locating the right image, installing the software, and the wifi doesn't work? What kind of @#$%^ software is this?")

- Changing the topic a bit: My goal for this ToH effort is that it become self-sustaining. That is, once we're done with the new dataentry pages and the new ToH, I would like to give the entire ToH team the luxury of walking away and/or focussing our attention elsewhere and have the ToH and detail pages continue to operate as we have designed it.

- For example, the only required input should be people updating the dataentry and details page for routers they know about. When CC becomes stable, many people (developers and people who own the particular brand/model, and specifically *not* members of the ToH team), would update the dataentry/detail pages with info about how CC works on their own router.

- After CC becomes final, I would be OK with a situation where many of the dataentry/detail pages never get updated beyond BB. This is another indication of the "level of support" for that particular router. If nobody gets around to trying CC on that model (or nobody gets around to updating the wiki), then I see no value to sending newcomers to that equipment. There are plenty of good and reasonably-priced routers that *are* supported. *We* should not spend hours of time figuring out how to help some unknown person save $20 on their router.

- Consequently, we can be selective about the information we retain/display. There are three categories of people:
   1) Newcomers, who care about the "stable" release for their router. We should make that our focus, so that anyone trying it is highly likely to succeed.
   2) A small fraction of people (developers, people who hunger for the newest stuff) care about trying out the latest from trunk.
   3) A vanishingly small fraction of site visitors are looking for historical information on AA or earlier versions for routers that have current support. We should retain the info that exists, but shouldn't spend a great deal of time linking to those older (obsolete, buggy, ugly) builds.

- The proposed framework works well for #1

- Given that #2 above (people interested in trunk builds) is a small number, perhaps there's a way to think of "trunk" as a kind of "WIP". Maybe the Comments could say, "Testing in Trunk (DD) - check the Forum at ..."

- For #3, we can send them to the download pages that list all images for all architectures. (NB the dataentry and details pages will always have info on the most recent *supported* OpenWrt builds. If the current build is AA, then that's fine...)

(Last edited by richbhanover on 16 Jun 2015, 04:52)

How about we just drop it (the Supported field):

1) The end users should anyway just download stable releases (and can be told/taught to avoid trunk)
2) The developers will not waste their time with 2/8MB devices anyway
3) Whether a device is WIP, Possible or Unknown is rather philosophical and says quite little about anything
4) All the details are anyway there (target, memory size, unknown chipsets, question marks)
5) With the "new" data entry model:
  - filters will make all 900+ devices manageable in "one" table (I think the 5 pages were created for this purpose)
  - filters can suit different needs/audiences
6) The "Supported" page is actually not called supported, it is called "Start"
7) Very different opinions/expectations about meaning of "Supported" (ADSL not working)
8) "Supported" is a simplification: people should read the device page for details/quirks anyway
9) When it comes to end users and purchasing recommendations:
- most supported devices are anyway not available for purchase
- most supported devices are not well supported in the sense that they have many users and are well tested (?)
- they would be better served by a top-20-list of currently available routers that actual users actually buy

...and so on...

So we drop it?

This is good... as long as filters work fine.

I think the rule for updating this field (and the image links fields) should be that it should be done by someone who has actually tested it.
Perhaps the device page should have a little section "New Release Testimonies" where people can say "me too". And when a few people have approved the above field and the image links can be updated. This way "abandoned" devices will degrade gracefully.

Of course, a forum thread can have serve the same purpose.

And eventually, when it is obvious that several people are using the device, anyone can update the Supported Releases and image links.

(Last edited by zo0ok on 16 Jun 2015, 07:51)

Looking at the remarkable lack of response, I'd say that "Drop the supported field" is not supported.

Haha! If I didn't want to listen to the others, I would just implement things my way, and then you would make scripts to patch my files before importing them. You get the Status_-field the way you want it.

But I think I have failed - strictly intellectually - to understand what was agreed on before I came with my drop-it-suggestion.

I suggest, either:
1) Tell me what statuses you want, and how to transform the current into the new, or
2) We leave it the way it is, simple as that.

I'm afraid my previous note threw a spanner into the works, and I'm sorry that I didn't respond yesterday. I was intrigued by the suggestion to drop the Supported field, but I'm not sure it hits the target.

My goal is to provide newcomers (and more experienced people) the right info to make a decision about firmware. This would have a link to the image (if available) and its "status" which describes what the image is. The Details page can have all the history (links to Kamikaze, Backfire, AA, BB, ...) but the ToH should summarize the "current state" for the router.

I think there are two difficult cases:

1) Router that has an image for BB, but there's a pretty solid build for CC (the state right now, for example). We want people to know about the BB build, but also that there's a pretty good new version coming soon.

2) Brand new model that doesn't currently work with either BB or CC, but there are folks who're working on it.

The rest of the cases seem simpler because there's only one image that's interesting.

Maybe we want to keep the "Status" field, but also provide a new field that's for "Developing News". It could be a link to the Details page or a Forum topic where people can talk about WIP/trunk developments.

@zo0ok: for the time being: Leave it as it currently is. It's the easiest and fastest way.
However, I've been thinking about this topic now for 2h*, and came to the conclusion: Let's try it out, let's see how it looks and feels like in the toh mkII, rather than just talk about it.

See, if the toh and datapages answer all questions a new user / developer might have in regards to hardware, openwrt status and firmware images, and if we can show the newbies the right direction.

For the tryout, change "Status_" to "Status_hidden", and fill this field with the "Page" out of your list.
This way it will not show up in the dataentry editor (but still in the wikisource), to simulate the absence of this field. If we decide to re-implement it: Simply recreate the datapages, but this time with "Status_".
Or in other words: We can kind of "switch off/on" this field from being displayed via the "_hidden".

We all can experiment in my demowiki, however, I'm hesitating to provide the adress publicly, since it's running only on a rpi2 on a 5mbit up line. Too bad we can't use private messages here in the forum.
I can send the URL via email, icq, jabber though

* 2h: You were right when you said "you all seem enthusiastic and agreeing, but I dont know about what"

Can you give some examples for this?

Can you also give examples for this?
I admit, I'm having difficulties to imagine what you mean or how the final result will look like...

Hmm... now you're confusing me. We already have this:
Device Page_page        : (.:toh:d-link:dir-505) # .:toh:brand:model_version
Forum Topic URL_urls    : (?)                    # forum.openwrt.org/viewtopic.php?id=xxxxx

Updated: https://dl.dropboxusercontent.com/u/906 … index.html
Data entries: https://dl.dropboxusercontent.com/u/906 … ikitxt.tgz
Data entries with Status_hidden: https://dl.dropboxusercontent.com/u/906 … hidden.tgz

A Raspberry Pi 2 - what a luxuary!
I thought you ran it on your DIR-505!

If you click on my "profile", I think there is a link to my homepage (blogg). You can post a comment there with the link (on any post) to your RPi. It should not be visible until I approve it. And I can delete it instead of approving it.