Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Joe Touch <touch@isi.edu>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: bloat@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net,
	touch@isi.edu
Subject: Re: [Cerowrt-devel] failing to find the "declared victory" in a current wifi router
Date: Wed, 08 Jul 2015 13:28:20 -0700	[thread overview]
Message-ID: <559D87E4.8010600@isi.edu> (raw)
In-Reply-To: <8F877E8A-6DD2-4318-B690-DF7395394037@gmx.de>

Hi, Sebastian,

On 7/8/2015 1:15 PM, Sebastian Moeller wrote:
> Hi Joe,
> 
> On Jul 8, 2015, at 20:37 , Joe Touch <touch@isi.edu> wrote:
...
>> The other step, IMO, would be two flags in the OpenWRT list of hardware:
>>
>> 	- a flag/color that indicates that the most recent hardware rev
>> 	supports BB
>>
>> 	- a different flag/color that indicates that the most recent
>> 	hardware rev supports CC
> 
> If you look at http://wiki.openwrt.org/toh/start you should have
> noticed two columns: version and status: status was/is supposed from
> which version openwrt supports that specific router version is
> supposed to tell which versions of said router actually fall under
> the supported status.

The information isn't clear:

	- does this indicate the openwrt version that first supported
	the hardware? or the specific version that is required?

	- for devices with multiple versions, this doesn't
	indicate whether the most recent version is supported or
	if the information refers to legacy versions

> Granted, status are not filled for all routers and sometimes with the
> unfortunate label “trunk” without stating a date or release number,
> but these seem to be the minority. Version seems to be in worse shape
> with lots of “-“ and “?”.

> By the way, you keep repeating the phrase “most recent hardware rev.”
> as if there was a common repository somewhere on the web from which
> to deduce what the most recent incarnation of each specific router
> name/type is; as it stands this information is filled in by
> volunteers, based on what version they got from a store/vendor/OEM
> and their installation testing/development. I would love to learn if
> you have a better way of collecting that information preferably in an
> automated fashion?

Sorry; to be more clear, I'm only asking for a different way of seeing
the information already on the site.

E.g., the Linksys WNDR4300 indicates support for v1 under BB, but that's
not the version that's now sold; when I click through to the device page
I see the information that indicates that the most recent motherboard
version is not currently supported at all.

I.e., I would have found the table much more useful if it had indicated:

device		BB	CC	highest board rev/support
-------------------------------------------------
WNDR4300	V1	no	V2/no

The BB column would tell me whether BB works and on what revs (and could
list more than one board rev); similarly for the CC column.

The last column above would tell me whether to bother trying to buy this
device now.

All this information could be derived by clicking on the many devices in
the list; I'm suggesting a different organization that would be more
useful to those trying to get on board and join the project.

>> The current list is a confusing mix of information about very old,
>> sometimes EOL (end-of-life) equipment.
> 
> What is bad about keeping information? Just because a device is EOL 
> by its manufacturer/vendor does not necessarily mean it is completely
> out of the retail channel/ second hand retail/sharing channel, so
> keeping information how to give such devices a “second life” as
> openwrt routers seems like a good idea to me.

Nothing is wrong with keeping the info; the issue is whether and when to
push it to a separate page.

Again, I do hope the feedback is useful.

Joe

  reply	other threads:[~2015-07-08 20:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-07  1:02 Joe Touch
2015-07-07  2:23 ` Rich Brown
2015-07-07  4:22   ` Joe Touch
2015-07-07  7:20     ` Sebastian Moeller
2015-07-07 12:03       ` [Cerowrt-devel] [Bloat] " Kevin Darbyshire-Bryant
2015-07-07 14:07     ` [Cerowrt-devel] " Rich Brown
2015-07-07 18:19       ` Matt Taggart
2015-07-08  1:54         ` Rich Brown
2015-07-08 18:37         ` Joe Touch
2015-07-08 20:15           ` Sebastian Moeller
2015-07-08 20:28             ` Joe Touch [this message]
2015-07-08 22:16               ` Sebastian Moeller
2015-07-09  1:34                 ` Rich Brown
2015-07-08  0:48   ` Jim Reisert AD1C
2015-07-08  2:47     ` Dave Taht
2015-07-07  6:16 ` Mikael Abrahamsson
2015-07-07 18:34   ` Joe Touch
2015-07-10  7:03     ` Mikael Abrahamsson
2015-07-10  7:22       ` Joe Touch
2015-07-10  7:48         ` Mikael Abrahamsson
2015-07-10  8:01         ` Sebastian Moeller
2015-07-10 16:57           ` Joe Touch
2015-07-07 15:40 ` Dave Taht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=559D87E4.8010600@isi.edu \
    --to=touch@isi.edu \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox