Seeing that users come to the forum with the same problems over and over again (I installed snapshot and there is no GUI; $thisandthat is not working as expected), I have the feeling we should be more explicit on the above page and give recommendations on when to use snapshots and when not.
My proposal to be added to the above page:
do use snapshots if...
your are experienced with linux, know how to manage unexpected problems of any kind (not booting at all, bootloops, no network connectivity, ...) [alternative see next line]
your are experienced enough with linux to know how to help yourself, should unexpected problems of any kind occur (not booting at all, bootloops, no network connectivity, ...)
there is not other choice, i.e. there is no other stable release available. This may be the case for newly added devices, or devices whose support hasn't matured enough to be called stable.
if stable release suffers from poor performance, and if snapshot is explicitly recommended in the forum due to improved stability, better wifi, or $whatever_problem it solves.
you can live without a GUI, or if you are experienced enough to install LuCI yourself
do not use snapshots if...
you absolutely need a GUI and you are not capable of installing LuCI yourself via ssh/commandline
you are completely unexperienced with linux and do not know what ssh is. It will most probably be a hassle for you and all other people involved to pull you through the installation and back to stock firmware.
you think you always need at any time to have the latest bleeding edge software, just because. The problems that can arise (starting by non-availability of LuCI in precompiled snapshot images) might be overwhelming to you and might drive you back to installing stock firmware again.
your expectation is to have a flawless and 100% working compilation, installation and usage of the firmware. Snapshots are experimental, and weird issues of any kind can arise at any time. What does work today, doesn't necessarily work tomorrow.
[ insert standard disclaimer, I can't speak for the LEDE project or its developers ]
[ I'd invert the order here and start with "do not use snapshots if... ]
This is a rather difficult topic...
...a matter of pretty personal perspective and the abilities and ambitions of the individual user.
On the one hand those users who'd need that disclaimer would be better served not using snapshots in the first place, on the other hand bugs can usually only be fixed via the current development trees, before eventually propagating back to a stable branch.
Stable releases do offer the advantage of luci being preinstalled, just as well as being frozen - which means users can install additional packages days, weeks, months or even years after they've flashed their base image. What the stable label cannot ensure however is the actual functionality of the firmware image for each an every device for which an downloadable firmware image exists, many devices probably haven't been tested by a human in years[1] - and there isn't really a tag in the image building code which would preclude device firmwares from being built and released with a stable release[2], even if they'd be known to be problematic. This means while there obviously is a better chance for bugs to get known for a stable release image, there isn't really a way to qualify this stability for all released devices.
Vilifying snapshot images wouldn't really serve its purpose either, in many cases users (at least those who can cope with installing luci manually or recovering from a potentially bad snapshot image) don't really have any other choice to either find support for their device or help in gettings things fixed[3] for themyselves and others. There is no inherent instability in the master branch, snapshots just haven't seen wide spread distribution or testing before the user gets access to them - but at the same time only very popular devices could be labelled as known-stable for release images either (and for those devices, bugreports tend to get raised quickly for the master branch as well).
[1] e.g. you can still download images for many 16 MB RAM devices, chances that those default release images (with uhttpd/ luci preinstalled) manage to even boot are somewhere between unlikely and non-existant - snapshots (without luci) at least offer a slim chance of "success" in that regard.
[2] that could be simply very new target architectures with not quite as mature as usual code, just as well as known broken devices - or device images that only have basic support (e.g. no wlan drivers) and don't really live up to the expectations of normal users.
[3] 17.01.x has roughly kernel 4.10 level wireless drivers, the master branch (snapshots) has updated to kernel 4.13 level drivers - this does improve support for several wlan chipset, both rather new ones (ath10k, mt76, mwlwifi, ...) and some fixes for older ones (rt2x00 thanks to Daniel Golle).
i just want to thank both of you for all the hardwork youve put into development and keeping things array('LEDE',[1,2,3,4]), you not only offer support, but are often very explicit on upkeep. I enjoy the forum and moderators along with users. Keep up the good work!
I added to that wiki page an introduction before that "do / do not" section.
Something like:
Main differences of buildbot snapshots compared to official stable releases:
snapshots do not contain LuCI GUI by default. It needs to be installed by the user.
snapshots are completely untested. Just automatic builds of the most recent source code and packages. Although snapshots are usually ok, they may sometimes contain serious bugs that prevent booting the device correctly or even prevent easy sysupgrading to new versions.
snapshots are built daily, and that sets time limits to installing new packages with opkg. Due to kernel version checksums, you can only install "kmod" kernel modules and other kernel version dependent modules from the exactly same snapshot build. So, after a few hours after flashing the firmware you may not be able to install new modules with opkg any more (as the next snapshot has been built into the download repo and has different checksums).
Main benefits of the snapshots:
newest available version of the main LEDE source and every package
support for new devices that have been added since the last stable release branching
1 - I think a bigger issue than the content is the visibility of the page itself. It's pretty hard to find. it's a "more" button on the downloads page. The user will first see the bold link to the actual firmware. Maybe stats can tell us how many people actually open the page.
2 - I agree putting the "do not" above the "do"
3 - I would suggest that there be something about "upgrade from factory" to initially use a release version if available, even if they want snapshot
4 - do not use snapshoot if you would like to install more packages in the future ( yes, already noted)
I think it has to be dealt with the same structure as the 4mb/32mb warning, as it targets the same people (newbies that don't know the limitations of what they are about to do).
So, a short message for the popup/message/thing saying like:
a
WARNING: Snapshots have no graphical interface, only SSH terminal!
They may have other limitations, see -link-to-bigger-article.
a
And then you can write a verbose article however you like. Note that I'm choosing the most important issue for a newcomer (lack of web interface) over anything else to grab his attention.
LOL the fact you have to explain any of that really makes me feel like im surrounded by women, i know that sounds sexist but thats just me.
<generic-sexist-statement>
Nonsense, women don't even know what a firmware or router is. </generic-sexist-statement>
On a more serious note, LEDE has some pitfalls that are not easily noticeable for newcomers.
I mean, a guy comes here because he wants to have a wifi router with more features (usually), or safer/updated, or whatever. Newcomers don't usually have a Linux background (most Linux users will figure out in 2 minutes that if the webinterface is not working they should try SSH too), nor a good-enough understanding of embedded hardware to figure out hardware support limitations on their own.
very true, maybe thats where beginners should start, a how to on using an ssh client, so they understand just some of the basics of a command line interface, rather than a graphical user interface. That way they can experience the whole gamut of tools behind the scene, like a list of tools to try, in order to understand what youre actually working with on a linux embedded device. knowing how to use a linux distrobution with tools like ssh,apt-get, ifconfig, iptables, df, grep etc, are practically a necessity. Then you can begin to understand what a package manager like opkg is and how packets are forwarded with ip tables, how to list your user interfaces. Not knowing that there is another piece to the linux embedded device to help resolve issues you wont see on your GUI, is going to be detrimental to successful operation of ones newly upgraded firmware.
Increased visibility: Where else should the page be linked to from?
4/32-like message: You mean adding such a message box to the dataentries, if only snapshot support is available? That would require a bit of work outside of the dataentry-editor, and would need to be reverted when support changes from snapshot to release, but I think that effort is worth it.
Example (in combination with 432 warning): https://lede-project.org/toh/hwdata/d-link/d-link_dir-601_b1
We could also put the text lf this page into http://downloads.lede-project.org/ - but I am not sure yet how to keep it editable... maybe I could make the directory index script fetch the wiki text.