LEDE Table of Hardware: Review of dataentry fields

Talk about Documentation
4

re: First-cut ToH pages.

  • The pages are much too wide. Perhaps the default text/search field widths could be made smaller?
  • CSS has the ability to make alternating rows different background colors (some kind of odd/even selector. See, for example, http://www.w3schools.com/cssref/sel_nth-child.asp)

Yes, I wasn't quite clear. It's all about "creation time". If we want to apply changes to every template, we really need to decide about those changes right now.

It's one thing to run a script across the 1100 dataentry pages to add/modify/remove fields. If we screw up and want to make changes after other people have started to enter their own info, it's a much harder process.

I was only suggesting that I would prefer to call this the "bottom-left button". I was initially perplexed at the instructions stating to use the "left edit button" because my eyes looked to the left and didn't see one... at least until I scrolled all the way down to the bottom. "bottom-left Edit button" would completely satisfy my concern.

Thanks.

5

depending on what you think about my idea here about templating the flashing guides too, we might need more fields to accomodate the info required by that to work
(flash offsets (min/max) for manual flashing, an identifier field to link the right tutorial depending on web interface as newer devices might have a different web interface even if they have the same brand ,console settings, something else maybe)

6

The file downloads have been reorganized and most of the packages are now at a folder at the same hierarchy level as targets. Under this "packages" folder are now a flat set of 39 instruction sets (I just checked all the subfolders) so I do not the the "Sub Instruction Set" field will be needed.

Can we mirror the exact names in this page https://downloads.lede-project.org/snapshots/packages/ for the Instruction Set values. Can the drop-downs link to the appropriate sub page?

I for one have not a clue as to how to map from targets to instruction sets, and do not think it's safe to have the user guess.

Not sure how to do the cleanup on this.

7

I find it confusing to have the fw images sorted into folders by target, and the packages sorted into folders by instruction set. Why is this so?

Updating instruction set in the dataentries: Sure, can be done.
Please complete the table I created here: https://wiki.lede-project.org/toh/instructionset_conversion

I don't understand... what dropdowns and sub page do you mean?

8

Images are grouped by target and packages by instruction set because multiple targets share the same packages.

Will provide a list of mappings here once I'm ner my PC again

9

I am referring to the drop down in the Data Entry view while in edit mode which contains the instruction set values.

I am suggesting, if possible, this display as a hyper-link in the data entry view mode and point to the same value on this page: https://downloads.lede-project.org/snapshots/packages/ .

So the LEDE Instructions Set value "i386_geode" would land here: https://downloads.lede-project.org/snapshots/packages/i386_geode/

I have gone into more detail here: Packages for instruction sets I have no idea how to map the values in this table, and suspect most users will also not.

10

OK, now I get it!
I'm afraid, AFAIK this is not possible. That's our old problem, that we want to show a short link in the datatables, e.g. "Installation Image" or "Upgrade Image" instead of the current full url.

11

Found a workaround:

  • datafield "LEDE instructionset" is now of type "page" -> internal wiki link
  • datafield "Packages download" is now of type "title" -> internal wiki link
  • on the page that both of the above datafields currently link to, I placed an external link to https://downloads.lede-project.org/snapshots/packages/
  • I created a namespace template for /instructionset/, which automatically fills in the instructionset in the pagetitle and the packages URL.

Good enough?

1 Like
12

Great solution!

13

I realize that I should mention something that has always bothered me about the "Device Page" entries shown on the OpenWrt ToH.

The names are lower-cased, but I think they would be far better ("more official" appearing) if they were the same case as the "Model" column.

14

We were talking about modularity. Several devices share the same installation methods.
Introducing the "Installation method" field was an attempt to create shortcuts to the always same installation instructions, that do not need to be repeated over and over again.

Richb wrote in Toward a good "Flashing LEDE Instructions" page - #22 by richb-hanover

I am not sure of the value of this "Installation method" field.

First off, I don't know how we would populate it. It wouldn't make
sense for us to review all the Device Pages from OpenWrt: despite the
fact that it would be a lot of work, we'd simply propagate any
(mis)information contained there (because we don't have personal
experience with all devices).

Second, what will the reader do differently based on the setting of this field? Would they choose not to use the device?

  1. I'm not afraid of a lot of work.
  2. Why should we review the OpenWrt devicepages, when this is about LEDE devicepages (which have yet to be created)?
  3. You don't want to propagate (mis)information -> you don't want to copy the OpenWrt devicepages, but instead create new LEDE devicepages. If the devicepages are created new anyways, why not add a new way to include installation instructions?
  4. Why should the reader do anything differently?
    What you might think: The "Installation method" shows up in the ToH, and the $user wants to sort and select by this criteria. That's not necessarily so, but thinking about it, it could be a usecase (I want a device that can be flashed via GUI, since I'm too noob to even think about using CLI. Everything different than GUI will not do.) But that's only thinking aloud...
    What I was thinking of: Show this field only on the devicepages and make them more modular by doing so.

Look at the packages download: Packages are now downloadable by instruction set, not by target, because several targets share the same instructionset and therefore also the same packages.

Same same in this case: Several devices / targets share the same installation instructions.
You could show this field on the devicepage in the "Installation" datatable, right next to the firmware download urls https://wiki.openwrt.org/meta/template_device#installation

15

Since LEDE is targets not only routers anymore, but to a wider category of embedded devices with hardware that may be much different than routers:
Would it be useful to have a field "GPIOs" in the dataentries?

The number of readily accessible GPIOs could be a useful search criteria.

What do you think?

16

Definitely, I think GPIO info is useful for custom hardware projects

17

+1 for GPIO field, for devboards/single board computers it is crucial info.

It may make sense to list also screen ports (either embedded like LVDS or external like HDMI) and audio ports.

18

Gentle reminder :slight_smile:

The conversion table I posted above moved to a new location and is waiting for filling. Once I have the relation OWrt vs. LEDE Instructionset, I will update the dataentries.

https://wiki.lede-project.org/docs/instructionset/instructionset_conversion

19

he posted them here

If what you need in that wiki page is mostly monkey businness (jow not strictly required), I can do that tomorrow.

20

Nice! Thanks for pointing me to that posting!

21

I've been adding things to that page, I noticed we have a few package arcs that are not used by any target.
I removed their entries when jow confirmed that they are indeed useless and will be purged from the download page here

22

Looking at the full view, at the end are "Firmware LEDE Install URL" and "Firmware LEDE Upgrade URL".

Currently there is only trunk and the url points to the snapshots folder. Eventually (soon?) there will be a stable release. Do we need 2 more fields and add some text "Trunk" and "Stable" (or similar) to the descriptions?

Do you have a plan around the future of the OpenWrt fields and contents? Long term does it make more sense to add a field and link to the device or techdata page at OpenWrt.

23

In the past the directive was: Show the stable version in the firmware download fields. Only if no stable version exists, use trunk instead.

No plans. For now, they are there and didn't cost anything :slight_smile:
If they stay in the dataentries, they need to be updated... hm... extra workload.
I wouldn't mind throwing them out.

That's already available: https://wiki.lede-project.org/toh/views/toh_available_864